Brasero is my weapon of choice. Now that I've helped you, why don't you find me the native KDE equivalents of Evolution (PLEASE don't say krashy KMail) Someone seems to have fixed most of the KMail crashes recently. You might want to try a recent version.
(Provided you liked KMail/sans/ crashes)
There is also mailody... not sure how it is.
Yeah, so, they steal the web app credentials. That gives them precisely nothinng. Rember, the web app does not store DB authentication info. I agree that those would be worthless, but I can't see where I mentioned getting those would be a concern. Cracking the web app would, however be a major concern, as that might leave the door open to subsume the webapp (to log the db credentials or to log the dataflow)
Further, communication over the internet, between the server requesting the data and the server running the web app would be encrypted via SSL. Communication over the LAN, between the server running the web app and the DB server could, optionally, be encrypted as well; they could also be the same server -- just firewall off everything but the HTTPS port. At no point does the data have to travel unencrypted. However, if you're truly that worried about internal data theft, you have bigger fish to fry than an internet-facing DB server.
However, the data would still be in clear text at the webapp, so if the webapp is cracked, then any and all data read through
the webapp woudl be available to the cracker.
The security gained from not leaving your DB directly accessible over the internet and preventing listing of available DBs and tables would be well worth the development and debugging time.
I do not know of any databases that offers that information without prior authentication. As that authentication requires db credentials, the webapp offers no additional protection.
Further, if someone did compromise the web app and obtain DB credentials somehow, they would still have to obtain table names in order to access any data. I suppose that could, potentially, be quite simple to pull off internally, with or without the web app acting as proxy. To clarify an earlier comment I made in this post, if you're that concerned about internal data theft, you should reevaluate your hiring and security clearance procedures.
I'm not that concerned... I merely maintain that the simple solution (e.g. postgres on the internet) is about as safe (or unsafe, if you prefer) as the complicated solution (webapp mediator). You gain a little by having an unusual setup, but loose some by making another attack vector available to the cracker.
Nice strawman, though. I had to read it a few times to find the flaws in your rebuttal. If it was a strawman, it was unintentional. I can't see what I've missed.
Further, why are flaws found on some web apps which store passwords or credit card information relevant to this web app, which stores neither? It was a tangent. I find that the only real protection against data theft apart from the usual encryption+authenticatino stuff is not having the data available in the first place.
Thank you for providing such useful comments. Likewise:)
You are arguing that adding an abstraction to the actual db helps keeping maintenance costs down. True, but not really a security concern. It is also something which is rather easily done with e.g. views, so the entire webapp can be saved, to the tune of millions of euros.
I should patent this, but I'll put it out in the open, instead, as I'll likely never impliment it myself. Perhaps a substantial number of admins will see this and actually use it; maybe our personal and financial data will end up more secure. Yeah. Right. Don't worry, software isn't patentable here, yet:)
Why not have a web app which simply acts as a proxy for the DB? Keep the DB login credentials out of the web app, entirely. Log into the web app over SSL and tunnel your DB queries through the web app. Seems simple enough to me; after logging in to the web app, you would still have to log into the DB, so compromising one doesn't automatically mean the other has been compromised as well.
So you are adding a mediator. That means additional points of failure, another program that can be compromised (perhaps leading to a man-in-the-middle attack, steal the db credentials together with the webapp ones and use that?). I hope the extra step is worth it. Of course, there are the costs too: All those debugging hours to rule out (or in!) that it isn't the webapp that causes trouble. Then there is the state concern... webapps work on stateless transactions (in a sense) while db servers typically do not. So you have to bridge that gap, which isn't easy todo without adding information about the db in the webapp. Which again leads to more complexity in the webapp, which opens the way for more bugs. Remember, if you are going to add a mediator, make it *dead* simple.
If the web app doesn't default to a valid DB, but, instead, simply forwards queries to and from the DB server, it would require an attacker to know the login credentials for the web app and the login credentials of the DB. If the web app prevented listing available DBs, the attacker would have to know that ahead of time or be a good guesser. Likewise if the web app prevented listing of table and field names and types. Sounds like you are unencrypting the transactions rather than wrapping them in the webapp --- how else would you know the forbidden requests?. Which means the queries are in plain text, leaving that webapp vulnerable for a fullblown crack.
Once the database and the applcations meant to access it are created, working and deployed, there's no reason to allow such listings, anyway. If such listings are, for some reason, needed, they can be gotten by direct DB access on the internal network; there's no reason they should HAVE to use the web app internally, it would only have to be used by applications accessing the DB from a remote location. That is security by obscurity. The article is probably better than I when it comes to explaining the cons and pros of that.
Please, submit counterpoints; make corrections and additions. Let's give these admins something they can use to actually make their (and our) data safer.
Done. I am a great proponent of KISS... keep it super simple;) Keep the public and/or exposed interfaces small and simple, don't trust data from clients more than strictly necessary, and never store information you don't need. Passwords are a classic here: too many webapps still store the actual passwords. Use hashes. The same goes for creditcard information. You don't need to know the actual number, do you? You just want to know if it has been used before. So hash it. You only need the data in case the police comes by or something? Encrypt it using a public key, keep the private key somewhere else (a piece of paper in a bank box, e.g.), and make it really long. The police probably won't come a-knocking, so it's a good tradeoff. Plus, you can probably send the bill+a bit extra to them, so you're home free.
Why not do a VPN? A VPN concentrator can be had for under $300 and remote sites can be connected with VPN gateways for under $100. Surely it is worth the piece of mind to not have your and your customers data exposed? Because VPN have a lot of hidden costs, adds little or no security to the described setup and adds another point of cracking and failure? E.g., said contractor perhaps have a backdoor. He might not even know about it himself. Why add that 3rd party? Why have that extra costs, and extra fuss? Also, I have yet to see a totally transparent, never-fails, zero-setup VPN. Which means that the cost of the VPN is somewhat higher.
VPNs are good if you have an open internal, trusted network that you want selected machines on the internet to have access to, without having a clue to where those machines connect from. It's not a topology I'd recommend, but it's quite common. Of course, there might be more usecases.
Why doesn't DB - Webapp - {internet} work? Why can't you have a DB on your local subnet?
This is particularly relevant since you could just as easily roll a couple virtual machines on the same subnet and just castrate the DB for internet access.
It might work, that would depend on what application we are talking about. It isn't really any more secure, though. It just means that instead of crackers having to crack the secure, well-tested db authentication (propably some assymmetric encryption based on a reputable library) they have to crack the webapp (or less likely, the web server). Webapps are not trivially secure.
So if I had, say, shops spread around with a central server keeping up a database for inventory and such, just exposing a reasonably hardened db to the net seems reasonable enough. That way, you could get cheap (dynamic ip) internet connections for each shop, and have an app connect directly from the shops to the db. It might be a better solution, it all depends.
Personally, I would rather have my webserver, which is designed to be publicly available, and quite easy to secure, available - vs. WormBait such as MSSQL. The fix in that case would be to switch MSSQL for a better database. postgress is free, and quite secure even on the internet.
Brilliant idea! Let's call one of them/dev/urandom and the other one/dev/random.
/dev/urandom is the PRNG while/dev/random is the true RNG. In other worse, exactly the same as on Windows, save for device names.
http://en.wikipedia.org/wiki/Urandom Well, I knew that, and most linux folks do, but thank you for telling anyway. However, if the guy I replied to is correct, the windows/dev/random does not block if insufficient entropy is available. The only windows I use are the ones used to keep the heat in, though, so I wouldn't know personally.
Interestingly, the much-reviewed TrueCrypt engine seems to slow to a crawl if you create a bunch of files (and therefore keys) in a hurry - presumably it has an RNG that actually blocks waiting until it has enough new "really random" bits for each new key. This is a cool idea for a crypto library, but not usable for a general-purpose RNG, which suggests that the system libraries should probably provide *two* RNGs. Brilliant idea! Let's call one of them/dev/urandom and the other one/dev/random.;)
OK, so you can't bind lock screen to [WIN]-L, it shows but doesn't work. To be fair (or unfair) that's been like that for the last _2_versions_. Hmm.. that is the binding I use (each day). Though on Kubuntu, so it might be a Gnome thing.
* Application bundles - drag and drop install, removal. Ability to drag an.app to anywhere in the file system at any time. App resources all contained in the.app directory structure instead of scattered all over the file system We have this. It's called "deb packages". Works like a charm.
*/Application directory - default place for App bundles to be copied to You mean/application... no need to use capitals. Anyway, I don't see the advantage over the current system. I don't really care where packages are stored, that is my package manager's job. Oh
*/Preferences - standard place for apps to store their user specific settings instead of hidden . files in the main user home directory You mean/preferences:p Anyway, that sounds like a horrible idea. Cleanup after users would get more messy and quotas too. But putting them under ~/.prefs/... might not be a bad idea. There is some merit there, but not an easy thing to change!
* An app interface building tool that has OS X level UI element default spacing when laying out an interface to help with the jarringly hideous problems virtually every Linux app has with visual layo Hmm..I think OSX apps looks terrible, while KDE apps are the cleanest. But all three are quite usable, so I don't see this as a priority. And technically, it isn't the interface building tool's job to layout widgets, that would be horrible! Just imagine what happens when the font changes, or the resolution.
I think the issue at hand, is that the people who actively contribute, are running out of things to write about. There is a TON more that can go into wiki, but the "experts" or... people who even CARE about those subjects, are not the type who care about writing up articles about it.
Or they've been run off of Wikipedia altogether. Wikipedia rewards playing the political game and the ability to be there day in and day out far, far more than it does expertise.
You must be editing very different articles than I:) The most political article I have edited was the C++ one, and even there, by using a bit of thought and the talk page, the changes I've made went through smoothly. And I am a very casual editor, I have made maybe a few handfuls of contributions:)
For the truly bored, wikipedia sports a list of countries that use the billion=10^12 and billion=10^9, among other variants. And indeed, billion seems to mostly mean 10^9 among the English speaking.
Copyright infringement is theft.
The problem with RIAA is that they try to sue people who didn't infringe their copyright.
At least, this usage of the world "steal" is pretty old. Tom Lehrer (if you know who that is) said in the 60s "I thought I'd steal.. I mean adapt... this idea" or something close. It is just a word that has gotten additional meanings. If I "steal your heart" I hardly deny the usage of your heart, either:)
Personally, I don't mind copyright, but the length is suboptimal. (15, 20 years from publishing would be enough, I think). Also, copyright should not be used to force people to watch certain stuff, such as copyright notices or other things.
As long as reasonable care is taken to make sure you got the right person, and as long as the punishment fits the crime, I have no problem going after the file sharers. On the other hand, DRM is one of those things I would forbid. It's counterproductive for innovation in the surrounding fields.
We seem to be going in circles. I know this solution, is previously pointed out, but that solution is not database agnostic. So in these cases, you have the choice between database agnosticism and efficiency. And during these choices, programmers will make mistakes. I rather suspect that much of the rails's reputation of sluggishness is due to stuff like that.
Of course, without the profiling data, we will never know.
For simple selects, rails provide the find class function, which is nice, but even relatively simple stuff like selecting on a date, asking for a specific month is not possible without sql fragments.
What's wrong with entries.find(:all,:conditions => [:month => 6])?
According to the documentation, this would not work. What I need is something like SELECT * FROM entries WHERE MONTH(date)=6. What the above would get me is SELECT * FROM entries WHERE month=6.
Or am I wrong? But even so, there must be limits to what find can do, and in those cases, a db agnostic way to access the databases would be very nice.
A few more resources?
Rails is dog slow.. I know of more than one company that has gone under because of the huge amount of server costs due to ruby and rails. A few saved themselves by rewriting in PHP and getting rid of almost all of their servers.
It would be interesting to see where those resources are spent. I wonder if anyone has done an analysis.
As an example, it is very easy to do a select by going through all the records in the db. And in rails, that way might look better... no sql fragments and so on.
This is just an issue of poor programming (or FUD). The idea that the Rails developers wouldn't provide the ability to select specific records out of a table is absurd, and any developer who selects the whole table and manually searches instead is incompetent.
I don't agree on this wholeheartedly. Yes, rails allows SQL fragments, so you can do stuff like that if you wish, and by carefully writing the sql, it will work on most databases. However, it will no longer be truly database agnostic, which lessens the appeal somewhat. For simple selects, rails provide the find class function, which is nice, but even relatively simple stuff like selecting on a date, asking for a specific month is not possible without sql fragments. So, it is certainly easier to write something like entries.find(:all).collect { |entry| entry.date.month == 6 } to get all the entries from a june date. Yes, it doesn't scale, but the programmer in question might have judged that it didn't need to (perhaps the list of entries is expected to be small). And so on, I think you get my drift.
As for ruby being slow, this is a much smaller deal than you'd expect. Most of these apps are database limited anyway - things like Rails caching will probably have a larger positive effect being able to execute less ruby instructions per microsecond.
Good point, but it depends. Lots of applications are CPU bound on filling in templates, especially when caching is used. Yes, for DB bound applications, rails will do just fine. In any case, I am completely certain that ruby will get to be as fast as python as to make no difference, in time.
You nailed it pretty well, but I thought an elaboration might need. So,
The real criticism of rails is this: It's slow. So if you are going to build something that has to serve lots'and'lots of pages, don't do it. From what I've read, the reason for this is a combination of slow ruby (which will be cured) and trading efficiency for elegance is so easy. As an example, it is very easy to do a select by going through all the records in the db. And in rails, that way might look better... no sql fragments and so on.
In my humble opinion, rails needs a way to write db-engine-agnostic efficient queries to be useful in the applications that needs to serve a lot. For the moment, I'd suggest at least care if you want to go this route.
The other criticism is that if you have a big, homegrown non-ruby-library, you won't be able to use that in rails. True, but obvious.
Does these criticism make rails useless today? Not at all. It's wonderful for making all those webapps that doesn't take a pounding. Many, many web applications serve less than a page per second, and for those, rails is just perfect. The smaller development cost will match up wonderfully with the lesser usage. And as it is small apps (I wrote one for managing the employees lunch-club), the chance that you really need any existing homegrown library is small, too.
let's just say the file selector in GNOME blows away any other file selector I've ever dealt with except the file selector in Mac OS X apps. I love the GNOME file selector in GNOME apps. It's so flexible and restrictive.
My bolding. Just reinforces my point. If you want power, configurability, several ways to do stuff, that sort of thing go for KDE. If you like minimalism, get-the-hell-out-of-my-way, do-your-job-and-nothing else sort thing, go for GNOME. I never understood the bad blood between KDE and GNOME. They both do what they do nicely, and noone forces you to use the other camps desktop. Yes, that means you probably have to load both kdelibs and gtk*, but hey, we are quickly moving to 4Gb RAM. Those libs are not *that* big.
So let's not fight. Instead, continue the great work done on integration. E.g, I hear that a way to get the proper file selector for either desktop will soon be available, which means that I get to skip that fileselector from GNOME. Which is, to my way of working, the second worst file selector I have seen, only topped by the MAC OS one:p
I never understood the point of these huge, monolithic libraries. They're a bitch to maintain & if you want to use an improved aspect in PART of the library (e.g. a better database interface), you often must upgrade ALL uses of the library that you might be happy with (e.g. the GUI). In Open Sources 2.0, Chris DiBona states "when developing, I like to use large libraries only when I either don't want to deal with a technology, or I don't fully understand it and don't feel qualified to implement it." It seems that many *nix hackers feel similarly about userland tools. So why is QT so popular? Well, first of QT is split into several sublibraries (as of 4.0), so it's not monolithic as such. As to why it is popular, try using it. It's popular because it is very well made. To the grandparent, QT takes longer to compile because it is C++, which is a language that is hard on the compiler. GTK, on the other hand, is written in C, which is very easy on the compiler. (Insert language flamewar here).
Read the fine print next time, clown. They are just playing by the rules. Why can't you ?
Actually, in the EU, they do not. Since it is within 6 months, they have to prove that it was not a fault in the product at the time of purchase. This consumer right cannot be limited or revoked in any way for a sale (to a person) within EU.
Slashdot Mirror
A reason to upgrade to Vista! ;)
However, the data would still be in clear text at the webapp, so if the webapp is cracked, then any and all data read through the webapp woudl be available to the cracker.
The security gained from not leaving your DB directly accessible over the internet and preventing listing of available DBs and tables would be well worth the development and debugging time.I do not know of any databases that offers that information without prior authentication. As that authentication requires db credentials, the webapp offers no additional protection.
Further, if someone did compromise the web app and obtain DB credentials somehow, they would still have to obtain table names in order to access any data. I suppose that could, potentially, be quite simple to pull off internally, with or without the web app acting as proxy. To clarify an earlier comment I made in this post, if you're that concerned about internal data theft, you should reevaluate your hiring and security clearance procedures.I'm not that concerned... I merely maintain that the simple solution (e.g. postgres on the internet) is about as safe (or unsafe, if you prefer) as the complicated solution (webapp mediator). You gain a little by having an unusual setup, but loose some by making another attack vector available to the cracker.
Nice strawman, though. I had to read it a few times to find the flaws in your rebuttal. If it was a strawman, it was unintentional. I can't see what I've missed. Further, why are flaws found on some web apps which store passwords or credit card information relevant to this web app, which stores neither? It was a tangent. I find that the only real protection against data theft apart from the usual encryption+authenticatino stuff is not having the data available in the first place. Thank you for providing such useful comments. LikewiseYou are arguing that adding an abstraction to the actual db helps keeping maintenance costs down. True, but not really a security concern. It is also something which is rather easily done with e.g. views, so the entire webapp can be saved, to the tune of millions of euros.
So you are adding a mediator. That means additional points of failure, another program that can be compromised (perhaps leading to a man-in-the-middle attack, steal the db credentials together with the webapp ones and use that?). I hope the extra step is worth it. Of course, there are the costs too: All those debugging hours to rule out (or in!) that it isn't the webapp that causes trouble. Then there is the state concern... webapps work on stateless transactions (in a sense) while db servers typically do not. So you have to bridge that gap, which isn't easy todo without adding information about the db in the webapp. Which again leads to more complexity in the webapp, which opens the way for more bugs. Remember, if you are going to add a mediator, make it *dead* simple.
If the web app doesn't default to a valid DB, but, instead, simply forwards queries to and from the DB server, it would require an attacker to know the login credentials for the web app and the login credentials of the DB. If the web app prevented listing available DBs, the attacker would have to know that ahead of time or be a good guesser. Likewise if the web app prevented listing of table and field names and types.Sounds like you are unencrypting the transactions rather than wrapping them in the webapp --- how else would you know the forbidden requests?. Which means the queries are in plain text, leaving that webapp vulnerable for a fullblown crack. Once the database and the applcations meant to access it are created, working and deployed, there's no reason to allow such listings, anyway. If such listings are, for some reason, needed, they can be gotten by direct DB access on the internal network; there's no reason they should HAVE to use the web app internally, it would only have to be used by applications accessing the DB from a remote location. That is security by obscurity. The article is probably better than I when it comes to explaining the cons and pros of that. Please, submit counterpoints; make corrections and additions. Let's give these admins something they can use to actually make their (and our) data safer.
Done. I am a great proponent of KISS... keep it super simple ;) Keep the public and/or exposed interfaces small and simple, don't trust data from clients more than strictly necessary, and never store information you don't need. Passwords are a classic here: too many webapps still store the actual passwords. Use hashes. The same goes for creditcard information. You don't need to know the actual number, do you? You just want to know if it has been used before. So hash it. You only need the data in case the police comes by or something? Encrypt it using a public key, keep the private key somewhere else (a piece of paper in a bank box, e.g.), and make it really long. The police probably won't come a-knocking, so it's a good tradeoff. Plus, you can probably send the bill+a bit extra to them, so you're home free.
VPNs are good if you have an open internal, trusted network that you want selected machines on the internet to have access to, without having a clue to where those machines connect from. It's not a topology I'd recommend, but it's quite common. Of course, there might be more usecases.
This is particularly relevant since you could just as easily roll a couple virtual machines on the same subnet and just castrate the DB for internet access.
It might work, that would depend on what application we are talking about. It isn't really any more secure, though. It just means that instead of crackers having to crack the secure, well-tested db authentication (propably some assymmetric encryption based on a reputable library) they have to crack the webapp (or less likely, the web server). Webapps are not trivially secure.
So if I had, say, shops spread around with a central server keeping up a database for inventory and such, just exposing a reasonably hardened db to the net seems reasonable enough. That way, you could get cheap (dynamic ip) internet connections for each shop, and have an app connect directly from the shops to the db. It might be a better solution, it all depends.
http://en.wikipedia.org/wiki/Urandom Well, I knew that, and most linux folks do, but thank you for telling anyway. However, if the guy I replied to is correct, the windows
[...] Buy a new car and light bulbs filled with mercury!"
To be fair, the saved electricity means less mercury emission from coal plants, so the mercury, at least, is of little concern.
Or, you could look into LED.
Well, that rules out Denmark, where it is mostly grey with rainclouds. Spain, maybe?
Or they've been run off of Wikipedia altogether. Wikipedia rewards playing the political game and the ability to be there day in and day out far, far more than it does expertise.
You must be editing very different articles than I
For the truly bored, wikipedia sports a list of countries that use the billion=10^12 and billion=10^9, among other variants. And indeed, billion seems to mostly mean 10^9 among the English speaking.
The problem with RIAA is that they try to sue people who didn't infringe their copyright.
At least, this usage of the world "steal" is pretty old. Tom Lehrer (if you know who that is) said in the 60s "I thought I'd steal.. I mean adapt... this idea" or something close. It is just a word that has gotten additional meanings. If I "steal your heart" I hardly deny the usage of your heart, either :)
Personally, I don't mind copyright, but the length is suboptimal. (15, 20 years from publishing would be enough, I think). Also, copyright should not be used to force people to watch certain stuff, such as copyright notices or other things.
As long as reasonable care is taken to make sure you got the right person, and as long as the punishment fits the crime, I have no problem going after the file sharers. On the other hand, DRM is one of those things I would forbid. It's counterproductive for innovation in the surrounding fields.
We seem to be going in circles. I know this solution, is previously pointed out, but that solution is not database agnostic. So in these cases, you have the choice between database agnosticism and efficiency. And during these choices, programmers will make mistakes. I rather suspect that much of the rails's reputation of sluggishness is due to stuff like that.
Of course, without the profiling data, we will never know.
What's wrong with entries.find(:all, :conditions => [:month => 6])?
According to the documentation, this would not work. What I need is something like SELECT * FROM entries WHERE MONTH(date)=6. What the above would get me is SELECT * FROM entries WHERE month=6.
Or am I wrong? But even so, there must be limits to what find can do, and in those cases, a db agnostic way to access the databases would be very nice.
Rails is dog slow.. I know of more than one company that has gone under because of the huge amount of server costs due to ruby and rails. A few saved themselves by rewriting in PHP and getting rid of almost all of their servers.
It would be interesting to see where those resources are spent. I wonder if anyone has done an analysis.
This is just an issue of poor programming (or FUD). The idea that the Rails developers wouldn't provide the ability to select specific records out of a table is absurd, and any developer who selects the whole table and manually searches instead is incompetent.
I don't agree on this wholeheartedly. Yes, rails allows SQL fragments, so you can do stuff like that if you wish, and by carefully writing the sql, it will work on most databases. However, it will no longer be truly database agnostic, which lessens the appeal somewhat. For simple selects, rails provide the find class function, which is nice, but even relatively simple stuff like selecting on a date, asking for a specific month is not possible without sql fragments. So, it is certainly easier to write something like entries.find(:all).collect { |entry| entry.date.month == 6 } to get all the entries from a june date. Yes, it doesn't scale, but the programmer in question might have judged that it didn't need to (perhaps the list of entries is expected to be small). And so on, I think you get my drift.
As for ruby being slow, this is a much smaller deal than you'd expect. Most of these apps are database limited anyway - things like Rails caching will probably have a larger positive effect being able to execute less ruby instructions per microsecond.
Good point, but it depends. Lots of applications are CPU bound on filling in templates, especially when caching is used. Yes, for DB bound applications, rails will do just fine. In any case, I am completely certain that ruby will get to be as fast as python as to make no difference, in time.
You nailed it pretty well, but I thought an elaboration might need. So,
The real criticism of rails is this: It's slow. So if you are going to build something that has to serve lots'and'lots of pages, don't do it. From what I've read, the reason for this is a combination of slow ruby (which will be cured) and trading efficiency for elegance is so easy. As an example, it is very easy to do a select by going through all the records in the db. And in rails, that way might look better... no sql fragments and so on.
In my humble opinion, rails needs a way to write db-engine-agnostic efficient queries to be useful in the applications that needs to serve a lot. For the moment, I'd suggest at least care if you want to go this route.
The other criticism is that if you have a big, homegrown non-ruby-library, you won't be able to use that in rails. True, but obvious.
Does these criticism make rails useless today? Not at all. It's wonderful for making all those webapps that doesn't take a pounding. Many, many web applications serve less than a page per second, and for those, rails is just perfect. The smaller development cost will match up wonderfully with the lesser usage. And as it is small apps (I wrote one for managing the employees lunch-club), the chance that you really need any existing homegrown library is small, too.
My bolding. Just reinforces my point. If you want power, configurability, several ways to do stuff, that sort of thing go for KDE. If you like minimalism, get-the-hell-out-of-my-way, do-your-job-and-nothing else sort thing, go for GNOME. I never understood the bad blood between KDE and GNOME. They both do what they do nicely, and noone forces you to use the other camps desktop. Yes, that means you probably have to load both kdelibs and gtk*, but hey, we are quickly moving to 4Gb RAM. Those libs are not *that* big.
So let's not fight. Instead, continue the great work done on integration. E.g, I hear that a way to get the proper file selector for either desktop will soon be available, which means that I get to skip that fileselector from GNOME. Which is, to my way of working, the second worst file selector I have seen, only topped by the MAC OS one :p
Actually, in the EU, they do not. Since it is within 6 months, they have to prove that it was not a fault in the product at the time of purchase. This consumer right cannot be limited or revoked in any way for a sale (to a person) within EU.