Yes, interlacing is the word I meant; sorry if i caused confusion. Do you have any more info about 24fps DVD content? It doesn't seem obvious/logical, given that a PS3 will output 24p from bluray content, yet not dvds.
$BUZZWORD is totally overrated! It's $OTHER_BUZZWORD which counts! And only $CHOICE really supports $OTHER_BUZZWORD. Yes, !($CHOICE) formally also supports $OTHER_BUZZWORD, but that's no true support. Only $CHOICE has true support for $OTHER_BUZZWORD. And that clearly proves that $CHOICE is better.
You should be using prepared statements and then explicitly passing in buzzwords. Do you have any idea how many argument injection vulnerabilities you have here?
I really have to say "it depends" on this one as well. Star Wars fills the same emotional need for me as LotR, whereas Star Trek fills a niche somewhere in between The Replacement Killers and Patch Adams.
Emacs vs. Vi - Emacs.
Ugh. You people type so many keystrokes, and yet I never see things get done any faster. Vim for POTUS!
My understanding was that all modern TVs have programming specifically to detect pulldown patterns and undo them.
Oppo stuff undoes 3:2 pulldown from DVD material and will play back a 24fps signal. It does make a noticeable difference (I tested on some LotR landscape pans; but even some of my sitcoms seem to be 24fps source, mangled to 60fps for DVD release). However, it really highlights bad edits, because if the 3:2 pulldown isn't perfect in a scene change there will be a single frame which is "torn" into a top half and a bottom half from the surrounding frames. I doubt that any modern TVs are actually undoing 3:2 pulldown without mucking around with interpolation (i.e. 1080i vs. 1080p), which causes its own similar artifacts.
As to references, just search for "120Hz 24fps 5:5 pulldown" and you'll find plenty of investigation on gearhead forums like avsforum. In fact, that link specifically discusses the 3:2 pulldown reversal into a 60fps interlaced stream, and those guys are better informed than I.
which is stupid.. it's slower to move the mouse to the menu, then move hand back to keyboard to type.. either use the menu, or use all hotkeys.. search is band-aid for a shitty GUI.
The GP never actually said anything about mice. The "search bar" gets focus when I hit my Windows key, so excel is 6 keystrokes away from a cold start. For a simple program name this is easily faster than pinning to the taskbar and using the Start+N hotkey, which is the shortest hotkey that I can think of.
i haven't read CALM (i'm not in the USA), but i sincerely hope it defines the level as measured on the end-user's playback device
More significant is that CALM is based on a model of accoustic perception which is much more complex than peak/RMS amplitude. For one, human hearing is more sensitive at specific frequencies (e.g. speech and crying babies, and probably any resonant frequencies of our skull). For another, sharp/percussive peaks tend to be perceived as quieter (or at least less annoying!) than equal-volume sustained tones. So compressing a drumset beat and some attorney's voice to the same "average" range means that the music will sound quieter than the advertisement. So whether CALM normalizes at the broadcaster or at the end-user, it should be strictly better because its measurement more accurately models perception and should have less error inherently.
Also, piling in against the free-market spin doctor: broadcasters are granted a form of monopoly due to limited resources for transmission. They should be regulated and hand-slapped for what appears to be blatant disregard for their government-granted customer base.
the US has the most money and buys and sells oil in thousandths of a second with HFT supercomputers and day traders. They set the price.
Having the most money does indeed enable price manipulation (the guy with the widest stop-limits an deepest margin accounts wins in a game of chicken). But what on earth makes you think that trading faster allows one to "set the price"?
I'll admit that I hadn't thought of building bittorrent into the client; mainly because most residential-grade connections have relatively terrible upstream bandwidth. I can see this working for recent material in metropolitan areas where peers are nearby and upstream bandwidth is plentiful. I don't think it would be effective out in the boonies, and I could see the lack of peers being problematic for less-popular content. But it would definitely be worth a shot for someone like Netflix to try!
Yes there is. Bandwidth caps imposed by cable providers make it artificially expensive to download on demand content, while they continue to chew up what bandwidth they do have with shows that few people watch because of "packages".
FTFY
No, that's not what I mean. Bandwidth for broadcast material can be sized without regard to downstream behavior. When they send so many channels to your cable box, the less popular channels get heavier compression, but they know exactly what throughput they need to provision. With on-demand content, they have to guess. And if they guess wrong, latency shoots through the roof and everyone gets a big fat "buffering" screen instead of their program at peak hours. It's not about artificial costs due to bandwidth caps*, it's about a real and unavoidable difference in the data-stream. Grind your axe somewhere else, AC.
* Artificial scarcity for reasonable-latency bandwidth is indeed a bad thing for the 'net and content distribution in general. But it has nothing to do with my argument that bandwidth or storage requirements are fundamentally higher for an on-demand system than they are for a broadcast system.
A candidate with 5 years writing Perl scripts isn't necessarily going to be able to immediately write pro PHP scripts... Can the candidate learn? Certainly possible... good security practices? Quite likely not.
While I agree with you in principle, your particular example is quite ironic. I would expect a candidate with 5 years of Perl experience to jump straight to PDO for database access, owing to its similarity to DBI. OTOH, I would bet that many PHP programmers are still using mysql_real_escape_string_and_what_does_addslashes_do() in a quagmire of dynamically-generated SQL and blacklist-based regexes (regices?) for data validation.
One of my co-workers came off of a HP minicomputer and was fixing bugs in.NET web applications within a few weeks, a few years later he is now the lead on another web project.
I have smart friends, too. I also know some guys that grew up on C, and now code C++ like it's some horrible bastard-child of C and Java*. Sure, it works, but it ain't pretty. Knowing the Turing model is very different from knowing the effective idioms of a language.
* The verbosity of Java, the manual resource management of C, and the performance of neither.
There is no longer any compelling technological reason for time-slot television.
Yes there is. Bandwidth and storage (caching) capacity can be sized according to the source, regardless of the number of consumers. If all content is on-demand, then either redundant data needs to flow from the source, substantial caching infrastructure needs to be set up, or consumers must plan ahead for material to be available (i.e. starting content in 10-minute timeslices). All are feasible plans, but none is a free lunch.
Maybe you wouldn't have 70 channels of mostly crap if content were priced for the public without hidden advertising subsidies. Many niche channels and programs survive now only because of bundling practices; they would either die or move to Internet-only distribution.
No, it's clearly an extension of the postfix increment operator. The expression a** returns the current value of a and as a side effect executes a *= 1. Because it requires a copy, in most cases you should use **a instead.
Since you don't have the source code to Opera, what makes you think Opera isn't also reporting browsing data, just like Chrome allegedly does?
You don't need the source to trace system calls and network packets. Even if Opera were to phone home using some nefarious mechanism that fell through the cracks of strace and ltrace, it would still be detectable by a packet sniffer. Much like the "many eyes" hypothesis works to give people confidence on source code access, it should also apply here. If a bored nerd discovered something like this on the weekend, news would spread across tech sites like wildfire.
So, how do I stop Firefox from syncing except when I hit CTRL-D?
For starters, you should disable Session Restore and the Awesome Bar. Both of these features are 'auto-saving' and probably require I/O. I would then start experimenting with something like strace -e trace=sync,fsync,fdatasync and looking at stack traces to find further configuration options which can be disabled. Disclaimer: I have not tried this, as I don't have a Linux desktop at the moment. You may need to use ltrace for fsync/fdatasync.
Facebook would be quite within their rights to put these on iTunes or Amazon.
No, they wouldn't. You should try reading the actual FaceBook ToS
Yes, the ToS is quite clear about the ramifications of using (or ignoring) privacy controls. However, because the license is transferable, many users may have accidentally granted this permission while futzing with privacy settings. This particular license terminates, but what if Facebook automatically transfers the license to some wholly-owned subsidiary upon posting? IANAL so maybe I'm missing something, but it sounds like a back door the size of a Mack truck.
For kernels tweaked into "laptop mode" this may be different, but for stock modern Linux the maximum time delay for disk cache writes is 30+5=35 seconds, not hours.
Yes, laptop_mode is exactly the scenario to which I refer when I say "hours". That's of course where the syncs are the most expensive, as well. I ran into this don't fear the fsync discussion on the topic years ago, but it seems that the original site is dead.
Yes, interlacing is the word I meant; sorry if i caused confusion. Do you have any more info about 24fps DVD content? It doesn't seem obvious/logical, given that a PS3 will output 24p from bluray content, yet not dvds.
You should be using prepared statements and then explicitly passing in buzzwords. Do you have any idea how many argument injection vulnerabilities you have here?
I really have to say "it depends" on this one as well. Star Wars fills the same emotional need for me as LotR, whereas Star Trek fills a niche somewhere in between The Replacement Killers and Patch Adams.
Ugh. You people type so many keystrokes, and yet I never see things get done any faster. Vim for POTUS!
Oppo stuff undoes 3:2 pulldown from DVD material and will play back a 24fps signal. It does make a noticeable difference (I tested on some LotR landscape pans; but even some of my sitcoms seem to be 24fps source, mangled to 60fps for DVD release). However, it really highlights bad edits, because if the 3:2 pulldown isn't perfect in a scene change there will be a single frame which is "torn" into a top half and a bottom half from the surrounding frames. I doubt that any modern TVs are actually undoing 3:2 pulldown without mucking around with interpolation (i.e. 1080i vs. 1080p), which causes its own similar artifacts.
As to references, just search for "120Hz 24fps 5:5 pulldown" and you'll find plenty of investigation on gearhead forums like avsforum. In fact, that link specifically discusses the 3:2 pulldown reversal into a 60fps interlaced stream, and those guys are better informed than I.
Yeah, it's pretty distracting at first. But then I find the menu setting to turn it off.
Yeah, we've got some "Saganites" on the block and they're nothing but trouble. I can't stand curiosity.
The GP never actually said anything about mice. The "search bar" gets focus when I hit my Windows key, so excel is 6 keystrokes away from a cold start. For a simple program name this is easily faster than pinning to the taskbar and using the Start+N hotkey, which is the shortest hotkey that I can think of.
More significant is that CALM is based on a model of accoustic perception which is much more complex than peak/RMS amplitude. For one, human hearing is more sensitive at specific frequencies (e.g. speech and crying babies, and probably any resonant frequencies of our skull). For another, sharp/percussive peaks tend to be perceived as quieter (or at least less annoying!) than equal-volume sustained tones. So compressing a drumset beat and some attorney's voice to the same "average" range means that the music will sound quieter than the advertisement. So whether CALM normalizes at the broadcaster or at the end-user, it should be strictly better because its measurement more accurately models perception and should have less error inherently.
Also, piling in against the free-market spin doctor: broadcasters are granted a form of monopoly due to limited resources for transmission. They should be regulated and hand-slapped for what appears to be blatant disregard for their government-granted customer base.
Having the most money does indeed enable price manipulation (the guy with the widest stop-limits an deepest margin accounts wins in a game of chicken). But what on earth makes you think that trading faster allows one to "set the price"?
I'll admit that I hadn't thought of building bittorrent into the client; mainly because most residential-grade connections have relatively terrible upstream bandwidth. I can see this working for recent material in metropolitan areas where peers are nearby and upstream bandwidth is plentiful. I don't think it would be effective out in the boonies, and I could see the lack of peers being problematic for less-popular content. But it would definitely be worth a shot for someone like Netflix to try!
No, that's not what I mean. Bandwidth for broadcast material can be sized without regard to downstream behavior. When they send so many channels to your cable box, the less popular channels get heavier compression, but they know exactly what throughput they need to provision. With on-demand content, they have to guess. And if they guess wrong, latency shoots through the roof and everyone gets a big fat "buffering" screen instead of their program at peak hours. It's not about artificial costs due to bandwidth caps*, it's about a real and unavoidable difference in the data-stream. Grind your axe somewhere else, AC.
* Artificial scarcity for reasonable-latency bandwidth is indeed a bad thing for the 'net and content distribution in general. But it has nothing to do with my argument that bandwidth or storage requirements are fundamentally higher for an on-demand system than they are for a broadcast system.
While I agree with you in principle, your particular example is quite ironic. I would expect a candidate with 5 years of Perl experience to jump straight to PDO for database access, owing to its similarity to DBI. OTOH, I would bet that many PHP programmers are still using mysql_real_escape_string_and_what_does_addslashes_do() in a quagmire of dynamically-generated SQL and blacklist-based regexes (regices?) for data validation.
I have smart friends, too. I also know some guys that grew up on C, and now code C++ like it's some horrible bastard-child of C and Java*. Sure, it works, but it ain't pretty. Knowing the Turing model is very different from knowing the effective idioms of a language.
* The verbosity of Java, the manual resource management of C, and the performance of neither.
Yes there is. Bandwidth and storage (caching) capacity can be sized according to the source, regardless of the number of consumers. If all content is on-demand, then either redundant data needs to flow from the source, substantial caching infrastructure needs to be set up, or consumers must plan ahead for material to be available (i.e. starting content in 10-minute timeslices). All are feasible plans, but none is a free lunch.
Maybe you wouldn't have 70 channels of mostly crap if content were priced for the public without hidden advertising subsidies. Many niche channels and programs survive now only because of bundling practices; they would either die or move to Internet-only distribution.
Hey, some of us enjoy Perl!
You had better update your fictional URLs, then. The fine manual (RFC 2606) does not list .web as a reserved name.
https://TubeSteak:hunter2@tickets:8080/
How is that less ridiculous? Who uses the Internet and doesn't associate http:// with the WWW already???
On a more ridiculous note, maybe now someone can finally get cracking on a web presence for Dillon Edwards Investments.
No, it's clearly an extension of the postfix increment operator. The expression a** returns the current value of a and as a side effect executes a *= 1. Because it requires a copy, in most cases you should use **a instead.
You don't need the source to trace system calls and network packets. Even if Opera were to phone home using some nefarious mechanism that fell through the cracks of strace and ltrace, it would still be detectable by a packet sniffer. Much like the "many eyes" hypothesis works to give people confidence on source code access, it should also apply here. If a bored nerd discovered something like this on the weekend, news would spread across tech sites like wildfire.
FTFY :)
For starters, you should disable Session Restore and the Awesome Bar. Both of these features are 'auto-saving' and probably require I/O. I would then start experimenting with something like strace -e trace=sync,fsync,fdatasync and looking at stack traces to find further configuration options which can be disabled. Disclaimer: I have not tried this, as I don't have a Linux desktop at the moment. You may need to use ltrace for fsync/fdatasync.
Yes, the ToS is quite clear about the ramifications of using (or ignoring) privacy controls. However, because the license is transferable, many users may have accidentally granted this permission while futzing with privacy settings. This particular license terminates, but what if Facebook automatically transfers the license to some wholly-owned subsidiary upon posting? IANAL so maybe I'm missing something, but it sounds like a back door the size of a Mack truck.
Yes, laptop_mode is exactly the scenario to which I refer when I say "hours". That's of course where the syncs are the most expensive, as well. I ran into this don't fear the fsync discussion on the topic years ago, but it seems that the original site is dead.