So in a non-packetised (i2s or spdif) couldn't some jitter be caused in transmission? Can't you get transmission group delay, or phase delay that varies with frequency (ie with the bit pattern being transmitted), or even with noise, causing variability in the detection of the framing bits?
Not necessarily. If talking spdif, or i2s - ie a raw, un-packetised PCM transmission, it's possible that variability in the jitter could be at audible frequencies. If you deliberately modulated the timing, so the DAC clock had frequency modulation in the audible range, that would manifest as audible components in the output. It's not per bit phase shit that's an issue, i's per sample phase shifting, with frequencies in the audible range. Cable impacts Jitter, and noise might too.
But back to the review - it's packetised ethernet, and none of this jitter matters on the wire unless it causes frame drops, which shouldnt happen with any significance with any compliant cat5/6 cable.
Sort of. It's jitter that's the problem for i2s, not bit loss/corruption (if you are losing bits, you are in strife though). If you don't have a rock-solid reference clock at the dac, and buffer/re-clock to that, you're influenced by jitter in the transmission. I2s is transmitting raw PCM intended to directly, and immediately drive the DAC. Jitter can vary with signal and time, and that jitter appears as a modulation of the DAC timing, which may have audible components. Imagine the DAC pushing out a square wave, where the rising and falling edge being delayed in a sinusoidal pattern - you'd hear that as harmonic. I don't understand why they just don't all have a high precision clock for the DAC, and be done with it. Perhaps then syncing multiple DAC could be an issue, but inside a single stereo DAC, it should be easy (given the cost)?
Anyway in the review above at the-ear.net, it's all wankery. It's packetised ethernet, pulling data of a NAS. Assuming things aren't so bad that we lose frames, any compliant cat 5/6 will happily work, as long as the box accessing the NAS can keep up. The original cables would have to be so bad, or faulty, as to cause significant packet loss, which would not manifest as improved sound stage, but as noise, dropouts - nothing subtle.
For i2s, cable quality does matter more, but only if your DAC needs to extract re-clocking info off the wire, and returns diminish rapidly, extremely rapidly. Poor cables, long runs could potentially alter the output signal,and possibly in an audible way.
Have a read of "The Phoenix Project" [http://itrevolution.com/books/phoenix-project-devops-book/] . It's about dev-ops, but also gives an insight into how IT systems are the core of a manufacturing business. Show they add value. Align your IT work with the strategic goals of the business, and show how what you want to achieve with your work will improve the bottom line.
I wonder if a mill driven version is feasible, provided you always operate in a zone with sufficient apparent wind. I know on sail/wing craft, that the direct downwind is only impossible due to stalling of the foil, but if a turbine was used, and you have already exceeded windspeed, I can't see any reason you can't go dead down-wind (given the mill can generate enough power to overcome drag, at say 1.2x apparent wind)
This is a very interesting topic - regardless of where it's floated, it generates the same set of arguments every time, amoungst people with the same varying levels of education and intuition
I used tacking/gibing interchangeably (having the wing change sides of the sail), but it's not important. What is important is sailing downwind faster than the wind (whether directly downwind, or at a very broad reach off the wind)
The speed of the boat can be greater than the wind speed, and yes, I agree that the hypotenuse is the boat speed. However, if the boat is travelling at something significantly more than wind speed, the component in the direction of the true wind can exceed the actual true-wind speed (and hence, any component of it). Upwind, it's not likely (as you need to have more than 1.4x wind speed I think), but downwind, if you get 2x wind speed, and 135deg heading, the component in the wind direction will be greater than the wind speed. For an ice-boat, at 135deg true wind, it might be doing 5x wind speed, with apparent wind 20deg (it feels a headwind still)
In this case, it's wheels driving a propeller, but I think the other way could work too. See this animation for a good intuitive reason as to why it works
It's the movement of the wind relative to the ground that's important (to avoid the perpetual motion stuff), and the relative forces required in air vs on-ground. The animation clearly shows how a simple geared machine can move in the opposite direction to the motive force (and faster), aor move in the same direction. In this case, the prop is the inneficient mechanical interface to the wind,
At risk of great embarrassment, I can see that this is possible. I can't fully explain this particular device, but my windsurfing experience tells me that if my drag didn't increase so massively with speed, and my sail didn't stall as the apparent wind closed in, I could keep accelerating off the wind. Faster than wind sailing is well understood (balance of lift and drag at a particular velocity, that is greater than windspeed) I suspect there's some sort of polar function of wind speed and boat speed that obeys the conservation of energy stuff, that can't be achieved with a fixed wing.
It's been shown that ice-boats can travel at more than 5x wind speed, and be heading within 20deg of downwind at this time. The VMG (average velocity), accounting for tacking, can be directly downwind, and way in excess of wind speed (the analogy is that if you raced a balloon, you can beat it). They can't just take off in the downwind direction and achieve that, they need to reach speed first, then head downwind, and the faster they go, the further downwind they can point. By towing another vehicle that travels directly downwind, we have a wind powered vessel travelling directly downwind at more than wind speed.
Replace the sail with a pivoting turbine driving some very efficient drive mechanism, I can see how we could make a turbine powered iceboat, or land yacht. Because the turbine blade angle of attack is largely dependant on airspeed (not the direction we are travelling, but how fast the air is passing through the turbine), even when travelling downwind (at faster than airspeed), the turbine is going to be able to generate rotational force, that can drive the vehicle.
Where does the energy come from to overcome those losses? I had to think about that, and it's about where we draw the bounding box for working out if energy is conserved. The energy source is the same as ordinary sailing. The wind is travelling across the ground, so has kinetic energy when compared to the ground. Provided we are able to attach to the ground and the air, we can extract some of that difference in energy.
And that's what it boils down to: the speed of a wind powered vessel is determined by the energy available, and the energy required to travel at a particular speed. It's not about the direction you are travelling in. The direction of travel just requires diffent means to extract the energy.
No, tacking downwind is not going directly downwind, but if the boat was making way so that it's average velocity was directly downwind, at greater than wind-speed (very efficient gybeing), couldn't it tow something, that was then travelling directly down-wind at greater than wind-speed? That madly tacking/gybing sail is actually a turbine.
To deter copper thieves, why not go straight for the payload. Put a massive, high current coil along the fence line, and induce a current in the stolen copper, either making it too hot to handle, or melting it in place. Safe for the neighborhood kids (provided they keep their bikes away).
Yeah, that's true - no help until you've got some memory pressure. I used to get in a situation where if I'd left my machine for a while, with a lot of apps/RAM used, it would all get swapped out by some IO activity. Swapin was horribly slow, but with USB flash swap, swapin is independant of other HDD IO, and not impacted by random access and is pretty quick.
Big doses of pgout are still nasty, but once it's happened and you've got your working set in RAM, lots of stuff on standby in swap, and big file cache, things work well.
Swap to flash does work.
It allows you to increase swappiness, and push unused stuff to flash, but use RAM for file cache.
I've done some experiments with USB flash on my laptp, and it's heaps better in terms of responsiveness now. No HDD thrashing when ram gets tight.
http://dazsbraindump.blogspot.com/2010/03/why-put-your-linux-swap-on-usb-stick.html
However, all succesfull examples of these groups have some strong leadership. Even if it's informal. The same goes for Open Source software. All thriving projects have effective leadership of some sort. Those without leaders, wither and die.
How about SELinux (or Mandatory access controls)
on
Sudo vs. Root
·
· Score: 1
If you use MAC/MLS type stuff like selinux (not for OSX obviously), root can be just another user, with some extra freedoms depending on circumstance (not all powerful regardless)
As an example, my understanding (not a guru) is in selinux, you don't have to be root to listen on port 80. If you do start it as root, the app has a system enforced policy that determines what it can do. ie it can listen on port 80, but only write to certain files, not make tcp conections (unless allowed etc). The rights aren't of the starting user, but of the application itself.
When this is applied to sudo, the command you run can be restricted in its operation depending on system policy. I think that the final effect depends on who you logged in as, and how that login context is allowed to change when running sudo. ie some users will be able to run a process via sudo and have it take on all its power, but others will not be able to run it with privileges beyond their own (or some subset of the max for the apps policy)
Some posts have talked about renaming/hiding bash for example. In a full selinux environment, when sudo launces bash (or any app as uid of root), it has no more privilege than system policy allows. If you create your own bash, it only has the security privs that you do, even if launched by sudo. You may end up with uid=0, but contained by your login priveleges. Some users can be assigned extra rights and can do more.
Once again, not a guru - have played a little with it in Fedora Core 4 (enforcing mode, targetted policy), which still allows sudo to do anything, via a selinux aware sudo. I beleive that there is a way that you can make it less transparent, and more secure, but as always security policy is a trade-off between usability and absoulte security. I'm happy(ish) knowing that I have strong password policy for my server and that selinux *helps* stop a compromised app operating outside of its intended policy. However, if you have the password to a sudo unrestricted user, all bets are off. When I'm more comfortable with selinux, I will find out how to wind back sudo and require manual changes in my initial security context before doing particular tasks (like changinf application selinux tagging).
I like what i've seen in selinux so far. Some new stuff to learn, and some things still to win me over, but it is a step in the light direction.
Slashdot Mirror
So in a non-packetised (i2s or spdif) couldn't some jitter be caused in transmission? Can't you get transmission group delay, or phase delay that varies with frequency (ie with the bit pattern being transmitted), or even with noise, causing variability in the detection of the framing bits?
Not necessarily. If talking spdif, or i2s - ie a raw, un-packetised PCM transmission, it's possible that variability in the jitter could be at audible frequencies. If you deliberately modulated the timing, so the DAC clock had frequency modulation in the audible range, that would manifest as audible components in the output. It's not per bit phase shit that's an issue, i's per sample phase shifting, with frequencies in the audible range. Cable impacts Jitter, and noise might too.
But back to the review - it's packetised ethernet, and none of this jitter matters on the wire unless it causes frame drops, which shouldnt happen with any significance with any compliant cat5/6 cable.
Sort of. It's jitter that's the problem for i2s, not bit loss/corruption (if you are losing bits, you are in strife though). If you don't have a rock-solid reference clock at the dac, and buffer/re-clock to that, you're influenced by jitter in the transmission. I2s is transmitting raw PCM intended to directly, and immediately drive the DAC. Jitter can vary with signal and time, and that jitter appears as a modulation of the DAC timing, which may have audible components. Imagine the DAC pushing out a square wave, where the rising and falling edge being delayed in a sinusoidal pattern - you'd hear that as harmonic. I don't understand why they just don't all have a high precision clock for the DAC, and be done with it. Perhaps then syncing multiple DAC could be an issue, but inside a single stereo DAC, it should be easy (given the cost)?
Anyway in the review above at the-ear.net, it's all wankery. It's packetised ethernet, pulling data of a NAS. Assuming things aren't so bad that we lose frames, any compliant cat 5/6 will happily work, as long as the box accessing the NAS can keep up. The original cables would have to be so bad, or faulty, as to cause significant packet loss, which would not manifest as improved sound stage, but as noise, dropouts - nothing subtle.
For i2s, cable quality does matter more, but only if your DAC needs to extract re-clocking info off the wire, and returns diminish rapidly, extremely rapidly. Poor cables, long runs could potentially alter the output signal,and possibly in an audible way.
Have a read of "The Phoenix Project" [http://itrevolution.com/books/phoenix-project-devops-book/] . It's about dev-ops, but also gives an insight into how IT systems are the core of a manufacturing business. Show they add value. Align your IT work with the strategic goals of the business, and show how what you want to achieve with your work will improve the bottom line.
Yeah - I sussed out the prop thing later, and actually found a neat animation, using gears, and a moving gear track as an analogy.
http://sifter.org/~simon/journal/20101107.h.html
I wonder if a mill driven version is feasible, provided you always operate in a zone with sufficient apparent wind. I know on sail/wing craft, that the direct downwind is only impossible due to stalling of the foil, but if a turbine was used, and you have already exceeded windspeed, I can't see any reason you can't go dead down-wind (given the mill can generate enough power to overcome drag, at say 1.2x apparent wind)
This is a very interesting topic - regardless of where it's floated, it generates the same set of arguments every time, amoungst people with the same varying levels of education and intuition
Cheers
I used tacking/gibing interchangeably (having the wing change sides of the sail), but it's not important. What is important is sailing downwind faster than the wind (whether directly downwind, or at a very broad reach off the wind)
The speed of the boat can be greater than the wind speed, and yes, I agree that the hypotenuse is the boat speed. However, if the boat is travelling at something significantly more than wind speed, the component in the direction of the true wind can exceed the actual true-wind speed (and hence, any component of it). Upwind, it's not likely (as you need to have more than 1.4x wind speed I think), but downwind, if you get 2x wind speed, and 135deg heading, the component in the wind direction will be greater than the wind speed. For an ice-boat, at 135deg true wind, it might be doing 5x wind speed, with apparent wind 20deg (it feels a headwind still)
http://en.wikipedia.org/wiki/Sailing_faster_than_the_wind#Vector_diagrams_and_formulas
In this case, it's wheels driving a propeller, but I think the other way could work too. See this animation for a good intuitive reason as to why it works
http://sifter.org/~simon/journal/20101107.h.html
It's the movement of the wind relative to the ground that's important (to avoid the perpetual motion stuff), and the relative forces required in air vs on-ground. The animation clearly shows how a simple geared machine can move in the opposite direction to the motive force (and faster), aor move in the same direction. In this case, the prop is the inneficient mechanical interface to the wind,
At risk of great embarrassment, I can see that this is possible. I can't fully explain this particular device, but my windsurfing experience tells me that if my drag didn't increase so massively with speed, and my sail didn't stall as the apparent wind closed in, I could keep accelerating off the wind. Faster than wind sailing is well understood (balance of lift and drag at a particular velocity, that is greater than windspeed) I suspect there's some sort of polar function of wind speed and boat speed that obeys the conservation of energy stuff, that can't be achieved with a fixed wing.
It's been shown that ice-boats can travel at more than 5x wind speed, and be heading within 20deg of downwind at this time. The VMG (average velocity), accounting for tacking, can be directly downwind, and way in excess of wind speed (the analogy is that if you raced a balloon, you can beat it). They can't just take off in the downwind direction and achieve that, they need to reach speed first, then head downwind, and the faster they go, the further downwind they can point. By towing another vehicle that travels directly downwind, we have a wind powered vessel travelling directly downwind at more than wind speed.
Replace the sail with a pivoting turbine driving some very efficient drive mechanism, I can see how we could make a turbine powered iceboat, or land yacht. Because the turbine blade angle of attack is largely dependant on airspeed (not the direction we are travelling, but how fast the air is passing through the turbine), even when travelling downwind (at faster than airspeed), the turbine is going to be able to generate rotational force, that can drive the vehicle.
Where does the energy come from to overcome those losses? I had to think about that, and it's about where we draw the bounding box for working out if energy is conserved. The energy source is the same as ordinary sailing. The wind is travelling across the ground, so has kinetic energy when compared to the ground. Provided we are able to attach to the ground and the air, we can extract some of that difference in energy.
And that's what it boils down to: the speed of a wind powered vessel is determined by the energy available, and the energy required to travel at a particular speed. It's not about the direction you are travelling in. The direction of travel just requires diffent means to extract the energy.
Whew - Even I believe me know...
No, tacking downwind is not going directly downwind, but if the boat was making way so that it's average velocity was directly downwind, at greater than wind-speed (very efficient gybeing), couldn't it tow something, that was then travelling directly down-wind at greater than wind-speed? That madly tacking/gybing sail is actually a turbine.
To deter copper thieves, why not go straight for the payload. Put a massive, high current coil along the fence line, and induce a current in the stolen copper, either making it too hot to handle, or melting it in place. Safe for the neighborhood kids (provided they keep their bikes away).
Yeah, that's true - no help until you've got some memory pressure. I used to get in a situation where if I'd left my machine for a while, with a lot of apps/RAM used, it would all get swapped out by some IO activity. Swapin was horribly slow, but with USB flash swap, swapin is independant of other HDD IO, and not impacted by random access and is pretty quick. Big doses of pgout are still nasty, but once it's happened and you've got your working set in RAM, lots of stuff on standby in swap, and big file cache, things work well.
Swap to flash does work. It allows you to increase swappiness, and push unused stuff to flash, but use RAM for file cache. I've done some experiments with USB flash on my laptp, and it's heaps better in terms of responsiveness now. No HDD thrashing when ram gets tight. http://dazsbraindump.blogspot.com/2010/03/why-put-your-linux-swap-on-usb-stick.html
However, all succesfull examples of these groups have some strong leadership. Even if it's informal. The same goes for Open Source software. All thriving projects have effective leadership of some sort. Those without leaders, wither and die.
If you use MAC/MLS type stuff like selinux (not for OSX obviously), root can be just another user, with some extra freedoms depending on circumstance (not all powerful regardless)
As an example, my understanding (not a guru) is in selinux, you don't have to be root to listen on port 80. If you do start it as root, the app has a system enforced policy that determines what it can do. ie it can listen on port 80, but only write to certain files, not make tcp conections (unless allowed etc). The rights aren't of the starting user, but of the application itself.
When this is applied to sudo, the command you run can be restricted in its operation depending on system policy. I think that the final effect depends on who you logged in as, and how that login context is allowed to change when running sudo. ie some users will be able to run a process via sudo and have it take on all its power, but others will not be able to run it with privileges beyond their own (or some subset of the max for the apps policy)
Some posts have talked about renaming/hiding bash for example. In a full selinux environment, when sudo launces bash (or any app as uid of root), it has no more privilege than system policy allows. If you create your own bash, it only has the security privs that you do, even if launched by sudo. You may end up with uid=0, but contained by your login priveleges. Some users can be assigned extra rights and can do more.
Once again, not a guru - have played a little with it in Fedora Core 4 (enforcing mode, targetted policy), which still allows sudo to do anything, via a selinux aware sudo. I beleive that there is a way that you can make it less transparent, and more secure, but as always security policy is a trade-off between usability and absoulte security. I'm happy(ish) knowing that I have strong password policy for my server and that selinux *helps* stop a compromised app operating outside of its intended policy. However, if you have the password to a sudo unrestricted user, all bets are off. When I'm more comfortable with selinux, I will find out how to wind back sudo and require manual changes in my initial security context before doing particular tasks (like changinf application selinux tagging).
I like what i've seen in selinux so far. Some new stuff to learn, and some things still to win me over, but it is a step in the light direction.