Something this basic requires a posting on the front of Slashdot? Great choice, kdawson!
I'll be sure to try and get my article about setting Openfire up on FreeBSD here soon..........
Oh, I know a lot about ORMs. You just seem a little angry that people don't agree with your views on them. You calling me inexperienced demonstrates this when, in fact, the contrary about me is true.
Also, they put the ability to write your own code in there for a reason. Reasons like I discussed in the GP. I'll bet that between your code and mine, people will pick up and learn my code faster than your convoluted object model
Peace.
I'd guess they compare RoR to PHP because that's the only "compelling" tool in Ruby to use for web development. At least, it's the most well-known one, meaning it's better for production environments, because it will be more stable and have more developer mindshare than X framework in Ruby.
So, I think the real debate is over whether to do things in PHP, where mindshare is massive and there is no ORM (which I think is great... though maybe a PHP ORM does exist) or whether to do things in Ruby+RoR, where mindshare is much smaller and ORMs are in play (you already know my personal opinion about this).
Any RoR developer I've ever talked to was just into it because it was "hip". That's fine and all for toy projects, as I've used that excuse in the past, but it's not an appropriate reason for choosing production-level languages. For that, you just have to sit down and hammer out the details of what the tools/languages are going to offer you or prevent you from doing (easily).
My comments aren't to say that RoR doesn't have benefits that actually make it useful. In fact, that'd be difficult for me to say either way, because I have not used it.
I do know that, in general, ORMs are slow, difficult, and language/library-specific when compared to some more general DB access libraries out there. Really, it doesn't take a lot of code to setup an object that can use a DB in an optimized fashion if you just write that code yourself, and it'll be a lot clearer without all the "magic objects" floating around.
For examples of slow code, try writing Hibernate apps in Java that must use saveOrUpdate() when you could easily write some more explicit code to do any pre-caching for you. Same principle will apply to other ORMs.
No, you can just use set a boolean in your inner-loop that outer-loops use when you break from the inner-loop. Also, you can create inline functions if you really wanted to go that route.
As for C++, 64 KB of bloat for exceptions is nothing compared to the performance cost of handling exceptions. For the architectures you mentioned, it's an issue, which is why C++ either isn't used or is used without exceptions. However, for the majority of systems, exception-handling performance trumps a boost in run-time size.
Of course, for me the "year of the Linux desktop" was years ago. And because of this, I'd like to see it more widespread. Mainly because you are right - there are some proprietary software that has no equivalent. I'd really like the option of buying said software and running it on my platform of choice. But that's not really anything more than a personal wish.
How much time did you spend getting your desktop running? I've run them as well (and still do), and it took a lot more time to get it running than it did the first time I ever used Windows or OS X. I haven't ever heard anyone say that they had a first-time full multimedia setup going in a FOSS OS faster than their first-time full multimedia setup in Windows or OS X. Newbs just don't know about Xine, VLC, all the codecs they'll need, where to get them, or how to handle their package management systems until they spend plenty of time reading about them. And, really, time is money, and it may cost too much in certain situations.
Yeah. We're never going to see a Tivo, TomTom, or Google. We're never going to see the various private architectures I've supported for my employers. Just not going to happen.
I think perhaps I wasn't clear with what I meant. I meant that people aren't going to create an innovative solution as a FOSS platform, because there is no immediate reward. Because, like I said, people want and need money. As far as I know, none of the products you mentioned are open-source; by the time they are (if ever), it will be because they see no more benefit in keeping them proprietary.
I also use a lot of FOSS and a mix of proprietary. I always give the FOSS solutions additional points in any given consideration. I hate being beholden to any given vendor for numerous reasons. FOSS gives me options that proprietary solutions rarely (if ever) provide. But there are times that a proprietary solution is just too good to pass up. We will then risk it and deal with the risk involved (sometimes we never have to worry about it, sometimes we get bitten).
So, you give FOSS a higher default rating based on an ideological reason rather than an objective one? It sounds like you let personal views cloud your judgement when making software decisions. FOSS should only be one factor in the acquisition of something for use. I also think that in terms of TCO, going with an excellent proprietary solution, even if it is converted to a better FOSS alternative in the future, will be lower with the proper development team in place. The only time this may not be the case is if you have a team of developers that's really going to broaden the base product and make it genuinely awesome for your task.
Really, the software we use should be used because it's the best tool for the job. If it's a FOSS solution, great. If you have to pay for the appropriate tool, do it. Vary your choices according to objective reasoning and budget constraints. If you feel a FOSS alternative should be created, do it, but that points back to my point about people not innovating on FOSS platforms.
If all else fails, lower your standards.
