Re:My only suggestion for X
on
X Power Tools
·
· Score: 4, Insightful
Nope. This has already been addressed in the most recent X.org release. In fact the goal of this release is automatic hardware hotplugging support with no config files.
Actually it already works now. I'm running Ubuntu 7.10. Not too long ago I plugged in a beamer into my VGA port, and it... just worked! No configurations, no restart, it Just Worked(tm).
If you're going to whine, at least make an effort to stay up to date with the facts.
Re:So when do we get its successor?
on
X Power Tools
·
· Score: 1
"Look, I know this is the standard FOSS fanboy answer to any criticisms about anything and everything, but it's gotten tiresome - it doesn't actually address the criticism at all."
And you think complaining about it is somehow going to magically solve the problem? Problems are solved because *someone* creates a solution, not because people whine about it. If everybody complains and nobody actually does anything about it, then the problem will continue to exist forever.
"It's on the same level of relevance as if you'd responded "Oh, yeah? Well your momma's fat!"
No it isn't. Such a comparison is utterly ridiculous.
And I suppose your definition of "worthless" is "anything not supported by Microsoft/IBM/Sun/(insert big name company here)"?
I'd rather define "worthless" as "something nobody whatsoever can ever use for any reason whatsoever". But YAML is already used as the Ruby on Rails database configuration file. I use it myself for configuration files for my own apps. It works, it does its job. So by definition, YAML cannot be worthless.
Saying YAML is worthless is like saying.ini files are worthless.
Are you too young to remember the late 90s? Back then, before IE was bundled with Windows, ISPs would *give you a CD/floppy* with Netscape on it. There, problem solved. There are plenty of ways to provide a browser without the end user having to worry about it.
IE6 is a huge pile of ******. These days, whenever I write a website, the procedure is always like this: 1. Test website in Firefox initially. 2. Verify that it works in Opera. 3. Verify that it works in Konqueror. 4. Verify that it works in Safari. 5. See it totally break down in IE6.
IE6 has too many rendering bugs. It's the sole cause of hours and hours of lost productivity. It's about time that it dies. IE7, although not as standards compliant as... uhm... pretty much every other browser on earth, is orders of magnitude better than IE6. People should be forced to use IE7 (or Firefox, or Opera, or whatever; just not IE6).
I've benchmarked both, as well as searched Google, and I couldn't find any evidence that Mongrel is faster than Lighttpd+FastCGI. Could you point me to some sources which show that Mongrel is faster?
Thanks for the info. But do you know why Mongrel became the most popular Rails container, instead of lighttpd+FastCGI, or even Apache+FastCGI? I mailed the mailing list in the past but I never got a decent answer - people just say that they like Mongrel but nobody seems to be able to explain why it's better than the alternatives. I've heard of lighttpd+FastCGI crashing often, but I've been running a Rails app op lighttpd+FastCGI for more than a year now and it's very stable.
I agree. I've had correspondence with Zed in the past: I was asking him some questions about Rails's support for process forking (I was working on improving Ruby/Rails copy-on-write support), because as the Mongrel author he probably knows some gotchas. What I got in return was a series of very offensive emails. I did my best to stay polite, but every single email I got back seemed to be full of hate and rantings about Rails and Ruby.
No doubt that the guy's brilliant, but I wouldn't want someone like him as my colleague/employee/business partner/etc.
So instead of asking the user to tell the developer how to reproduce the bug, one has to ask the user to send the log files? Riiiight. That doesn't make the situation any better.
Besides, any reasonably complex application will do way too many things to be able to be properly logged. There's no way that one can extract all necessary information from the logs.
"When users complain about bugs, they are met with hostile demands to explain exactly, how to reproduce the bug"
Tell me, how do you expect a developer to fix a problem if the developer doesn't even know how to reproduce the bug? How do you expect a car mechanic to fix your car if you don't tell him what is wrong, and just "it's broken, fix it"?
The reason is that PHP is a "Hypertext Preprocessor". It even says that for its name! PHP is perfect for simple websites in which all pages have a shared header and footer. Rubyonrails.org doesn't even access the database. As soon as your web app has more than 500 lines of code and accesses the database, Rails will become very attractive.
It all boils down to using the right tool for the right job. Do you use a hammer to repair your TV? "OMG they don't use Rails for their own static content website that doesn't even access the database, therefore Rails must suck!" is just an excuse that people use to mod down Rails. It has got nothing to do with its merits.
I'm guessing that it's because: 1. IE sucks and Maxthon is better (tabbed browsing and popup blocking and all). Since Maxthon is based on the IE engine, people can still view all their websites (with Flash, ActiveX, etc). 2. Maxthon (previously known as MyIE2) has existed longer than Firefox. So when Firefox became popular, Chinese people are already used to Maxthon and don't want to switch. 3. Maxthon has supported Chinese localization for a long time, possibly longer than Firefox.
"Since they are functionally equivalent, any reasonable modern database system will perform them the same under the hood."
Will it? The subqueries that I worked with are more complex than that, and PostgreSQL didn't seem to be able to transform it into something faster, even though some students were able to do it by hand. What is according to you "any reasonable modern database system"? Are they always able to find an optimal alternative within reasonable time?
I don't have the assignment anymore so unfortunately I can't show you the execution plan.
What do views, HAVING and stored procedures have to do with this? To create a view I have to come up with a query in the first place. HAVING makes it possible to add conditions inside a group - but still, how exactly does this solve the problem without using a subquery?
The query would be derived as follows, by using mathematical set notation:
{ r:document_revisions | "r is the latest revision of the associated document" } <=> { r:document_revisions | FOR ALL(r2:document_revisions | (r2.document_id = r.document_id) => (r2.created_on <= r.created_on)) } <=> { r:document_revisions | FOR ALL(r2:document_revisions | NOT (r2.document_id = r.document_id) OR (r2.created_on <= r.created_on)) } <=> { r:document_revisions | FOR ALL(r2:document_revisions | r2.document_id != r.document_id OR (r2.created_on <= r.created_on)) } <=> { r:document_revisions | NOT EXISTS(r2:document_revisions | NOT(r2.document_id != r.document_id OR (r2.created_on <= r.created_on))) } <=> { r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND NOT (r2.created_on <= r.created_on)) } <=> { r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on) } => SELECT * FROM document_revisions r WHERE NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on) => SELECT * FROM document_revisions r WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on) => SELECT * FROM document_revisions r LEFT JOIN documents d ON r.document_id = d.id WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on)
And there you have it - a subquery that is dependent on the parent query. Expensive, forces the database to walk through the entire document_revisions able. How would you change this into something that doesn't need a subquery? Compare this query to the one in which I introduced an is_newest_revision column. I spent 10-15 minutes on this one, the other one I could write with almost no effort and should be a lot faster to run too.
"Subqueries are no more expensive than joins, and many query planners/optimizers will end up doing the exact same internal approach to both."
During the "database systems" lab sessions we had to write large queries with lots of subqueries, and some took a minute to run even though the data set is small (less than 200 rows in total). If you have subselect that depends on the parent:
SELECT * FROM users u WHERE (SELECT * foo WHERE foo.bar = u.username); then doesn't that force the database to walk through the entire users table?
"And thats fine until the second application starts modifying data in that DB."
The system has been in development for 2 months now. It's responsible for modifying all data in the DB and somehow it works just fine. Where did you get the idea that the app is not allowed or should not modify the DB directly?
"Then what if that developer didnt know about that rule? Since the db wasnt configured to guarantee data integrity the other developer has to somehow know that thats something the application must enforce to ensure integrity."
What if a developer doesn't know the programming language that the app is written in? What if the developer doesn't know how to breathe? Simple: make sure that the developer does. Make sure that he does know the rule. That is what documentation and training is for, isn't it? The report and the UML class diagram specifically mentions this constraint.
Actually, the model class automatically enforces this rule. Upon saving the model class, it will automatically set the is_newest_revision of older revision objects to false. That is what abstraction and object oriented programming is for. It has only been around for, oh you know, 20-30 years?
Reading all this makes me think that people use stored procedures as a replacement for database model classes because their developers are too incompetent to write good SQL.
Furthermore, unlike Perl, Ruby will warn you about ambiguous parenthesis. If you write:
foo bar "hello", "world" then you could mean foo(bar("hello", "world")) or foo(bar("hello"), "world"). Ruby will print a warning and tell you to use parenthesis.
"As the developer, you just need to worry about passing the monster name and the database spits out everything you want."
So you want the developer to treat the database as a black box? Is that a good thing? It sounds like you're working with incompetent developers.
"If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too."
In this specific case, the game server is written in C++. There are no additional tools that access the database. So what's the point in using this stored procedure? Even if there are additional tools (should they be written in C++ as well), what's the advantage of this stored procedure over sharing the database model class?
"Once you bury the database logic in the application code, you have to rewrite it for every application."
Oh my, and all this time I thought object oriented programming and dynamic libraries solved this 20-30 years ago.
Rubyonrails.org is written in PHP. If anything, this "proves" that PHP doesn't scale.
One might now be tempted to attack Rails for using PHP. Keep in mind that rubyonrails.org is a simple and "dumb" website with only some static content (except the blog). For that kind of small stuff, PHP is best.
Slashdot Mirror
Nope. This has already been addressed in the most recent X.org release. In fact the goal of this release is automatic hardware hotplugging support with no config files.
Actually it already works now. I'm running Ubuntu 7.10. Not too long ago I plugged in a beamer into my VGA port, and it... just worked! No configurations, no restart, it Just Worked(tm).
If you're going to whine, at least make an effort to stay up to date with the facts.
"Look, I know this is the standard FOSS fanboy answer to any criticisms about anything and everything, but it's gotten tiresome - it doesn't actually address the criticism at all."
And you think complaining about it is somehow going to magically solve the problem? Problems are solved because *someone* creates a solution, not because people whine about it. If everybody complains and nobody actually does anything about it, then the problem will continue to exist forever.
"It's on the same level of relevance as if you'd responded "Oh, yeah? Well your momma's fat!"
No it isn't. Such a comparison is utterly ridiculous.
And I suppose your definition of "worthless" is "anything not supported by Microsoft/IBM/Sun/(insert big name company here)"?
.ini files are worthless.
I'd rather define "worthless" as "something nobody whatsoever can ever use for any reason whatsoever". But YAML is already used as the Ruby on Rails database configuration file. I use it myself for configuration files for my own apps. It works, it does its job. So by definition, YAML cannot be worthless.
Saying YAML is worthless is like saying
Are you too young to remember the late 90s? Back then, before IE was bundled with Windows, ISPs would *give you a CD/floppy* with Netscape on it. There, problem solved. There are plenty of ways to provide a browser without the end user having to worry about it.
I know that, and I already do that. But that's not my point.
Yeah but this time, the push comes from Microsoft. Those third party websites will *have* to fix them, or lose all their customers.
IE6 is a huge pile of ******. These days, whenever I write a website, the procedure is always like this:
1. Test website in Firefox initially.
2. Verify that it works in Opera.
3. Verify that it works in Konqueror.
4. Verify that it works in Safari.
5. See it totally break down in IE6.
IE6 has too many rendering bugs. It's the sole cause of hours and hours of lost productivity. It's about time that it dies. IE7, although not as standards compliant as... uhm... pretty much every other browser on earth, is orders of magnitude better than IE6. People should be forced to use IE7 (or Firefox, or Opera, or whatever; just not IE6).
StarCraft runs fine in Wine. In fact these days I play StarCraft on Linux only, except when I need to go on Battle.Net. :)
I've benchmarked both, as well as searched Google, and I couldn't find any evidence that Mongrel is faster than Lighttpd+FastCGI. Could you point me to some sources which show that Mongrel is faster?
Thanks for the info. But do you know why Mongrel became the most popular Rails container, instead of lighttpd+FastCGI, or even Apache+FastCGI? I mailed the mailing list in the past but I never got a decent answer - people just say that they like Mongrel but nobody seems to be able to explain why it's better than the alternatives. I've heard of lighttpd+FastCGI crashing often, but I've been running a Rails app op lighttpd+FastCGI for more than a year now and it's very stable.
I agree. I've had correspondence with Zed in the past: I was asking him some questions about Rails's support for process forking (I was working on improving Ruby/Rails copy-on-write support), because as the Mongrel author he probably knows some gotchas. What I got in return was a series of very offensive emails. I did my best to stay polite, but every single email I got back seemed to be full of hate and rantings about Rails and Ruby.
No doubt that the guy's brilliant, but I wouldn't want someone like him as my colleague/employee/business partner/etc.
So instead of asking the user to tell the developer how to reproduce the bug, one has to ask the user to send the log files? Riiiight. That doesn't make the situation any better.
Besides, any reasonably complex application will do way too many things to be able to be properly logged. There's no way that one can extract all necessary information from the logs.
"When users complain about bugs, they are met with hostile demands to explain exactly, how to reproduce the bug"
Tell me, how do you expect a developer to fix a problem if the developer doesn't even know how to reproduce the bug? How do you expect a car mechanic to fix your car if you don't tell him what is wrong, and just "it's broken, fix it"?
The reason is that PHP is a "Hypertext Preprocessor". It even says that for its name! PHP is perfect for simple websites in which all pages have a shared header and footer. Rubyonrails.org doesn't even access the database. As soon as your web app has more than 500 lines of code and accesses the database, Rails will become very attractive.
It all boils down to using the right tool for the right job. Do you use a hammer to repair your TV? "OMG they don't use Rails for their own static content website that doesn't even access the database, therefore Rails must suck!" is just an excuse that people use to mod down Rails. It has got nothing to do with its merits.
What does that have to do with rubyonrails.org being written in PHP?
In China it's a lot worse than in the US. When was the last time you saw a US website that requires ActiveX?
I'm guessing that it's because:
1. IE sucks and Maxthon is better (tabbed browsing and popup blocking and all). Since Maxthon is based on the IE engine, people can still view all their websites (with Flash, ActiveX, etc).
2. Maxthon (previously known as MyIE2) has existed longer than Firefox. So when Firefox became popular, Chinese people are already used to Maxthon and don't want to switch.
3. Maxthon has supported Chinese localization for a long time, possibly longer than Firefox.
"Since they are functionally equivalent, any reasonable modern database system will perform them the same under the hood."
Will it? The subqueries that I worked with are more complex than that, and PostgreSQL didn't seem to be able to transform it into something faster, even though some students were able to do it by hand. What is according to you "any reasonable modern database system"? Are they always able to find an optimal alternative within reasonable time?
I don't have the assignment anymore so unfortunately I can't show you the execution plan.
What do views, HAVING and stored procedures have to do with this? To create a view I have to come up with a query in the first place. HAVING makes it possible to add conditions inside a group - but still, how exactly does this solve the problem without using a subquery?
The query would be derived as follows, by using mathematical set notation:
{ r:document_revisions | "r is the latest revision of the associated document" }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | (r2.document_id = r.document_id) => (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | NOT (r2.document_id = r.document_id) OR (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | FOR ALL(r2:document_revisions | r2.document_id != r.document_id OR (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | NOT(r2.document_id != r.document_id OR (r2.created_on <= r.created_on))) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND NOT (r2.created_on <= r.created_on)) }
<=>
{ r:document_revisions | NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on) }
=>
SELECT * FROM document_revisions r
WHERE NOT EXISTS(r2:document_revisions | r2.document_id = r.document_id AND r2.created_on > r.created_on)
=>
SELECT * FROM document_revisions r
WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on)
=>
SELECT * FROM document_revisions r
LEFT JOIN documents d ON r.document_id = d.id
WHERE NOT EXISTS(SELECT * FROM document_revisions r2 WHERE r2.document_id = r.document_id AND r2.created_on > r.created_on)
And there you have it - a subquery that is dependent on the parent query. Expensive, forces the database to walk through the entire document_revisions able. How would you change this into something that doesn't need a subquery?
Compare this query to the one in which I introduced an is_newest_revision column. I spent 10-15 minutes on this one, the other one I could write with almost no effort and should be a lot faster to run too.
"Subqueries are no more expensive than joins, and many query planners/optimizers will end up doing the exact same internal approach to both."
During the "database systems" lab sessions we had to write large queries with lots of subqueries, and some took a minute to run even though the data set is small (less than 200 rows in total). If you have subselect that depends on the parent:
SELECT * FROM users u WHERE (SELECT * foo WHERE foo.bar = u.username);
then doesn't that force the database to walk through the entire users table?
"And thats fine until the second application starts modifying data in that DB."
The system has been in development for 2 months now. It's responsible for modifying all data in the DB and somehow it works just fine. Where did you get the idea that the app is not allowed or should not modify the DB directly?
"Then what if that developer didnt know about that rule? Since the db wasnt configured to guarantee data integrity the other developer has to somehow know that thats something the application must enforce to ensure integrity."
What if a developer doesn't know the programming language that the app is written in? What if the developer doesn't know how to breathe?
Simple: make sure that the developer does. Make sure that he does know the rule. That is what documentation and training is for, isn't it? The report and the UML class diagram specifically mentions this constraint.
Actually, the model class automatically enforces this rule. Upon saving the model class, it will automatically set the is_newest_revision of older revision objects to false. That is what abstraction and object oriented programming is for. It has only been around for, oh you know, 20-30 years?
Reading all this makes me think that people use stored procedures as a replacement for database model classes because their developers are too incompetent to write good SQL.
Not. The. Point.
Okay, I'll replace "$FAVORITE_FRAMEWORK" with "$WHATEVER_YOU_HAPPEN_TO_USE". Better now?
My point still stands: that RoR is limited, and that being limited is exactly what boosts productivity and what makes it good.
Read what 'crayz' just replied to you.
Furthermore, unlike Perl, Ruby will warn you about ambiguous parenthesis. If you write:
foo bar "hello", "world"
then you could mean foo(bar("hello", "world")) or foo(bar("hello"), "world"). Ruby will print a warning and tell you to use parenthesis.
"As the developer, you just need to worry about passing the monster name and the database spits out everything you want."
So you want the developer to treat the database as a black box? Is that a good thing? It sounds like you're working with incompetent developers.
"If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too."
In this specific case, the game server is written in C++. There are no additional tools that access the database. So what's the point in using this stored procedure? Even if there are additional tools (should they be written in C++ as well), what's the advantage of this stored procedure over sharing the database model class?
"Once you bury the database logic in the application code, you have to rewrite it for every application."
Oh my, and all this time I thought object oriented programming and dynamic libraries solved this 20-30 years ago.
Rubyonrails.org is written in PHP. If anything, this "proves" that PHP doesn't scale.
One might now be tempted to attack Rails for using PHP. Keep in mind that rubyonrails.org is a simple and "dumb" website with only some static content (except the blog). For that kind of small stuff, PHP is best.
It proves that the people who complain that Rails can't scale are just that - complainers.