I decided long ago that the MySQL guys are clowns. MySQL's lack of features was never as big a problem as the fact that I just couldn't take these guys seriously (and the above is only a small subset of the reasons for that).
I notice that the course homepage talks about designing for an "idealised parallel computer" -- did it take into account the huge speed hit that comes from false sharing on real processors? That should be a major consideration if you are designing shared-memory parallel algorithms, since they can degrade performance by 1700% on modern processors. If you're not careful, your parallel algorithms could end up being much slower than single-threaded ones simply because they force so many cache bounces.
Not a flame, but did your prof say that good string (or other instrument performers) musicians are not a dime a dozen? Are any instruments considered to be more difficult than others?
Here are a couple thoughts on that question (which I think is an interesting one).
One is that different instruments attract different kinds of people. Extremely driven people tend to be attracted to Violin and Piano, so the fact that there are many fine violinists and pianists doesn't at all imply that they are easier. Trombonists and Violists tend to be a lot more laid back and quirky. There are lots of instrumentalist jokes that play on these stereotypes.
Another thing to mention: the best pianists at my college practically never left the music building. They practiced all the time. To contrast, the best clarinet player at my school practiced very little.
I think piano is challenging in a different way than most instruments. Pianists play far more notes than anyone else. The most difficult piano pieces are almost incomprehensible in the sheer speed and skill required just to play all the notes, and yet the pianists you hear on CDs still can play these pieces basically perfectly. Pianists are also expected (as a matter of tradition) to memorize everything they play solo, despite having so many notes.
Most other instruments, in contrast, have challenges that center more around tuning, breathing, having good tone production and embrochure, and hitting high notes.
And singers are a totally different ball game. Singers have to be really finely in tune with their health, and the state of their instrument can vary a lot throughout the day and depend on factors like sleep and diet.
I have read your posting and your blog. I think you are not very knowledgeable about operating systems and how they work.
Thanks for the feedback. I know a lot more than you think, but you and others made me realize that I didn't make my point very well. I'm writing a follow-up to present my ideas in hopefully a clearer way.
Now, if you do all these things well, the user may have to wait a moment now or then, for the sake of the aboive requirements.
Filling a buffer does not take a user-perceptible amount of time. User-perceptible pauses come when UIs block on I/O or CPU-intensive calculations like garbage-collection (ugh).
As more systems become SMP, the excuses for interrupting UIs become even less; one modern CPU is more than enough to do the plumbing work of real-time needs (eg. yes, it may take a lot of CPU time to do DSP on a real-time stream of sound data, but it doesn't take that much to move data around as need be).
Microkernel architecture, which brings tons of benefits (principally modularity and isolation). Yes, microkernels have a bad name, but I'm building on L4, a practical, Open Source microkernel that got it right
extensive support for low-latency and real-time applications (there is no reason that media players on today's hardware should ever glitch)
Like I said, it's totally vaporware at this point, but if this sounds interesting to you, check out my blog and my wiki to check out my ideas and my progress. My effort might totally flop (statistically speaking, this is likely to happen), but I have tons of ideas and an intense passion to see them realized.
Unfortunately, OpenID will utterly fail in it's task: it will never be a trustworthy source of identification.
You seem to be confused about the scope of OpenID. OpenID is not a system for tying user accounts to personal identities. It simply provides secure, distributed user accounts. It's not failing at it's task, it's failing at a task that you seem to want, but OpenID was never designed to solve.
I don't know about anyone elses, but IMHO GPL3 is as invasive a liscense agreement as the one in Windows Vista. How dare anyone tell me what I can and cannot do with my own hardware.
Huh? How does GPLv3 tell you what you can and cannot do with your own hardware?
Or is your real beef that you cannot tell your customers what they can and cannot do with their own hardware after they buy it?
Have you actually looked at a PDF file in a text editor? It's a meaningless pile of spaghetti.
What you mean is that it's not human-readable. And it's not designed to be -- what's the point of that? It's not going to be human-writable or human-editable.
And it's plain, readable XML instead of a 25-year-old printer description language.
XML is a subset of a 40-year-old markup language. XML has become the ultimate cancer on computing -- it's this seductive hammer that makes everything look like a nail, and when the first round of XML doesn't quite solve the problem, the solution is to throw on a little *more* XML.
XML is wastefully large, so all XML formats have to be compressed to be at all competetive in terms of file size.
XML is totally un-indexable, so you can't let any single XML document grow too big (because you always have to parse from the start to get the data you really want). So XML formats often have to break up their data into multiple XML files, and then make the "file format" a zip archive of various XML documents sprinkled around.
Your applicaiton can build files using any XML parsing engine, instead of having to license a PDF library.
Do you have any idea how miniscule a part of PDF *or* XPS functionality consists of parsing? One chapter (~130 pages) of the PDF spec covers syntax. The remaining 7 chapters (~650 pages) deal with how to interpret and render what you've parsed.
That XML library you use to read/write XPS files is going to be pretty useless on its own, unless you're also using a library that specifically knows the XPS format.
Putting the lock deep in silicon, where no software can touch it (or only specifically authenticated/authorized software), does not count as "giving them the key." This is the direction DRM is moving.
Oh my God, you're right - someone might try to attack the system! They probably never thought of that!
Re:Genuine question about perl vs ruby
on
Lisp and Ruby
·
· Score: 3, Interesting
Actually there is a good reason to look at Perl given Ruby. Regular Expressions. Ruby has a object and method for doing regular expressions but compared to Perl it's very combersome and is even lacking some of the properties that Perl's regex has.
Cumbersome? Which is this, Perl or Ruby?
"Hello, World!" =~/Hello, (\w+)!/; print $1;
Trick question -- it's both. What exactly about Ruby's way is cumbersome?
I agree with you to an extent, but I think that there are some cases where the effect is the opposite. Would IBM pour as many engineering resources into the Linux kernel if it was not GPL? Or do they want the assurance that their work benefits only the commons, and cannot be used against them by proprietary competitors?
The first time I tried Aperture on my 15" MacBook pro, I understood why there is no longer a 12" in the "Pro" line. The whole UI is designed around having a wide rectangular display. It would be almost unusable on a 12" PowerBook-sized screen. I haven't used all the other "Pro" apps, but I would bet that they are following suit.
Sure, not everyone who uses a MacBook Pro will use Aperture or other "Pro" apps, but that's who Apple is marketing the "Pro" to.
The only correct solution of this problem is proper quoting/escaping.
In the case of SQL, a much better solution is using bind variables. In addition to being totally invulnerable to injection attacks, they improve the efficiency of your queries (since the database engine can recognize when queries differ only in data, and cache its plan).
Re:About 5 years ago I was robbed
on
Free Geek Robbed
·
· Score: 1
You agreed to meet a burglar in a dark alley? That sounds insane.
I certainly like Google but that's bullshit. Eric is tactful with his words; surely all of this data portability stuff has an additional purpose, like, say, helping bringing valuable data in to Google's services?
Umm, obviously? But that doesn't make it bullshit unless Google fails to live up to this themselves in markets where they already have strong dominance (eg. Gmail).
The license of what font, obtained from where, and what exactly does the license say? Are you talking about your "custom fonts" or fonts that come with the program itself? You are making vague and unverifiable claims.
Most of these score programs use custom fonts. Custom fonts are copyright. You cannot distribute anything that is rendered in a custom font without permission from the creator of that font.
What you say is true of all fonts. Your term "custom fonts" doesn't mean anything. All fonts are Copyright (C) their creator, whether they come with the program, or you get them off the internet, or you buy them in a box. However, except in exceptional circumstances, I feel confident in saying that no one would buy a font that made you pay royalties to distribute your own music. I would virtually guarantee that the fonts that ship with mainstream music programs (Finale, Sibelius, etc) do not require this.
While your skepticism is taken, I have been interested in this issue for many years, and while I do not have specific case law, I make the observations:
several public domain music sites share this interpretation, presumably after doing their legal homework. See the Mutopia Project's page about legal issues, and a similar page at CPDL. Since it is in these sites' interest to distribute, the fact that they share this interpretation does not bode well for a more liberal reading.
As a musician, every modern score I have come across (including modern scores of early music, of which I perform a lot) will have a Copyright (C) the year it was published. So the publishers are at least attempting to assert this right. Some editions (like the New Novello Choral Edition of the Messiah) also include notes specifically forbidding even public performance of the music from the edition without payment. I always find this extremely offensive.
There are some unarguably creative things that go into editing music -- for example, deciding what the real note is when the original manuscripts only have a smudge, reconciling differences between different manuscripts, etc -- and there will often be significant scholarship that goes into resolving these issues. Almost every edition I have encountered (even of music as recent as the 20th century) includes scholarly work like that, which would probably make a judge sympathetic to the idea that the printing is copyrightable.
As much as I dislike it, GP's claims are fairly well-accepted among things I have read on this issue.
Slashdot Mirror
Amen, brother.
For people not familiar with MySQL's history, I would suggest a little reading from previous versions of MySQL's manual:
How to cope without COMMIT/ROLLBACK: For the moment, we are much more for implementing the SQL server language (something like stored procedures). With this you would very seldom really need COMMIT-ROLLBACK. This would also give much better performance.
Reasons not to use foreign keys. There are so many problems with FOREIGN KEYs that we don't know where to start.
I decided long ago that the MySQL guys are clowns. MySQL's lack of features was never as big a problem as the fact that I just couldn't take these guys seriously (and the above is only a small subset of the reasons for that).
Checking the referer header is ultimately going to fail because it would mean trusting the client to not lie about the referer.
In this case the client is the victim. Why would a client spoof Referer in order to attack itself?
It's not perfect, but Referer checking should cover nearly all attacks of this sort.
I notice that the course homepage talks about designing for an "idealised parallel computer" -- did it take into account the huge speed hit that comes from false sharing on real processors? That should be a major consideration if you are designing shared-memory parallel algorithms, since they can degrade performance by 1700% on modern processors. If you're not careful, your parallel algorithms could end up being much slower than single-threaded ones simply because they force so many cache bounces.
Not a flame, but did your prof say that good string (or other instrument performers) musicians are not a dime a dozen? Are any instruments considered to be more difficult than others?
Here are a couple thoughts on that question (which I think is an interesting one).
One is that different instruments attract different kinds of people. Extremely driven people tend to be attracted to Violin and Piano, so the fact that there are many fine violinists and pianists doesn't at all imply that they are easier. Trombonists and Violists tend to be a lot more laid back and quirky. There are lots of instrumentalist jokes that play on these stereotypes.
Another thing to mention: the best pianists at my college practically never left the music building. They practiced all the time. To contrast, the best clarinet player at my school practiced very little.
I think piano is challenging in a different way than most instruments. Pianists play far more notes than anyone else. The most difficult piano pieces are almost incomprehensible in the sheer speed and skill required just to play all the notes, and yet the pianists you hear on CDs still can play these pieces basically perfectly. Pianists are also expected (as a matter of tradition) to memorize everything they play solo, despite having so many notes.
Most other instruments, in contrast, have challenges that center more around tuning, breathing, having good tone production and embrochure, and hitting high notes.
And singers are a totally different ball game. Singers have to be really finely in tune with their health, and the state of their instrument can vary a lot throughout the day and depend on factors like sleep and diet.
I have read your posting and your blog. I think you are not very knowledgeable about operating systems and how they work.
Thanks for the feedback. I know a lot more than you think, but you and others made me realize that I didn't make my point very well. I'm writing a follow-up to present my ideas in hopefully a clearer way.
Now, if you do all these things well, the user may have to wait a moment now or then, for the sake of the aboive requirements.
Filling a buffer does not take a user-perceptible amount of time. User-perceptible pauses come when UIs block on I/O or CPU-intensive calculations like garbage-collection (ugh).
As more systems become SMP, the excuses for interrupting UIs become even less; one modern CPU is more than enough to do the plumbing work of real-time needs (eg. yes, it may take a lot of CPU time to do DSP on a real-time stream of sound data, but it doesn't take that much to move data around as need be).
- capability-based security, from the ground up
- Microkernel architecture, which brings tons of benefits (principally modularity and isolation). Yes, microkernels have a bad name, but I'm building on L4, a practical, Open Source microkernel that got it right
- extensive support for low-latency and real-time applications (there is no reason that media players on today's hardware should ever glitch)
Like I said, it's totally vaporware at this point, but if this sounds interesting to you, check out my blog and my wiki to check out my ideas and my progress. My effort might totally flop (statistically speaking, this is likely to happen), but I have tons of ideas and an intense passion to see them realized.Unfortunately, OpenID will utterly fail in it's task: it will never be a trustworthy source of identification.
You seem to be confused about the scope of OpenID. OpenID is not a system for tying user accounts to personal identities. It simply provides secure, distributed user accounts. It's not failing at it's task, it's failing at a task that you seem to want, but OpenID was never designed to solve.
I don't know about anyone elses, but IMHO GPL3 is as invasive a liscense agreement as the one in Windows Vista. How dare anyone tell me what I can and cannot do with my own hardware.
Huh? How does GPLv3 tell you what you can and cannot do with your own hardware?
Or is your real beef that you cannot tell your customers what they can and cannot do with their own hardware after they buy it?
Have you actually looked at a PDF file in a text editor? It's a meaningless pile of spaghetti.
What you mean is that it's not human-readable. And it's not designed to be -- what's the point of that? It's not going to be human-writable or human-editable.
And it's plain, readable XML instead of a 25-year-old printer description language.
XML is a subset of a 40-year-old markup language. XML has become the ultimate cancer on computing -- it's this seductive hammer that makes everything look like a nail, and when the first round of XML doesn't quite solve the problem, the solution is to throw on a little *more* XML.
XML is wastefully large, so all XML formats have to be compressed to be at all competetive in terms of file size.
XML is totally un-indexable, so you can't let any single XML document grow too big (because you always have to parse from the start to get the data you really want). So XML formats often have to break up their data into multiple XML files, and then make the "file format" a zip archive of various XML documents sprinkled around.
Your applicaiton can build files using any XML parsing engine, instead of having to license a PDF library.
Do you have any idea how miniscule a part of PDF *or* XPS functionality consists of parsing? One chapter (~130 pages) of the PDF spec covers syntax. The remaining 7 chapters (~650 pages) deal with how to interpret and render what you've parsed.
That XML library you use to read/write XPS files is going to be pretty useless on its own, unless you're also using a library that specifically knows the XPS format.
Putting the lock deep in silicon, where no software can touch it (or only specifically authenticated/authorized software), does not count as "giving them the key." This is the direction DRM is moving.
What's truly frightening is that George Bush wanted to name this guy to the Supreme Court, where he could make these "creative" constitutional interpretations have the force of law !!
Oh my God, you're right - someone might try to attack the system! They probably never thought of that!
Cumbersome? Which is this, Perl or Ruby? Trick question -- it's both. What exactly about Ruby's way is cumbersome?
I agree with you to an extent, but I think that there are some cases where the effect is the opposite. Would IBM pour as many engineering resources into the Linux kernel if it was not GPL? Or do they want the assurance that their work benefits only the commons, and cannot be used against them by proprietary competitors?
The first time I tried Aperture on my 15" MacBook pro, I understood why there is no longer a 12" in the "Pro" line. The whole UI is designed around having a wide rectangular display. It would be almost unusable on a 12" PowerBook-sized screen. I haven't used all the other "Pro" apps, but I would bet that they are following suit.
Sure, not everyone who uses a MacBook Pro will use Aperture or other "Pro" apps, but that's who Apple is marketing the "Pro" to.
Can it use the system address book on OS X yet? Please??
Honest question: why is this good, but traffic cams and telescreens bad?
Where is the line between "good for justice/democracy/etc" and "invasion of privacy?"
Ergo, if something is morally and ethically wrong, then it should be against the law.
Adultery? I think there are things that most people would consider morally and ethically wrong, but that aren't the state's (or the people's) concern.
The only correct solution of this problem is proper quoting/escaping.
In the case of SQL, a much better solution is using bind variables. In addition to being totally invulnerable to injection attacks, they improve the efficiency of your queries (since the database engine can recognize when queries differ only in data, and cache its plan).
You agreed to meet a burglar in a dark alley? That sounds insane.
I certainly like Google but that's bullshit. Eric is tactful with his words; surely all of this data portability stuff has an additional purpose, like, say, helping bringing valuable data in to Google's services?
Umm, obviously? But that doesn't make it bullshit unless Google fails to live up to this themselves in markets where they already have strong dominance (eg. Gmail).
Computing Scientists are not all Programmers.
OK, but the ones who aren't have two main choices for a career: academia and academia.
Not all Programmers are Computing Scientists.
OK, but the ones who have that background will run circles around the ones who don't.
The license of what font, obtained from where, and what exactly does the license say? Are you talking about your "custom fonts" or fonts that come with the program itself? You are making vague and unverifiable claims.
Most of these score programs use custom fonts. Custom fonts are copyright. You cannot distribute anything that is rendered in a custom font without permission from the creator of that font.
What you say is true of all fonts. Your term "custom fonts" doesn't mean anything. All fonts are Copyright (C) their creator, whether they come with the program, or you get them off the internet, or you buy them in a box. However, except in exceptional circumstances, I feel confident in saying that no one would buy a font that made you pay royalties to distribute your own music. I would virtually guarantee that the fonts that ship with mainstream music programs (Finale, Sibelius, etc) do not require this.
- several public domain music sites share this interpretation, presumably after doing their legal homework. See the Mutopia Project's page about legal issues, and a similar page at CPDL. Since it is in these sites' interest to distribute, the fact that they share this interpretation does not bode well for a more liberal reading.
- As a musician, every modern score I have come across (including modern scores of early music, of which I perform a lot) will have a Copyright (C) the year it was published. So the publishers are at least attempting to assert this right. Some editions (like the New Novello Choral Edition of the Messiah) also include notes specifically forbidding even public performance of the music from the edition without payment. I always find this extremely offensive.
- There are some unarguably creative things that go into editing music -- for example, deciding what the real note is when the original manuscripts only have a smudge, reconciling differences between different manuscripts, etc -- and there will often be significant scholarship that goes into resolving these issues. Almost every edition I have encountered (even of music as recent as the 20th century) includes scholarly work like that, which would probably make a judge sympathetic to the idea that the printing is copyrightable.
As much as I dislike it, GP's claims are fairly well-accepted among things I have read on this issue.