Look up the meaning as a transitive verb. As a kind gesture I even used one of them colonial dictionaries that I assume represents your cultural persuasion. Some guys representing nobody in particular saying "Oh hay guys, maybe we shouldn't use Trend" is hardly an example of mass agreement from the throngs.
I fully agree that feature sniffing is superior to browser sniffing in most ways, however it's no panacea. Case in point: I'm currently working on a JS SOAP client that must run on many browsers, including a couple of embedded browsers. Two cases where feature sniffing is insufficient:
All the browsers except old IE support creating XMLHttpRequest by "new XMLHttpRequest()". However, one of the embedded browsers segfaults after doing this a few times, so I have to artificially limit it to one request at a time and reuse the same XMLHttpRequest object in that case.
All the browsers support XMLHttpRequest.responseXML, however one of the embedded browsers just creates an empty document. The solution is to use a DOMParser on XMLHttpRequest.responseText in that case.
So yeah, I mostly agree with you, but in some cases feature sniffing may be impossible (as in 1) or just inefficient and awkward (as in 2).
Or alternatively they have a browser sniffing script that whitelists known-good browser setups, and FF2/Linux isn't tested and known to work? Or that their FF detection is too strict and so accidentally excludes UA strings that have slight differences?
Why assume it's malicious, when this sort of issue is well known to anyone who's ever tried to support multiple browsers through UA sniffing?
We're in good company. I guess the only time you could benefit from a query being serviced by multiple processors is if your database is handling fewer concurrent requests than you have processors, and yet you need to shave milliseconds off the small number of queries that are running.
I might be missing something, but that sounds like a pretty specialised use case.
I doubt your problem is CPU bound; most DB issues tend to be I/O bound. If simple queries are taking too long, the chances are you need to rethink your indexing - and be sure to EXPLAIN the query to make sure it actually is using the indices, as there are various reasons (some unavoidable, some a little retarded) why it won't.
Firefox (2 at least) is not standards compliant. Maybe more so than IE7, but it's still not standards compliant. Perhaps you can suggest a 100% compliant brower instead?
Speaking as one of their end users, I would not thank them. I significantly prefer IE to Firefox - just because you don't doesn't mean that you are "right". For me, IE is faster, lighter, and more stable than FF. If I have a choice of browsers I will go for IE or Opera every time.
I realise this may contradict what you thought was the majority world-view (gleaned from Slashdot), but it turns out it's not. Here's another thing to rock your world: for desktop use, I vastly prefer Windows to Linux. Imagine!
Given this engineer seems not to understand the different roles played by bit depth and sampling frequency, I wouldn't hold much faith in what he says.
You need to look up the Nyquist-Shannon sampling theorem. It doesn't state "we can record up to half the sampling rate but with a bit of square-waviness at the top end". What it states (proves) is that you can recreate/perfectly/ a waveform with bandwidth less than half the sampling frequency.
You'll also notice a lot of scary-looking maths. That's because reconstituting an analog signal from digital is a little more complex than just playing join-the-dots, which seems to be what most people do when they talk about square waves at high frequencies.
Of course, how well your DAC implements this is an entirely different matter.
I'm not the OP, but you may want to check out the Studio Central forums. Filled with equal measures of twats and great advice. You'll probably want to check out the DAW forums (digital audio workstaion, in case you've not come across that term before).
Don't expect to find very much about Linux though.
locate+grep is fine as long as you're only interested in a relatively simple query (find all.txt files under/dir/ectory matching this regex). Once you're after something more complex (find.txt files modified in the last week) you realistically have to use find. Then, once you want to move past simple text search (find.html and.odt files modified in the last week, containing the string "my awesome 1995 homepage" even if some of the words are bold or blinking) then you've got to use something smarter that knows to separate content and markup. If you don't need to do queries like that then fine, but that doesn't mean nobody does.
As you've demonstrated you didn't even know what Vista's indexing service did, I would reserve judgement on the finer points of its precise implementation if I were you. But just for starters: would you consider it bloat that Linux has currently "stolen" 300MB of my laptop's RAM for a disk cache? Or would you instead think that that is a sensible thing to do with unused resources?
And finally, nobody's said that indexing is taking 11% of CPU time. YOU said "Name one thing its doing though" and somebody suggested indexing (and defragging). In his case it could be his animated virtual lapdancer wallpaper for all we know. You'll notice that pretty much everyone else says they're idling at around 1%.
My Windows PC (2000 for many years, recently XP) has none of those problems either. Probably because I don't install "useful" software I see in banner ads.
If your friend is happy with Ubuntu+Firefox then that's just great, and it'll certainly help with virus threats. However, I predict it won't be long before we see spyware/adware helpfully distibuted as XPIs, and your friend will no doubt be delighted at how easy it is to install it. Did you know there's a plugin to remove the XPI install delay in FF? Users care about security right up to the point it means they have to type "sudo", remember a separate admin password, click "allow", wait for an XPI timer...you know, actually do something themselves.
I don't think you know what the indexing service does. Take a look at some of the example queries (you'll note several different dialects) and tell me that slocate even comes close. Linkie.
And if there is an equivalent for Linux then I'd love to hear about it, because find|grep and similar are sometimes just too damn slow, and can't provide the level of inspection of dedicated file content filters. Actually, is this what beagle is trying to do?
Where did you get the guitar spectrum from? A poorly-recorded song?
No, my guitars.
eight 12" speakers have PLENTY of low end
Yes, if they're being fed a low frequency signal. A guitar doesn't do low end unless it's gone through an octave pedal or similar. As another poster said it does mid-range, sure, but not low end unless you're really fucking with the signal with effects. Just look at the fundamental of the low E string - hell, even the low B if you've got a 5 string. Compare it with what a bass can do and see what low end means.
From the way you're talking, I guess you have a guitar and a decent rig. Try recording your growliest power chord, then look at the spectrum. You will likely be surprised what you see - it doesn't match what you hear. You'll probably find it starts around the low-mid range, with the high-end increasing with distortion. Though obviously without knowing your exact setup I can't say for certain. If you have access to a half-decent bass rig then try the same and note the difference.
Also, their example of bass driver movement due to a "guitarist strumming a power chord"? I think they should record a power chord and check out its spectrum; there's not much low end at all. They probably mean "on the songs I like, power chords are often played at the same time as loud bass and bass drums".
If they can't tell the difference then they probably have little business talking about the subtleties of music production and recording formats.
Even better is the idea of producers (gasp) altering the mix to suit MP3s better. Maybe they should look up the original purpose of mastering compressors, especially those with a lat/vert mode. Yup - they're there to compensate for the limitations of your precious, precious vinyl.
Exactly because it's an order of magnitude slower. In all other tests it is a similar speed to all other browsers, then in one particular test it is ridiculously slower. There are no other tests or browsers that exhibit this behaviour, else I expect he'd have discounted them as anomolous also.
There could be a good reason for the test showing poor performance - say IE is shit at string concatenation - and then the result reflects badly on IE. Or, it could be that for whatever reason the benchmark hits some strange edge case that virtually never crops up in normal usage, in which case the benchmark should be thrown out. But without further information you have to just treat the result as null. It's an unknown.
Slashdot Mirror
SSH can, of course, be configured to compress automatically.
Look up the meaning as a transitive verb. As a kind gesture I even used one of them colonial dictionaries that I assume represents your cultural persuasion. Some guys representing nobody in particular saying "Oh hay guys, maybe we shouldn't use Trend" is hardly an example of mass agreement from the throngs.
And lo, everyone on the website knew not to believe a single word you say, from now unto eternity.
What you mean is a couple of random people have mooted a boycott. Well I'm sure Trend will issue a profit warning to investors post haste.
The fuck kind of question is that? Next on Slashdot: What's the best colour?
- All the browsers except old IE support creating XMLHttpRequest by "new XMLHttpRequest()". However, one of the embedded browsers segfaults after doing this a few times, so I have to artificially limit it to one request at a time and reuse the same XMLHttpRequest object in that case.
- All the browsers support XMLHttpRequest.responseXML, however one of the embedded browsers just creates an empty document. The solution is to use a DOMParser on XMLHttpRequest.responseText in that case.
So yeah, I mostly agree with you, but in some cases feature sniffing may be impossible (as in 1) or just inefficient and awkward (as in 2).Yes, the MS employee responding sounded clueless - almost as if he's some cheap as shit outsourced grunt reeling stock answers from a knowledge base.
You, however, sound like a mildly retarded cunt. Seriously, you sound like an absolute cunt.
Why assume it's malicious, when this sort of issue is well known to anyone who's ever tried to support multiple browsers through UA sniffing?
Yeah, forcing them to run ultra secret hacking tools like nmap will really sort the 1337 from the L4m3.
I might be missing something, but that sounds like a pretty specialised use case.
I doubt your problem is CPU bound; most DB issues tend to be I/O bound. If simple queries are taking too long, the chances are you need to rethink your indexing - and be sure to EXPLAIN the query to make sure it actually is using the indices, as there are various reasons (some unavoidable, some a little retarded) why it won't.
I suspect if you could "solve the wind resistance issues" most airborne transportation could get one hell of a lot faster than that.
What does that do? Recursively force-delete a directory whose name is a single space?
Firefox (2 at least) is not standards compliant. Maybe more so than IE7, but it's still not standards compliant. Perhaps you can suggest a 100% compliant brower instead?
I realise this may contradict what you thought was the majority world-view (gleaned from Slashdot), but it turns out it's not. Here's another thing to rock your world: for desktop use, I vastly prefer Windows to Linux. Imagine!
Given this engineer seems not to understand the different roles played by bit depth and sampling frequency, I wouldn't hold much faith in what he says.
You'll also notice a lot of scary-looking maths. That's because reconstituting an analog signal from digital is a little more complex than just playing join-the-dots, which seems to be what most people do when they talk about square waves at high frequencies.
Of course, how well your DAC implements this is an entirely different matter.
Don't expect to find very much about Linux though.
That's pretty much exactly what you do. And have you seen the CPU requirements of convolution reverb, or component-modeled effects/synths?
As you've demonstrated you didn't even know what Vista's indexing service did, I would reserve judgement on the finer points of its precise implementation if I were you. But just for starters: would you consider it bloat that Linux has currently "stolen" 300MB of my laptop's RAM for a disk cache? Or would you instead think that that is a sensible thing to do with unused resources?
And finally, nobody's said that indexing is taking 11% of CPU time. YOU said "Name one thing its doing though" and somebody suggested indexing (and defragging). In his case it could be his animated virtual lapdancer wallpaper for all we know. You'll notice that pretty much everyone else says they're idling at around 1%.
If your friend is happy with Ubuntu+Firefox then that's just great, and it'll certainly help with virus threats. However, I predict it won't be long before we see spyware/adware helpfully distibuted as XPIs, and your friend will no doubt be delighted at how easy it is to install it. Did you know there's a plugin to remove the XPI install delay in FF? Users care about security right up to the point it means they have to type "sudo", remember a separate admin password, click "allow", wait for an XPI timer...you know, actually do something themselves.
And if there is an equivalent for Linux then I'd love to hear about it, because find|grep and similar are sometimes just too damn slow, and can't provide the level of inspection of dedicated file content filters. Actually, is this what beagle is trying to do?
No, my guitars.
eight 12" speakers have PLENTY of low end
Yes, if they're being fed a low frequency signal. A guitar doesn't do low end unless it's gone through an octave pedal or similar. As another poster said it does mid-range, sure, but not low end unless you're really fucking with the signal with effects. Just look at the fundamental of the low E string - hell, even the low B if you've got a 5 string. Compare it with what a bass can do and see what low end means.
From the way you're talking, I guess you have a guitar and a decent rig. Try recording your growliest power chord, then look at the spectrum. You will likely be surprised what you see - it doesn't match what you hear. You'll probably find it starts around the low-mid range, with the high-end increasing with distortion. Though obviously without knowing your exact setup I can't say for certain. If you have access to a half-decent bass rig then try the same and note the difference.
If they can't tell the difference then they probably have little business talking about the subtleties of music production and recording formats.
Even better is the idea of producers (gasp) altering the mix to suit MP3s better. Maybe they should look up the original purpose of mastering compressors, especially those with a lat/vert mode. Yup - they're there to compensate for the limitations of your precious, precious vinyl.
There could be a good reason for the test showing poor performance - say IE is shit at string concatenation - and then the result reflects badly on IE. Or, it could be that for whatever reason the benchmark hits some strange edge case that virtually never crops up in normal usage, in which case the benchmark should be thrown out. But without further information you have to just treat the result as null. It's an unknown.