SE Michigan was generally pretty good for me on Nextel (had it there for about 6 months before I moved to Chicago).
But yeah, they were never good in the real sticks; okay in the burbs, though. Depends on where you are - Nextel's network, of all the cellcos I've used (which now includes everyone except T-Mo and Verizon) is by far the spottiest.
Why should an admin have that right? For a fact, if ours did I would be finding ways to break their rules on a constant basis, just because they'd be ridiculous rules. Similarly, if our firewall were locked down too tightly, you can bet I'd be finding ways around it. Reasonable lockdown won't upset a user; unreasonable will, and will likely lead to far more trouble than letting the users use the harmless stuff. I've been on both sides of the fence, working as IT and working with IT, and I've observed enough environments to know that people will use less workarounds when they don't need to work around things to get what they want.
Given that many secretaries (in fact, *all* of ours - we have a security guard at our reception desk, and he doesn't get a computer) are not in the public view, and that of those who are in public view their machines are often not at all visible, why shouldn't they set hunk of the month as their background? What does it matter? If someone is offended by a bit of onscreen beefcake, too bad. As long as the company standards aren't being broken (which would prevent, e.g., nudie pics as backgrounds on engineer's machines in most cases), where's the harm? It's entirely possible that my wearing of a Star of David offends Muslims in my workplace, or that my visible facial piercing offends the strait-laced. However, neither of these interfere with *my* work and with the work of reasonably tolerant people. Similarly, beefcake on the desktop interferes with no ones' work except the overly sensitive.
Admins need to learn that users are probably more sensible in many areas (read: what is and is not an acceptable desktop background) than they are, and that the areas they should be locking are those where the admin actually does know more (read: lockdown installation privileges, lockdown inappropriate network use, enforce virus protection, etc.)
Quite frankly, what I *need* to do my job includes things like admin rights on my PC. What a secretary *needs* to do her job doesn't, and she shouldn't get them, but neither should admin have the right to tell her "You can't change your desktop background. You can't turn drop shadows on or off. You can't change your screen font. You can't make a window translucent" or any of the other things that fall under 'eye candy'. If leaving something unlocked (and again, I'm not saying let them install Weatherbug and crap like that out the wazoo) will not *negatively* affect the computer's stability, then it should by default be allowed. Allowing your users freedom should always be preferable to not doing so, unless there is a good reason not to. You may think your users don't dislike you for locking their machines down, but in my experience, you're wrong.
Installing programs unchecked? Not usually a necessary freedom.
Modifying inherent eye candy properties? Not a necessary freedom, but one unlikely to affect the stability of a machine, and as such a freedom that should be allowed.
Eye-candy that has no effect on the OS (I'm not saying let the users go out and install Stardock or whatever utility of the month) has no effect on administration, and as a result should be allowed.
Case in point - desktop backgrounds. There is no reason not to let users set their own, and many reasons to let them do so, like the fact that if you let them do the things they want that don't affect things, they're more likely to listen to you when you say "You must use Firefox for security reasons."
Hell, they tune the engine output acoustics on cars so that sports cars give a nice 'growl' while family cars have a subjectively quieter engine sound. A lot of engineering time goes into getting the sound right on a Ferrari or Corvette engine.
Would this 'fairly simple workaround' be calling the carrier? Because that's the simplest workaround I know of.
Let me explain something to you. It's called "subsidy locking". You see, you are not paying the full price for your phone, usually. The carrier pays a portion of it. In return, you sign a contract. That's all well and good, but the carriers have (justifiably) decided to lock their phones so that even if you break contract, you still can't use that phone they helped pay for anywhere else unless you ask them first. If you've completed their requirements (I believe for T-Mobile its 90 days of service, AT&T 180, and I don't know for Cingular) then you can get it unlocked just by calling them.
It isn't disingenuous, unless you purchased one sans discount and it came locked. They should be better about explaining unlocking options, but there's nothing disingenous about them technologically enforcing the contract you signed with them.
Really? A quick Google would tell you the number is closer to 95%.
Re:I'm not worried, I don't use cash
on
Make Money Fast
·
· Score: 2, Interesting
My corner store won't.
The other corner store will only accept electronic transactions if I'm buying at least $10 worth of goods, which kinda makes it useless for a quick drink after a bike ride.
And it all depends on what kind of cashless society - if we move to a entirely debit/credit card based society, where all purchases are verified by a remote server, there's no counterfeiting, but an e-cash system could have counterfeit problems (depending on implementation).
Also, we will never actually get rid of untraceable cash (of some variety), because that would prevent politicians from being bribed anonymously.
Nonetheless, any change that will result in a huge number of people being inconvenienced for negligible gain (because dialup users have minimal online time they are both harder to infect and less of a problem when they are infected) is probably not a good change. Greene had some okay points in his article, but some of his items (specifically DHCP) struck me as excessive.
Like I said, broadband passing 50% happened last month, so if you hadn't looked in a while, you'd be wrong.
But generally, before pulling out numbers, especially for things that change as quickly as that, you might want to check your stats to make sure.
Re:On the next episode of Trading Spaces!
on
Port-A-Nuke
·
· Score: 1
He got a real design job, because he actually has skills.
I'm not a big fan of country/'old-timey' styled designs, which is pretty much Frank's stock in trade, so I don't like his designs although I admit he usually does a good job with them (if you like that sort of thing). Doug vs. Hildie, on the other hand, is sort of like Kerry vs. Bush - you don't like either one of them, but sooner or later you'll have to pick.
In the US, the majority of home users (over 50% as of last month) are on broadband now. The great majority of internet traffic is caused by broadband users now. More computers by far are hooked up to broadband, as home networks dialing in via dial-up are far less common than connection-shared broadband.
Re:On the next episode of Trading Spaces!
on
Port-A-Nuke
·
· Score: 1
The real question is, was anything ever *good* coming from Hildie? Because I recall seeing Doug produce a decent room once or twice. Fuck, even Frank makes something look okay once in a while, if you like fake-old looking shit.
I know you can convolve with an FFT. If you'd read my post thoroughly, you'd realize that. Conv(f,g) in frequency domain is equivalent to mult(f,g). Just as convolution in frequency is multiplication in time. And the article almost certainly realizes that, as they were implying "We're doing it differently than everyone else does".
The point was, if for some reason (as I said, I can't really think of any) you wanted to perform direct convolution, doing it in realtime on a reasonable input history on CPUs is an iffy proposition.
(Technically, N doesn't need to be a multiple of 2 - you can either DFT with a non-multiple of 2 or FFT with a zero-padded multiple, though without more thought than I care to put into it at the moment, I can't tell you what the bounds on that padding need to be - i.e. do you need to pad by the same amount on both input sequences?)
FFT is n(log n), while DFT is n^2 anyways, meaning that if you can't use the FFT and have to drop back to the DFT (again, I don't believe this would ever need to be the case, as I *think* you can non-uniformly zero pad) you're getting nothing from doing it frequency-domain as opposed to time domain.
It probably doesn't hurt Canada to be in a position where they are unlikely to ever *need* nukes, what with us Americans having such a warm stiffy regarding you guys (seriously... we joke about moose playing hockey, but really we like you.)
(And your beer.)
(Well, mostly your beer.)
Re:On the next episode of Trading Spaces!
on
Port-A-Nuke
·
· Score: 1
I think the GIANT portrait *OF HILDIE* on someone else's wall beats the hay.
Actually, TD convolution can be used for analyzing acoustic properties of a concert hall.
Also, when the FA says 'without converting to the frequency domain', why do you go on to talk about FFTs? The convolution operator f (*) g, is equivalent to integral(range of convolution)(f(tau) * g(t-tau)dtau). Now, frequency domain makes this easy, as f(*)g equals F(w)G(w) (product of their transforms into frequency domain). For discrete time sources, convolution can be represented as f(i)(*)g(i) = sum(over 0 to m)(fsubj*(gsubi-gsubj).
Performing a convolution on a lengthy time domain sample is, for the obvious reason, a lengthy process.
Look at it this way. For a pair of n-point sampled data source, to get their convolution over the same n-points (ignoring any possible extensions prior to or post the sample times of the sources), you need to perform n additions, one subtraction, and one multiplication, per sample. So your total number of operations scales as:
n(n+2), or effectively n^2. Which is alright for a short sequence, but if you're convolving by a long convolution kernel, or if you're preserving a long input history, time-domain convolution quickly becomes a VERY compute intensive process.
Now, why you might want to do convolution in TD without going to the FD, I don't know. But it isn't easy.
Typically, the other important parts of a DSP (besides the single cycle MAC) are:
Zero overhead looping. A DSP can require 0 or 1 cycles to do conditional loops.
Quick modulus addressing, making it easy to implement circular buffers. Again, we're trying to have no or single cycle times to implement a modulus address generation.
You're completely wrong. No offense, but I have personally written audio processing (reverbs, filters, delays, comp/limit) in fixed point math. It isn't even hard. Synthesis is EASY in fixed point, especially additive waveform synthesis. Mine didn't sound good, necessarily, but that has to do with the fact that making a good reverb algorithm is hard, not that implementing it in fixed point is hard. Compressors are a little harder to get right, because you have to think about how you're handling things and you will lose a bit of resolution, but by no means are they impossible. Please learn a bit about how most audio processing is implemented in the real world (i.e. fixed point). Floating opens up some new opportunities, but is by no means necessary.
24/192 stereo is, in fact 3 MB/s (3 bytes per sample * 192000 samples per second * 2 channels). So, 1.5 MB/s per channel. Check your math.
However, if you're doing processing, you usually run it at much higher bit depths to preserve dynamic range and resolution, and to prevent clipping during processes with positive gain; 48 and 60 bit bussing schemes aren't uncommon in current audio software. So now we're talking more on the order of 3 MB/s per channel. We need a channel back for every single processing unit, unless we can route things on card (I'm not, TBH, sure if you can route from effect A to effect B on the card without requiring a trip back to the main system). So, we can max out that 133 MB/s with 16 channels of audio, each having 2 effects processors on it, a not at all uncommon situation.
I meant to add an s to that - Energia had 2 successful launches (well, successful for Energia - Buran was successful, Polyus was not, as it failed to enter orbit wholely of its own fault).
SE Michigan was generally pretty good for me on Nextel (had it there for about 6 months before I moved to Chicago).
But yeah, they were never good in the real sticks; okay in the burbs, though. Depends on where you are - Nextel's network, of all the cellcos I've used (which now includes everyone except T-Mo and Verizon) is by far the spottiest.
Why should an admin have that right? For a fact, if ours did I would be finding ways to break their rules on a constant basis, just because they'd be ridiculous rules. Similarly, if our firewall were locked down too tightly, you can bet I'd be finding ways around it. Reasonable lockdown won't upset a user; unreasonable will, and will likely lead to far more trouble than letting the users use the harmless stuff. I've been on both sides of the fence, working as IT and working with IT, and I've observed enough environments to know that people will use less workarounds when they don't need to work around things to get what they want.
Given that many secretaries (in fact, *all* of ours - we have a security guard at our reception desk, and he doesn't get a computer) are not in the public view, and that of those who are in public view their machines are often not at all visible, why shouldn't they set hunk of the month as their background? What does it matter? If someone is offended by a bit of onscreen beefcake, too bad. As long as the company standards aren't being broken (which would prevent, e.g., nudie pics as backgrounds on engineer's machines in most cases), where's the harm? It's entirely possible that my wearing of a Star of David offends Muslims in my workplace, or that my visible facial piercing offends the strait-laced. However, neither of these interfere with *my* work and with the work of reasonably tolerant people. Similarly, beefcake on the desktop interferes with no ones' work except the overly sensitive.
Admins need to learn that users are probably more sensible in many areas (read: what is and is not an acceptable desktop background) than they are, and that the areas they should be locking are those where the admin actually does know more (read: lockdown installation privileges, lockdown inappropriate network use, enforce virus protection, etc.)
Quite frankly, what I *need* to do my job includes things like admin rights on my PC. What a secretary *needs* to do her job doesn't, and she shouldn't get them, but neither should admin have the right to tell her "You can't change your desktop background. You can't turn drop shadows on or off. You can't change your screen font. You can't make a window translucent" or any of the other things that fall under 'eye candy'. If leaving something unlocked (and again, I'm not saying let them install Weatherbug and crap like that out the wazoo) will not *negatively* affect the computer's stability, then it should by default be allowed. Allowing your users freedom should always be preferable to not doing so, unless there is a good reason not to. You may think your users don't dislike you for locking their machines down, but in my experience, you're wrong.
Installing programs unchecked? Not usually a necessary freedom.
Modifying inherent eye candy properties? Not a necessary freedom, but one unlikely to affect the stability of a machine, and as such a freedom that should be allowed.
You're a controlling freak, then.
Eye-candy that has no effect on the OS (I'm not saying let the users go out and install Stardock or whatever utility of the month) has no effect on administration, and as a result should be allowed.
Case in point - desktop backgrounds. There is no reason not to let users set their own, and many reasons to let them do so, like the fact that if you let them do the things they want that don't affect things, they're more likely to listen to you when you say "You must use Firefox for security reasons."
Hell, they tune the engine output acoustics on cars so that sports cars give a nice 'growl' while family cars have a subjectively quieter engine sound. A lot of engineering time goes into getting the sound right on a Ferrari or Corvette engine.
I can show you more than a few websites calling it the DCMA. Certainly at least 15.
But it's still, and will always be, the DMCA.
Errors can be repeated and spread across the web just like the truth can.
Would this 'fairly simple workaround' be calling the carrier? Because that's the simplest workaround I know of.
Let me explain something to you. It's called "subsidy locking". You see, you are not paying the full price for your phone, usually. The carrier pays a portion of it. In return, you sign a contract. That's all well and good, but the carriers have (justifiably) decided to lock their phones so that even if you break contract, you still can't use that phone they helped pay for anywhere else unless you ask them first. If you've completed their requirements (I believe for T-Mobile its 90 days of service, AT&T 180, and I don't know for Cingular) then you can get it unlocked just by calling them.
It isn't disingenuous, unless you purchased one sans discount and it came locked. They should be better about explaining unlocking options, but there's nothing disingenous about them technologically enforcing the contract you signed with them.
Cingular offers an unlimited GPRS, 1500 SMS, and 250 MMS plan for $20 a month now. Just thought you'd like to know.
Nextel is particularly bad in Chicago metro - Detroit area its pretty good.
I've personally been pretty satisfied with Cingular.
Really? A quick Google would tell you the number is closer to 95%.
My corner store won't.
The other corner store will only accept electronic transactions if I'm buying at least $10 worth of goods, which kinda makes it useless for a quick drink after a bike ride.
And it all depends on what kind of cashless society - if we move to a entirely debit/credit card based society, where all purchases are verified by a remote server, there's no counterfeiting, but an e-cash system could have counterfeit problems (depending on implementation).
Also, we will never actually get rid of untraceable cash (of some variety), because that would prevent politicians from being bribed anonymously.
Nonetheless, any change that will result in a huge number of people being inconvenienced for negligible gain (because dialup users have minimal online time they are both harder to infect and less of a problem when they are infected) is probably not a good change. Greene had some okay points in his article, but some of his items (specifically DHCP) struck me as excessive.
Like I said, broadband passing 50% happened last month, so if you hadn't looked in a while, you'd be wrong.
But generally, before pulling out numbers, especially for things that change as quickly as that, you might want to check your stats to make sure.
He got a real design job, because he actually has skills.
I'm not a big fan of country/'old-timey' styled designs, which is pretty much Frank's stock in trade, so I don't like his designs although I admit he usually does a good job with them (if you like that sort of thing). Doug vs. Hildie, on the other hand, is sort of like Kerry vs. Bush - you don't like either one of them, but sooner or later you'll have to pick.
Except that you can disable the DNS Client service and still get DNS resolution.
Don't believe me? Try it yourself.
Wrong.
In the US, the majority of home users (over 50% as of last month) are on broadband now. The great majority of internet traffic is caused by broadband users now. More computers by far are hooked up to broadband, as home networks dialing in via dial-up are far less common than connection-shared broadband.
The real question is, was anything ever *good* coming from Hildie? Because I recall seeing Doug produce a decent room once or twice. Fuck, even Frank makes something look okay once in a while, if you like fake-old looking shit.
I know you can convolve with an FFT. If you'd read my post thoroughly, you'd realize that. Conv(f,g) in frequency domain is equivalent to mult(f,g). Just as convolution in frequency is multiplication in time. And the article almost certainly realizes that, as they were implying "We're doing it differently than everyone else does".
The point was, if for some reason (as I said, I can't really think of any) you wanted to perform direct convolution, doing it in realtime on a reasonable input history on CPUs is an iffy proposition.
(Technically, N doesn't need to be a multiple of 2 - you can either DFT with a non-multiple of 2 or FFT with a zero-padded multiple, though without more thought than I care to put into it at the moment, I can't tell you what the bounds on that padding need to be - i.e. do you need to pad by the same amount on both input sequences?)
FFT is n(log n), while DFT is n^2 anyways, meaning that if you can't use the FFT and have to drop back to the DFT (again, I don't believe this would ever need to be the case, as I *think* you can non-uniformly zero pad) you're getting nothing from doing it frequency-domain as opposed to time domain.
It probably doesn't hurt Canada to be in a position where they are unlikely to ever *need* nukes, what with us Americans having such a warm stiffy regarding you guys (seriously... we joke about moose playing hockey, but really we like you.)
(And your beer.)
(Well, mostly your beer.)
I think the GIANT portrait *OF HILDIE* on someone else's wall beats the hay.
Actually, TD convolution can be used for analyzing acoustic properties of a concert hall.
Also, when the FA says 'without converting to the frequency domain', why do you go on to talk about FFTs? The convolution operator f (*) g, is equivalent to integral(range of convolution)(f(tau) * g(t-tau)dtau). Now, frequency domain makes this easy, as f(*)g equals F(w)G(w) (product of their transforms into frequency domain). For discrete time sources, convolution can be represented as f(i)(*)g(i) = sum(over 0 to m)(fsubj*(gsubi-gsubj).
Performing a convolution on a lengthy time domain sample is, for the obvious reason, a lengthy process.
Look at it this way. For a pair of n-point sampled data source, to get their convolution over the same n-points (ignoring any possible extensions prior to or post the sample times of the sources), you need to perform n additions, one subtraction, and one multiplication, per sample. So your total number of operations scales as:
n(n+2), or effectively n^2. Which is alright for a short sequence, but if you're convolving by a long convolution kernel, or if you're preserving a long input history, time-domain convolution quickly becomes a VERY compute intensive process.
Now, why you might want to do convolution in TD without going to the FD, I don't know. But it isn't easy.
Typically, the other important parts of a DSP (besides the single cycle MAC) are:
Zero overhead looping. A DSP can require 0 or 1 cycles to do conditional loops.
Quick modulus addressing, making it easy to implement circular buffers. Again, we're trying to have no or single cycle times to implement a modulus address generation.
Uhm....
You're completely wrong. No offense, but I have personally written audio processing (reverbs, filters, delays, comp/limit) in fixed point math. It isn't even hard. Synthesis is EASY in fixed point, especially additive waveform synthesis. Mine didn't sound good, necessarily, but that has to do with the fact that making a good reverb algorithm is hard, not that implementing it in fixed point is hard. Compressors are a little harder to get right, because you have to think about how you're handling things and you will lose a bit of resolution, but by no means are they impossible. Please learn a bit about how most audio processing is implemented in the real world (i.e. fixed point). Floating opens up some new opportunities, but is by no means necessary.
24/192 stereo is, in fact 3 MB/s (3 bytes per sample * 192000 samples per second * 2 channels). So, 1.5 MB/s per channel. Check your math.
However, if you're doing processing, you usually run it at much higher bit depths to preserve dynamic range and resolution, and to prevent clipping during processes with positive gain; 48 and 60 bit bussing schemes aren't uncommon in current audio software. So now we're talking more on the order of 3 MB/s per channel. We need a channel back for every single processing unit, unless we can route things on card (I'm not, TBH, sure if you can route from effect A to effect B on the card without requiring a trip back to the main system). So, we can max out that 133 MB/s with 16 channels of audio, each having 2 effects processors on it, a not at all uncommon situation.
And.... I am an idiot.
I meant to add an s to that - Energia had 2 successful launches (well, successful for Energia - Buran was successful, Polyus was not, as it failed to enter orbit wholely of its own fault).