Too bad folks haven't done the whole mass shotgun extinction trick with the European starlings. You've never seen such a mess as when a flock of those things descends on your yard. There's something inherently wrong about looking out at your yard and seeing nothing but black where the grass should be, because they've completely blotted out the ground. And the next morning, your sidewalk is practically solid white with bird crap. Just disgusting. I don't think "invasive species" quite covers it.:-)
Question: Is pulling over for 30 seconds to reprogram your toy really that big a deal?
When you're driving along an interstate and are trying to figure out what exit has food, yes. Yes, it is. There's no valid reason not to allow a passenger to change the destination while the vehicle is in motion. It's an unnecessary safety misfeature that reduces usability while providing no benefit whatsoever. (The in-dash GPS is pretty much useless for the driver anyway, because it isn't readily visible, and there's no way that any driver could feasibly program it while driving, so if somebody is reprogramming it while the vehicle is in motion, it is almost guaranteed to be a passenger, not the driver.)
There are still plenty of effects in real pianos that are not emulated properly. Two examples: resonances in the other strings of the piano when you strike a string, and striking a key, leaving it half-pressed, and striking again. The piano pedals are also not easy to emulate, I understand, but I don't know the details.
No question about it. There are things I can do on a grand that I can't do on any synth that I've tried. One trick I like to do is bell tones, where you give it just enough sustain pedal to get a little bit of ring and then play semi-staccato. That falls pretty soundly under "extended techniques", of course. In principle, it shouldn't be hard to make a software synth that can emulate that behavior, just by using a volume pedal instead of an on-off switch for the sustain pedal, and writing the software to model the instrument's behavior sufficiently. AFAIK, nobody has done it, though.
For that matter, I have yet to hear one that emulates the extra richness you get from a piano when you push the sustain pedal, but I haven't used any recent piano VIs, so I'd imagine somebody has done it by now, given how trivial it should be to emulate.
Either way, digital simulations of pianos are good enough to be generally usable. That's more than can be said for any digital brass I've heard to date. For example, consider the Garritan family of trombone sounds. Despite the fact that pretty much any normal tenor trombone played by any professional (and most high school and college students, statistically) has an F rotor, none of their trombone sounds go down below an E except the bass trombone stop, which makes them all almost completely and utterly useless for real-world use, where non-bass trombone parts routinely drop into that range.
The bass trombone stop has the range, but unfortunately, it has a very slow attack (which is somewhat realistic for larger bore trombones, mind you). To sound correct, the player should compensate for the slow attack and should play slightly ahead of the beat like a real trombone player does. Unfortunately, it doesn't, and as a result, in fast music, it ends up playing a quarter beat behind the rest of the ensemble, and it sounds like utter crap.
And those are just the problems that are bad enough that even the most tone-deaf person would notice them if you didn't work around them. Compared to that, getting a "mostly good enough" piano sound is easy.:-)
True, and it also depends a lot on how thick the orchestration is. In the middle of a dense mix, I'd be hard-pressed to tell the difference between the real thing and a virtual instrument. In a solo passage over thin orchestration, the difference is usually glaringly obvious, at least to people who have spent any significant amount of time listening to the real thing.
BTW, what does a cimbasso sound like? I'm guessing it's a lot like a bass trombone, just judging by the shape of the tubing. No?
Even during a deep traversal, AFAIK, it is just using modification information in the filesystem, not reading the entire file. Otherwise, a deep traversal would take as long as a full backup (days) instead of a tiny fraction of that time.
Now if the length of the file changes because of filesystem corruption, that's another matter.
None of those things qualify as "extended techniques" except the pitch bends, multiphonics, and lip slurs. Everything else is stuff we instrumentalists do every day, in pretty much every piece, sometimes because the director says, "Could we make that a bit brighter/more brassy," but more often, intuitively, based on what's happening in other parts, without any notation to guide us.
That's why it is always almost immediately obvious whether a brass recording was done with real instruments or synths, even with really good sample sets. The sample sets just can't reproduce the richness of a real-world performance.
Okay, maybe not for trumpet punctuation in a pop song, but....
Even in art music this is a noticeable trend. I'm active in classical music fora and filesharing circles, and I'm amazed at how many fans with many hundreds or thousands of CDs have no interest in going to the concert hall, because they are more comfortable in how classical music sounds off a CD or FLAC download (for example, a solo violin or cello in a concerto will likely be mixed louder on a disc than it sounds in live performance).
Don't blame the CD. Blame the soloist who refuses to be miked during the live gig.
Remember when drum machines threatened to put all drummers out of work?
And now, a rather large percentage of modern music uses at least some sampled drums. Mind you, it is often triggered by an actual drummer, though not always.
And the reality of the matter is that digital instruments do a good job of replicating piano, organ and other keyboard instruments. They can also do a halfway decent job with mallet-based percussion. However, it really isn't feasible to digitally replicate the sound of non-percussive instruments like brass and woodwinds, because there are simply too many different things that a real instrument player can do to change the quality of the sound. For example, when playing a brass instrument, you can:
Vary the position and tightness of the lips and jaw to change the tone to be brighter or more mellow
Start and stop notes with anything from crisp tonguing all the way down to "lip tonguing", resulting in radically different attacks and cutoffs
Lip slur between notes instead of tonguing
Vary the volume of a single note arbitrarily while you're playing it
Vary the pitch while you're playing it
Sing while you play a note (multiphonics)
And so on. There's simply no feasible way for software to simulate all those different variables without modeling the entire instrument, and even if you did that, you'd have to have a much more complex input controller than keyboards or wind controllers or any other MIDI input device that currently exists. By the time you've learned to play something as complex as that, you'll probably find that it's easier to learn to play the actual instrument.:-)
Depends on the backup methodology. If your backup works the way Apple's backups do, e.g. only modified files get pushed into a giant tree of hard links, then there's a good chance the corrupted data won't ever make it into a backup, because the modification wasn't explicit. Of course, the downside is that if the file never gets modified, you only have one copy of it, so if the backup gets corrupted, you have no backup.
So yes, in an ideal world, the right answer is proper block checksumming. It's a shame that neither of the two main consumer operating systems currently supports automatic checksumming in the default filesystem.
Doesn't the merchant have to send the imprint to the CC company (who presumably shreds them)? Or do you mean the carbon copy that they give you? Because that's the customer's problem. Also, the newer slips don't imprint the full card number on the copy, IIRC.
A Google engineer that designed a web language no one wants to use much less need, gives a talk about how the web needs more languages.
Part of me wants to think the guy is just nuts but this is starting to seem like a trend from Google.
They try to create a many options/products as possible to weaken established standards and then take them over with half-assed efforts that never work out.
Even ignoring whether you trust Google to stand behind anything they throw out there, we really don't need more languages for web programming. JavaScript might have a few things that make it quirky, but it isn't a particularly difficult language to learn, and there's no compelling reason to use anything else.
The part of web app development that sucks isn't the language. It's the API. The HTML/XML DOM is a horrible way to design a UI, and browsers implement lots of things in different and inconsistent ways. For example, I once built a website that uses the HTML editing API, and found myself repeatedly adding piles of browser-specific workarounds. The worst was Internet Explorer, and it was such a nightmare that I basically gave up trying to make it fully work. But both Firefox and WebKit had serious bugs, most of which have still not been fixed (though a few of them have at least been fixed in Google's fork).
And that's the tip of the iceberg. While doing design work for an EPUB book, I found such fascinating bugs as:
Safari/WebKit uses incorrect font metrics for web fonts, resulting in positioning being off by a couple of pixels (fixed in Google's Chrome Canary fork)
Firefox/Gecko has a fascinating bug (989686) in which relatively positioned elements move around nondeterministically between reloads.
Almost every time I try to do anything significant with any browser (or with eBook readers based on browser engines), I end up filing five or six bugs against the browser, and although nearly all of them do get confirmed, within a small margin of error, none of them ever get fixed. All the while, these browsers keep getting new features, most of which are not fully implemented, most of which are just as fragile and buggy as the previous features that I filed bugs about, and we're trying to build apps on top of that mess. It's like developing for an early beta of an operating system, only the OS never gets out of beta.
That's what's wrong with writing apps on the web. The d**n browsers suck. They all range from horrible to utterly catastrophic. And that's me putting a positive spin on things. So before Google wastes a lot more time creating new languages that don't fix any real problem, thus adding yet another major browser feature that will only halfway work just like all the others, they and other web browser manufacturers need to take the time to fix the steaming dung heaps that they call browsers so that every single &^$@#(&^@ web programming project doesn't require me to spend 75% of my time working around browser bugs.
But what about a change in ownership of the patents? Company A goes bankrupt, company B buys the patent portfolio from the bankruptcy liquidation sale. To what extent is company A's agreement binding upon company B?
Sure, you could do that, but I'd expect any app that tried it to get low enough ratings that people would steer clear of it. After all, lots of tablet-like devices have an Internet connection only when you're at home or near another open Wi-Fi connection.
For those apps that absolutely demand access to something, then you should be able to fake it. So: the app that demands access to your address book, you give it one with a couple of bogus entries. It is my machine so I should get to choose what is allowed.
IIRC, that's basically what iOS/OS X does. If the user denies permission, the OS provides the app with an empty address book that (AFAIK) is indistinguishable from a device on which the user hasn't added any contacts.
Now let's talk about why those teachers stopped caring. There's almost always a bad boss behind every employee burnout. Like they always say: Those who can't do, teach. Those who can't teach become school administrators.:-D
Just to clarify, there are two reasons to favor a seniority-based approach for public institutions, not a random approach. A random approach would be silly.
Why would you ever terminate an employee "chosen at random"? The whole point of a reduction in force (laying off redundant employees) should be to get rid of the less productive|skilled|useful people, or to "rebalance" the pool of employees so the available skills meet the current needs. The teachers unions like selection by seniority, but the school district should want to use a merit system, assuming they want to end up with the best teachers.
Two reasons.
First, The newest employees are likely to be the least attached to their jobs. When you've been working somewhere for a decade or longer, your job is a big part of your life, and it really sucks to lose it. When you've been there for six months, it's tough to be without the income, but at least you aren't pulling up roots to the degree that you would be if you had three kids in school who had been going to that school for years, were involved in various activities, etc.
Second, the newest employees are the cheapest, because they tend to be at a higher pay scale. By requiring administrators to eliminate those jobs first, you avoid the temptation of cost cutting through age discrimination in layoffs—substituting three cheap, fresh-out-of-school hires for two senior hires to make budget.
University tenure is not absolute, either. Tenured professors who show up to classes drunk typically get put on administrative suspension for a period of time, and then if they don't get their act together when they return, they get summarily canned.
Even at the university level, tenure just means you can't terminate a teacher without cause. If a teacher fails to do the job, puts students in danger, touches students inappropriately, etc., tenure doesn't keep that teacher from being thrown out on his or her backside.
You're interpreting the number wrong. It isn't saying that only 1–14% of the material learned comes from the teachers. It's saying that only 1–14% of the test score delta between a typical high-scoring student and a typical low-scoring student is caused by differences in the quality of teaching—that socioeconomic factors play a much bigger role in that disparity, as does the degree of involvement of the parents in the children's education.
The lawsuit claimed that poor, minority students were disproportionately damaged by last-in first-out layoffs and early teacher tenure because newer teachers will take jobs in low income schools. So when they have to cut heads district-wide, poor schools get hit hardest. They can't lay off the worst teacher in the district, only the newest one.
That's fundamentally flawed logic at its most basic. Yes, the teachers at the poorer schools are in the worst position, but assuming the cuts are based on firing the newest teachers in the district, rather than on a per-school basis, those poorer schools end up in the best position.
When they have to cut heads, they can't just cut out all the teachers at the low-income schools, because they won't have enough teachers to cover the classes. There are laws limiting class sizes, and all students are guaranteed an education, so there's a lower bound on the number of teachers below which those schools cannot drop. Therefore, if they remove the newest teachers, that means that most of the teachers at the poorer schools are removed, but because those schools are likely at or near the lower bound already, nearly all of those removed teachers must be replaced by someone, and more to the point, by definition, they must be replaced by someone with more experience than the teacher who was removed. Usually, that means that the quality of education improves.
And in the general case, poorer students are likely to be stuck with worse teachers no matter what, because the best teachers are more likely to get jobs in better districts with better pay. Tenure has no real effect on that whatsoever....
The primary reason that this "tenure" exists is to provide some sort of fair treatment for teachers. Remember: Teachers in the grand majority of school districts aren't allowed to quit their job.
Just to clarify, they aren't allowed to quit their job during the school year. They're free to give notice on the second day of class, so long as they stay until the end of the year.:-)
It also protects teachers at higher pay scales from being fired just to free up budgeting money (something that many schools have done anyway).
This. Just compare the quality of education you get at a university with mostly tenured faculty versus a university where most of the courses are taught by adjuncts, and you'll quickly see why tenure is a good thing. There's a very real benefit to keeping the composition of your faculty fairly consistent from year to year, rather than having an endless stream of poorly paid instructors who are there for a quarter, then are replaced by somebody else the next quarter, etc.
Experienced, successful teachers know how to judge other teachers. Some of those teachers go on to become principals and administrators.
This. Ideally, every teacher should spend three or four planning periods per year observing another teacher in the same school (without prior notice). This has two benefits. First, it allows teachers to evaluate one another (and if done randomly, helps reduce the impact of bias by administrators or other formal evaluators). Second, it allows teachers to notice good and bad habits in other teachers and emulate or avoid them.
Slashdot Mirror
Too bad folks haven't done the whole mass shotgun extinction trick with the European starlings. You've never seen such a mess as when a flock of those things descends on your yard. There's something inherently wrong about looking out at your yard and seeing nothing but black where the grass should be, because they've completely blotted out the ground. And the next morning, your sidewalk is practically solid white with bird crap. Just disgusting. I don't think "invasive species" quite covers it. :-)
When you're driving along an interstate and are trying to figure out what exit has food, yes. Yes, it is. There's no valid reason not to allow a passenger to change the destination while the vehicle is in motion. It's an unnecessary safety misfeature that reduces usability while providing no benefit whatsoever. (The in-dash GPS is pretty much useless for the driver anyway, because it isn't readily visible, and there's no way that any driver could feasibly program it while driving, so if somebody is reprogramming it while the vehicle is in motion, it is almost guaranteed to be a passenger, not the driver.)
No question about it. There are things I can do on a grand that I can't do on any synth that I've tried. One trick I like to do is bell tones, where you give it just enough sustain pedal to get a little bit of ring and then play semi-staccato. That falls pretty soundly under "extended techniques", of course. In principle, it shouldn't be hard to make a software synth that can emulate that behavior, just by using a volume pedal instead of an on-off switch for the sustain pedal, and writing the software to model the instrument's behavior sufficiently. AFAIK, nobody has done it, though.
For that matter, I have yet to hear one that emulates the extra richness you get from a piano when you push the sustain pedal, but I haven't used any recent piano VIs, so I'd imagine somebody has done it by now, given how trivial it should be to emulate.
Either way, digital simulations of pianos are good enough to be generally usable. That's more than can be said for any digital brass I've heard to date. For example, consider the Garritan family of trombone sounds. Despite the fact that pretty much any normal tenor trombone played by any professional (and most high school and college students, statistically) has an F rotor, none of their trombone sounds go down below an E except the bass trombone stop, which makes them all almost completely and utterly useless for real-world use, where non-bass trombone parts routinely drop into that range.
The bass trombone stop has the range, but unfortunately, it has a very slow attack (which is somewhat realistic for larger bore trombones, mind you). To sound correct, the player should compensate for the slow attack and should play slightly ahead of the beat like a real trombone player does. Unfortunately, it doesn't, and as a result, in fast music, it ends up playing a quarter beat behind the rest of the ensemble, and it sounds like utter crap.
And those are just the problems that are bad enough that even the most tone-deaf person would notice them if you didn't work around them. Compared to that, getting a "mostly good enough" piano sound is easy. :-)
True, and it also depends a lot on how thick the orchestration is. In the middle of a dense mix, I'd be hard-pressed to tell the difference between the real thing and a virtual instrument. In a solo passage over thin orchestration, the difference is usually glaringly obvious, at least to people who have spent any significant amount of time listening to the real thing.
BTW, what does a cimbasso sound like? I'm guessing it's a lot like a bass trombone, just judging by the shape of the tubing. No?
Even during a deep traversal, AFAIK, it is just using modification information in the filesystem, not reading the entire file. Otherwise, a deep traversal would take as long as a full backup (days) instead of a tiny fraction of that time.
Now if the length of the file changes because of filesystem corruption, that's another matter.
I suppose it depends on the ensemble as to who says no. Either way, the problem is that someone says no. :-)
None of those things qualify as "extended techniques" except the pitch bends, multiphonics, and lip slurs. Everything else is stuff we instrumentalists do every day, in pretty much every piece, sometimes because the director says, "Could we make that a bit brighter/more brassy," but more often, intuitively, based on what's happening in other parts, without any notation to guide us.
That's why it is always almost immediately obvious whether a brass recording was done with real instruments or synths, even with really good sample sets. The sample sets just can't reproduce the richness of a real-world performance.
Okay, maybe not for trumpet punctuation in a pop song, but....
Only files modified by a vnode write operation.
Don't blame the CD. Blame the soloist who refuses to be miked during the live gig.
And now, a rather large percentage of modern music uses at least some sampled drums. Mind you, it is often triggered by an actual drummer, though not always.
This.
And the reality of the matter is that digital instruments do a good job of replicating piano, organ and other keyboard instruments. They can also do a halfway decent job with mallet-based percussion. However, it really isn't feasible to digitally replicate the sound of non-percussive instruments like brass and woodwinds, because there are simply too many different things that a real instrument player can do to change the quality of the sound. For example, when playing a brass instrument, you can:
And so on. There's simply no feasible way for software to simulate all those different variables without modeling the entire instrument, and even if you did that, you'd have to have a much more complex input controller than keyboards or wind controllers or any other MIDI input device that currently exists. By the time you've learned to play something as complex as that, you'll probably find that it's easier to learn to play the actual instrument. :-)
Depends on the backup methodology. If your backup works the way Apple's backups do, e.g. only modified files get pushed into a giant tree of hard links, then there's a good chance the corrupted data won't ever make it into a backup, because the modification wasn't explicit. Of course, the downside is that if the file never gets modified, you only have one copy of it, so if the backup gets corrupted, you have no backup.
So yes, in an ideal world, the right answer is proper block checksumming. It's a shame that neither of the two main consumer operating systems currently supports automatic checksumming in the default filesystem.
Doesn't the merchant have to send the imprint to the CC company (who presumably shreds them)? Or do you mean the carbon copy that they give you? Because that's the customer's problem. Also, the newer slips don't imprint the full card number on the copy, IIRC.
Even ignoring whether you trust Google to stand behind anything they throw out there, we really don't need more languages for web programming. JavaScript might have a few things that make it quirky, but it isn't a particularly difficult language to learn, and there's no compelling reason to use anything else.
The part of web app development that sucks isn't the language. It's the API. The HTML/XML DOM is a horrible way to design a UI, and browsers implement lots of things in different and inconsistent ways. For example, I once built a website that uses the HTML editing API, and found myself repeatedly adding piles of browser-specific workarounds. The worst was Internet Explorer, and it was such a nightmare that I basically gave up trying to make it fully work. But both Firefox and WebKit had serious bugs, most of which have still not been fixed (though a few of them have at least been fixed in Google's fork).
And that's the tip of the iceberg. While doing design work for an EPUB book, I found such fascinating bugs as:
Almost every time I try to do anything significant with any browser (or with eBook readers based on browser engines), I end up filing five or six bugs against the browser, and although nearly all of them do get confirmed, within a small margin of error, none of them ever get fixed. All the while, these browsers keep getting new features, most of which are not fully implemented, most of which are just as fragile and buggy as the previous features that I filed bugs about, and we're trying to build apps on top of that mess. It's like developing for an early beta of an operating system, only the OS never gets out of beta.
That's what's wrong with writing apps on the web. The d**n browsers suck. They all range from horrible to utterly catastrophic. And that's me putting a positive spin on things. So before Google wastes a lot more time creating new languages that don't fix any real problem, thus adding yet another major browser feature that will only halfway work just like all the others, they and other web browser manufacturers need to take the time to fix the steaming dung heaps that they call browsers so that every single &^$@#(&^@ web programming project doesn't require me to spend 75% of my time working around browser bugs.
But what about a change in ownership of the patents? Company A goes bankrupt, company B buys the patent portfolio from the bankruptcy liquidation sale. To what extent is company A's agreement binding upon company B?
Sure, you could do that, but I'd expect any app that tried it to get low enough ratings that people would steer clear of it. After all, lots of tablet-like devices have an Internet connection only when you're at home or near another open Wi-Fi connection.
IIRC, that's basically what iOS/OS X does. If the user denies permission, the OS provides the app with an empty address book that (AFAIK) is indistinguishable from a device on which the user hasn't added any contacts.
Now let's talk about why those teachers stopped caring. There's almost always a bad boss behind every employee burnout. Like they always say: Those who can't do, teach. Those who can't teach become school administrators. :-D
Just to clarify, there are two reasons to favor a seniority-based approach for public institutions, not a random approach. A random approach would be silly.
Two reasons.
First, The newest employees are likely to be the least attached to their jobs. When you've been working somewhere for a decade or longer, your job is a big part of your life, and it really sucks to lose it. When you've been there for six months, it's tough to be without the income, but at least you aren't pulling up roots to the degree that you would be if you had three kids in school who had been going to that school for years, were involved in various activities, etc.
Second, the newest employees are the cheapest, because they tend to be at a higher pay scale. By requiring administrators to eliminate those jobs first, you avoid the temptation of cost cutting through age discrimination in layoffs—substituting three cheap, fresh-out-of-school hires for two senior hires to make budget.
University tenure is not absolute, either. Tenured professors who show up to classes drunk typically get put on administrative suspension for a period of time, and then if they don't get their act together when they return, they get summarily canned.
Even at the university level, tenure just means you can't terminate a teacher without cause. If a teacher fails to do the job, puts students in danger, touches students inappropriately, etc., tenure doesn't keep that teacher from being thrown out on his or her backside.
You're interpreting the number wrong. It isn't saying that only 1–14% of the material learned comes from the teachers. It's saying that only 1–14% of the test score delta between a typical high-scoring student and a typical low-scoring student is caused by differences in the quality of teaching—that socioeconomic factors play a much bigger role in that disparity, as does the degree of involvement of the parents in the children's education.
That's fundamentally flawed logic at its most basic. Yes, the teachers at the poorer schools are in the worst position, but assuming the cuts are based on firing the newest teachers in the district, rather than on a per-school basis, those poorer schools end up in the best position.
When they have to cut heads, they can't just cut out all the teachers at the low-income schools, because they won't have enough teachers to cover the classes. There are laws limiting class sizes, and all students are guaranteed an education, so there's a lower bound on the number of teachers below which those schools cannot drop. Therefore, if they remove the newest teachers, that means that most of the teachers at the poorer schools are removed, but because those schools are likely at or near the lower bound already, nearly all of those removed teachers must be replaced by someone, and more to the point, by definition, they must be replaced by someone with more experience than the teacher who was removed. Usually, that means that the quality of education improves.
And in the general case, poorer students are likely to be stuck with worse teachers no matter what, because the best teachers are more likely to get jobs in better districts with better pay. Tenure has no real effect on that whatsoever....
Just to clarify, they aren't allowed to quit their job during the school year. They're free to give notice on the second day of class, so long as they stay until the end of the year. :-)
This. Just compare the quality of education you get at a university with mostly tenured faculty versus a university where most of the courses are taught by adjuncts, and you'll quickly see why tenure is a good thing. There's a very real benefit to keeping the composition of your faculty fairly consistent from year to year, rather than having an endless stream of poorly paid instructors who are there for a quarter, then are replaced by somebody else the next quarter, etc.
This. Ideally, every teacher should spend three or four planning periods per year observing another teacher in the same school (without prior notice). This has two benefits. First, it allows teachers to evaluate one another (and if done randomly, helps reduce the impact of bias by administrators or other formal evaluators). Second, it allows teachers to notice good and bad habits in other teachers and emulate or avoid them.