Simple. Doing taxes is stressful. The tax code is confusing. The IRS is feared. Generally, people will avoid doing things which are unpleasant, and doing taxes is doubly so because of the fear involved. Perhaps you simply don't suffer from any anxiety about the process, or have better-than-average coping skills.
No. It's a lossy transform (you're replacing information), so there's no inverse function. It might be possible to detect artifacts of the original transform, and so it's possible you could apply an estimated inverse transform to simulate the original input signal, but it wouldn't be perfect restoration by a long shot.
I agree with most of what you posted, but I am curious why is there a want/need to define a norm. Can't each family choose for itself how it promotes its offspring toward adulthood?
You make a good point about the power of a single executive to do serious harm to a project/team. I experienced this myself a few years back; a particular VP of "Business Development" required us to work with a favored vendor of his choosing. Despite any and all evidence to show they were neither interested in nor capable of delivering their part of the solution, we were strictly forbidden to solicit competitive proposals. I suspected kickbacks were part of the reason but could not prove it.
This is a real weakness of many companies that have fallen into the common trap of allowing personal relationships at the executive level to dominate business decisions. A lot of short-term thinking based on ego and this year's bonus. Since the typical executive severance is what an engineer makes in two or more years, it's really not a problem for them to run companies into the ground and hop from enterprise to enterprise.
Define "Real World". There are plenty of people who are quite capable of living full and meaningful lives while maintaining social networks that primarily involve their churches and families. There is no evidence that the poster is going to prevent them from making their own choices as adults. You show you are biased against their right to self-determination by assuming you have the only valid concept of "Real World".
It has been shown (I can't google the study right now) that people in senior management have a much higher incidence of sociopathic and psychopathic behavior than the general population. If your management insists on rules for others that they don't follow themselves, and consciously flout, they may fall into that group. In that case, keep your resume and interview skills up-to-date.
And of course it's not as though the user of the weapon can guarantee the firing effect won't harm bystanders, or for that matter, kill the perpetrator (in the unlikely event he has a pacemaker).
And with what we've learned from the "non-lethal" taser, police are far more likely to use it liberally, essentially upping the chances of accidental deaths.
It's already becoming illegal to fortify your home against invasion. The justification is that no one who's not doing something illegal has a reason to fear no-knock forced entry from the police/ATF/FBI/DHS.
I found it so superb in my Unix hacking, I found one for Windows and now use this font in VisualStudio and other Windows apps (i.e. Notepad), as it is WORLDS better than Microsoft's default of courier. Any place I don't have this font, I will spend a lot of time to try and get it. The clarity and information density is superior to even the Proggy font family.
One frustration has been getting this to work under Cygwin/X; for some reason there seems to be some font magic w/ Gtk apps that try to scale or use a font differently than specified, so when I start gvim under Cygwin/X I get a short, uglier version of 6x13 (perhaps it's 6x12? Ever see this? Solution?
You got it right.
When you had to be closely associated with your community just to get by everyone knew your business. You were accountable to your family because if you were unreliable in paying your bills, etc., your family would suffer. The general store owner couldn't check your credit rating, he had to know you personally or have someone vouch for you to extend you credit. In many cases you wouldn't ever have lived alone; no extended period in your 20s with no one to answer to where you could do things considered "inappropriate" by your family.
Privacy was something that existed briefly when economic conditions permitted it in a few wealthy societies. Even today, my lower-class Mexican neighbors live 10 to a house that a typical middle-class white family would consider appropriate for 4 or 5. Do you think adolescents in 1100 sq. foot house have a reasonable expectation of privacy? Nope.
You're right, of course. But since we'll never be able to prove that letting the bad debt be liquidated and asset prices come back to natural (i.e. not easy-money inflated) levels would have worked, we'll have to listen to the Keynesians tell us how they saved us all from a fate worse than the inflationary depression they just caused, and watch them teach the next generation of public school victims the glories of printed money.
Government power is always purchased by those with the most money. So the only way to reduce corporate power through government is to reduce government power.
Why was this modded flamebait? That's ridiculous. He's right on target: science and engineering are related, but distinct, disciplines.
Engineering is the process of taking the outputs of science (research and development) and making it work it the real world. There is a huge difference between the personality type that can creatively solve a difficult and potential novel or unique problem and the a personality that can make that solution repeatable and low-cost in the real world.
Actually, no, it [their attempt] didn't work. That's why I had to rewrite it. It crashed constantly--see my notes on performance and reliability--no system running at 80% system load is properly designed, you should generally see at least 75% user load on a cpu-saturated system.
The mistake they made was trying to be too clever, and create a bunch of nifty framework classes that were interesting in theory but added unnecessary lines of code, genericity, and confusion. The advantage I had was that I was trying to solve a specific problem, instead of create a new framework.
I'm not criticizing MIT grads, grad students in general, or anything like that. I'm criticizing any developer who makes things more complicated than they need to be. In this case there was a very specific problem: take some low-level i/o data and make it available to multiple clients in real time. It did not warrant 20K lines of C++; yeah, I probably seem rather stuck-up about it, but what I'm proud of is that I kept the design simple enough I could implement it properly. They were so in love with their cleverness they failed to do that.
Ok, you got me. Seriously, though, I doubt I would have done as good a job if I wrote it in C++ and tried to do it in an OO paradigm, because that's harder to do well than to write simple procedural code. So to the point of the original story, C++ is an extremely sophisticated language, and assuming you can do everything better in C++ is only true if you're an expert C++ programmer. Likewise if you want to do things in any other language or paradigm for that matter.
I forget where I saw it, but I read once that a study was done where a group of programmers were using Haskell or Eiffel to dome some project X. And they kicked butt. So another study was done, and everybody expected that the same results would be shown, and it would prove Haskell/Smalltalk/Eiffel was going to be the solution to all software engineering problems.
The second time around the project took the same time and had the same defect rate as with a team doing it in C. What they found was that the first team were expert programmers, highly trained in the language in question, and the result was an artifact of that detail, not of the language.
So since I was doing C in a highly idiomatic way, and it was something that I was comfortable with, I succeeded. The C++ guys were trying to do too much with their code, and failed. I see a lot of that. KISS.
Unfortunately, the C++ programmer who writes bad C++ code is more common than the C++ programmer who writes good C++, and the bad C++ is probably harder to rework than bad php.
I once rewrote a bit of software that some MIT grads did. Theirs was 20K lines of C++, used 110 MB ram (constantly newing and deleting), used dozens of threads (constantly spawning and harvesting), and drove the system to its knees (90% system, 10% user load). My 2K (yes, one-tenth) lines of straight C used 5 threads (preallocated), a configurably preallocated ring buffer (about 100K in practice), and used less than 5% of user time with no measurable system load. And I was able to do this adding functionality and improving the reliability. Very few defects in 2000 lines of C.
The moral of the story is that C++ is complex, and even really smart people can do awful things with it. And the awful things really smart people do are worse than the awful things average or below-average people do. The programmer should use the tool he knows best, and if the tool isn't the right one, learn it, or let someone else do it.
Mono only runs on PC hardware. If you're running Solaris, AIX, HPUX, you're out of luck. A lot of shops could migrate to Mono more easily if it were multiplatform, but it's not.
I was troubleshooting problems with in-network (copper connected) equipment we sold ATT a few years ago (2005-ish). They repeatedly tried to blame us for the intermittent service issues, and we were pretty sure we narrowed it down to some kind of transport problem (i.e. their T-carrier backhaul from the towers).
After incredible resistance, we finally convinced them we'd admit it was our fault if they ran a specific line test (basically sending a lot of zeroes to test they were properly provisioned for data and not just voice) and it came back clean. They ran the test, and while it was silent on the other side of the conference call (we couldn't see the test results as it ran), we noticed everything started mysteriously turning green (all our intermittent drop-outs stopped). They made up some story about us changing configuration on their network (impossible) while we KNEW they were re-provisioning their copper to transmit data, as we'd suspected they should have done weeks before. They claimed that publicly so they could avoid taking responsibility for the network outages, which would have impacted their management performance numbers.
What I learned was that ATT has a culture of blaming everyone else and not fixing the problem. This is not a new thing.
Both of these approaches (locality and abstraction) fail frequently. The inlining/cut&paste approach to locality I don't need to explain.
Where the abstractions fail (and I see this more and more) is when the hot shot abstracts out the lower-level "dumb" classes but also mixes in assumptions about how they'll be used by the higher-level classes.
What you end up with is a rigid, inflexible, unmodifiable framework that forces the user (i.e. the programmer extending or re-using the framework code) to build the application the same way the original programmer did. I mean to the extent that the "abstracted" configuration class has to be used so you can use some element of the application framework, which means you also need to pull in the framework's persistence model, etc., etc...
The six-times reuse is much easier to achieve when you provide truly clean abstractions in the framework which promote reusing a small piece of the the framework without forcing the whole thing down the user's throat. It's much better since someone on a tight deadline can use what he needs, get the reuse, and maybe come back later for more.
Right on. The amortization of development costs is overlooked when people forget about the integration and test work that needs to be done. FCC approval alone is well beyond the means of a typical OSS team.
I'm not saying at all that computers can't or shouldn't be used in music. I'm saying that based on the input devices being used, and from what I can guess about the methodology used based on the video I watched, there's no way this system can be used to do things of comparable sophistication to what you'd get from a symphony orchestra.
After all, they are calling this a Linux laptop orchestra.
Of course computers are wonderful tools for composers who want to produce orchestral music but don't have the budget to pay a symphony orchestra to experiment with arrangement.
In fact, you made my point for me--a keyboard that would use midi or sampling to simulate an instrument is already a far better input device than these Wii controllers. Any serious musician will take the time to learn piano, to take advantage of its superior capabilities.
I'm not saying the computer's the problem. I'm saying that a Wii controller is not going to give the level of detailed I/O required to take advantage of the capabilities you describe.
It's IO bound. A flute player can alter the tone quality produced by changing their oral orifice from oval to circular, in addition to breath speed, vibrato, airflow angle against the flute, and then the notes being played.
And that's ONE instrument out of about a hundred. The video on their site showed about 6 people waving WiiMotes around. The WiiMote is not comparable to an actual physical interface to a real acoustic instrument and can't provide the richness of expression.
It's an interesting idea and may have beneficial applications for entertainment, music therapy or childhood education, but I don't see much potential for any real [read artistic] musical applications. Excepting, possibly, interactive performance art or something.
The richness of a real symphony orchestra's sound is tied to the complexity and expertise of about a hundred different musicians at levels of superb mastery working together as individuals to recreate and interpret a composer's vision. I don't see how it would be possible to do anything different from the already tired new-agey synthesizer muzak with a tool like this. Of course I feel similarly about replacing the big band with an electric guitar.
You can install RPMs as non-root by modifying the.rpmmacros file in your home directory and set dbpath to relocate the rpm database. Provided you manage dependencies (there are tricks to this) and install to a location you have write access to, this is a good and safe way to use RPM as non-root.
If a frontend were properly set up to allow this, and packages were made relocatable by default, it would work well.
In the case you describe, it's absolute the Right Thing to do to get the business. It doesn't mean you can't also follow up later.
It's a problem when a salesperson with a small (to the company's overall revenue) contract demands a feature to close a deal that costs more to implement than the overall revenue. to the salesperson it makes sense, because they get substantial benefit from the commission. The company suffers, though, if product management doesn't see that the behavior is costing them the ability to go after additional market share (due to lost engineer time).
Slashdot Mirror
Simple. Doing taxes is stressful. The tax code is confusing. The IRS is feared. Generally, people will avoid doing things which are unpleasant, and doing taxes is doubly so because of the fear involved. Perhaps you simply don't suffer from any anxiety about the process, or have better-than-average coping skills.
No. It's a lossy transform (you're replacing information), so there's no inverse function. It might be possible to detect artifacts of the original transform, and so it's possible you could apply an estimated inverse transform to simulate the original input signal, but it wouldn't be perfect restoration by a long shot.
I agree with most of what you posted, but I am curious why is there a want/need to define a norm. Can't each family choose for itself how it promotes its offspring toward adulthood?
You make a good point about the power of a single executive to do serious harm to a project/team. I experienced this myself a few years back; a particular VP of "Business Development" required us to work with a favored vendor of his choosing. Despite any and all evidence to show they were neither interested in nor capable of delivering their part of the solution, we were strictly forbidden to solicit competitive proposals. I suspected kickbacks were part of the reason but could not prove it.
This is a real weakness of many companies that have fallen into the common trap of allowing personal relationships at the executive level to dominate business decisions. A lot of short-term thinking based on ego and this year's bonus. Since the typical executive severance is what an engineer makes in two or more years, it's really not a problem for them to run companies into the ground and hop from enterprise to enterprise.
Define "Real World". There are plenty of people who are quite capable of living full and meaningful lives while maintaining social networks that primarily involve their churches and families. There is no evidence that the poster is going to prevent them from making their own choices as adults. You show you are biased against their right to self-determination by assuming you have the only valid concept of "Real World".
It has been shown (I can't google the study right now) that people in senior management have a much higher incidence of sociopathic and psychopathic behavior than the general population. If your management insists on rules for others that they don't follow themselves, and consciously flout, they may fall into that group. In that case, keep your resume and interview skills up-to-date.
And of course it's not as though the user of the weapon can guarantee the firing effect won't harm bystanders, or for that matter, kill the perpetrator (in the unlikely event he has a pacemaker).
And with what we've learned from the "non-lethal" taser, police are far more likely to use it liberally, essentially upping the chances of accidental deaths.
http://www.tulsabeacon.com/?p=3269
You couldn't be more right!
I found it so superb in my Unix hacking, I found one for Windows and now use this font in VisualStudio and other Windows apps (i.e. Notepad), as it is WORLDS better than Microsoft's default of courier. Any place I don't have this font, I will spend a lot of time to try and get it. The clarity and information density is superior to even the Proggy font family.
One frustration has been getting this to work under Cygwin/X; for some reason there seems to be some font magic w/ Gtk apps that try to scale or use a font differently than specified, so when I start gvim under Cygwin/X I get a short, uglier version of 6x13 (perhaps it's 6x12? Ever see this? Solution?
You got it right. When you had to be closely associated with your community just to get by everyone knew your business. You were accountable to your family because if you were unreliable in paying your bills, etc., your family would suffer. The general store owner couldn't check your credit rating, he had to know you personally or have someone vouch for you to extend you credit. In many cases you wouldn't ever have lived alone; no extended period in your 20s with no one to answer to where you could do things considered "inappropriate" by your family. Privacy was something that existed briefly when economic conditions permitted it in a few wealthy societies. Even today, my lower-class Mexican neighbors live 10 to a house that a typical middle-class white family would consider appropriate for 4 or 5. Do you think adolescents in 1100 sq. foot house have a reasonable expectation of privacy? Nope.
You're right, of course. But since we'll never be able to prove that letting the bad debt be liquidated and asset prices come back to natural (i.e. not easy-money inflated) levels would have worked, we'll have to listen to the Keynesians tell us how they saved us all from a fate worse than the inflationary depression they just caused, and watch them teach the next generation of public school victims the glories of printed money.
Government power is always purchased by those with the most money. So the only way to reduce corporate power through government is to reduce government power.
Why was this modded flamebait? That's ridiculous. He's right on target: science and engineering are related, but distinct, disciplines.
Engineering is the process of taking the outputs of science (research and development) and making it work it the real world. There is a huge difference between the personality type that can creatively solve a difficult and potential novel or unique problem and the a personality that can make that solution repeatable and low-cost in the real world.
Actually, no, it [their attempt] didn't work. That's why I had to rewrite it. It crashed constantly--see my notes on performance and reliability--no system running at 80% system load is properly designed, you should generally see at least 75% user load on a cpu-saturated system.
The mistake they made was trying to be too clever, and create a bunch of nifty framework classes that were interesting in theory but added unnecessary lines of code, genericity, and confusion. The advantage I had was that I was trying to solve a specific problem, instead of create a new framework.
I'm not criticizing MIT grads, grad students in general, or anything like that. I'm criticizing any developer who makes things more complicated than they need to be. In this case there was a very specific problem: take some low-level i/o data and make it available to multiple clients in real time. It did not warrant 20K lines of C++; yeah, I probably seem rather stuck-up about it, but what I'm proud of is that I kept the design simple enough I could implement it properly. They were so in love with their cleverness they failed to do that.
Ok, you got me. Seriously, though, I doubt I would have done as good a job if I wrote it in C++ and tried to do it in an OO paradigm, because that's harder to do well than to write simple procedural code. So to the point of the original story, C++ is an extremely sophisticated language, and assuming you can do everything better in C++ is only true if you're an expert C++ programmer. Likewise if you want to do things in any other language or paradigm for that matter.
I forget where I saw it, but I read once that a study was done where a group of programmers were using Haskell or Eiffel to dome some project X. And they kicked butt. So another study was done, and everybody expected that the same results would be shown, and it would prove Haskell/Smalltalk/Eiffel was going to be the solution to all software engineering problems.
The second time around the project took the same time and had the same defect rate as with a team doing it in C. What they found was that the first team were expert programmers, highly trained in the language in question, and the result was an artifact of that detail, not of the language.
So since I was doing C in a highly idiomatic way, and it was something that I was comfortable with, I succeeded. The C++ guys were trying to do too much with their code, and failed. I see a lot of that. KISS.
Unfortunately, the C++ programmer who writes bad C++ code is more common than the C++ programmer who writes good C++, and the bad C++ is probably harder to rework than bad php.
I once rewrote a bit of software that some MIT grads did. Theirs was 20K lines of C++, used 110 MB ram (constantly newing and deleting), used dozens of threads (constantly spawning and harvesting), and drove the system to its knees (90% system, 10% user load). My 2K (yes, one-tenth) lines of straight C used 5 threads (preallocated), a configurably preallocated ring buffer (about 100K in practice), and used less than 5% of user time with no measurable system load. And I was able to do this adding functionality and improving the reliability. Very few defects in 2000 lines of C.
The moral of the story is that C++ is complex, and even really smart people can do awful things with it. And the awful things really smart people do are worse than the awful things average or below-average people do. The programmer should use the tool he knows best, and if the tool isn't the right one, learn it, or let someone else do it.
Mono only runs on PC hardware. If you're running Solaris, AIX, HPUX, you're out of luck. A lot of shops could migrate to Mono more easily if it were multiplatform, but it's not.
I was troubleshooting problems with in-network (copper connected) equipment we sold ATT a few years ago (2005-ish). They repeatedly tried to blame us for the intermittent service issues, and we were pretty sure we narrowed it down to some kind of transport problem (i.e. their T-carrier backhaul from the towers).
After incredible resistance, we finally convinced them we'd admit it was our fault if they ran a specific line test (basically sending a lot of zeroes to test they were properly provisioned for data and not just voice) and it came back clean. They ran the test, and while it was silent on the other side of the conference call (we couldn't see the test results as it ran), we noticed everything started mysteriously turning green (all our intermittent drop-outs stopped). They made up some story about us changing configuration on their network (impossible) while we KNEW they were re-provisioning their copper to transmit data, as we'd suspected they should have done weeks before. They claimed that publicly so they could avoid taking responsibility for the network outages, which would have impacted their management performance numbers.
What I learned was that ATT has a culture of blaming everyone else and not fixing the problem. This is not a new thing.
Some good points.
Both of these approaches (locality and abstraction) fail frequently. The inlining/cut&paste approach to locality I don't need to explain.
Where the abstractions fail (and I see this more and more) is when the hot shot abstracts out the lower-level "dumb" classes but also mixes in assumptions about how they'll be used by the higher-level classes.
What you end up with is a rigid, inflexible, unmodifiable framework that forces the user (i.e. the programmer extending or re-using the framework code) to build the application the same way the original programmer did. I mean to the extent that the "abstracted" configuration class has to be used so you can use some element of the application framework, which means you also need to pull in the framework's persistence model, etc., etc...
The six-times reuse is much easier to achieve when you provide truly clean abstractions in the framework which promote reusing a small piece of the the framework without forcing the whole thing down the user's throat. It's much better since someone on a tight deadline can use what he needs, get the reuse, and maybe come back later for more.
Right on. The amortization of development costs is overlooked when people forget about the integration and test work that needs to be done. FCC approval alone is well beyond the means of a typical OSS team.
I'm not saying at all that computers can't or shouldn't be used in music. I'm saying that based on the input devices being used, and from what I can guess about the methodology used based on the video I watched, there's no way this system can be used to do things of comparable sophistication to what you'd get from a symphony orchestra.
After all, they are calling this a Linux laptop orchestra.
Of course computers are wonderful tools for composers who want to produce orchestral music but don't have the budget to pay a symphony orchestra to experiment with arrangement.
In fact, you made my point for me--a keyboard that would use midi or sampling to simulate an instrument is already a far better input device than these Wii controllers. Any serious musician will take the time to learn piano, to take advantage of its superior capabilities.
I'm not saying the computer's the problem. I'm saying that a Wii controller is not going to give the level of detailed I/O required to take advantage of the capabilities you describe.
It's IO bound. A flute player can alter the tone quality produced by changing their oral orifice from oval to circular, in addition to breath speed, vibrato, airflow angle against the flute, and then the notes being played.
And that's ONE instrument out of about a hundred. The video on their site showed about 6 people waving WiiMotes around. The WiiMote is not comparable to an actual physical interface to a real acoustic instrument and can't provide the richness of expression.
It's an interesting idea and may have beneficial applications for entertainment, music therapy or childhood education, but I don't see much potential for any real [read artistic] musical applications. Excepting, possibly, interactive performance art or something.
The richness of a real symphony orchestra's sound is tied to the complexity and expertise of about a hundred different musicians at levels of superb mastery working together as individuals to recreate and interpret a composer's vision. I don't see how it would be possible to do anything different from the already tired new-agey synthesizer muzak with a tool like this. Of course I feel similarly about replacing the big band with an electric guitar.
You can install RPMs as non-root by modifying the .rpmmacros file in your home directory and set dbpath to relocate the rpm database. Provided you manage dependencies (there are tricks to this) and install to a location you have write access to, this is a good and safe way to use RPM as non-root.
If a frontend were properly set up to allow this, and packages were made relocatable by default, it would work well.
In the case you describe, it's absolute the Right Thing to do to get the business. It doesn't mean you can't also follow up later.
It's a problem when a salesperson with a small (to the company's overall revenue) contract demands a feature to close a deal that costs more to implement than the overall revenue. to the salesperson it makes sense, because they get substantial benefit from the commission. The company suffers, though, if product management doesn't see that the behavior is costing them the ability to go after additional market share (due to lost engineer time).