Slashdot videos: Now with more Slashdot!
"I kind of wish there were two paths to get Linux on the desktop. A cutting edge path, tailored to the distro, and a Standard Desktop for Linux (SDL) that was included with most distros (voluntarily) that was designed for minimal change over the years (bug fixes and minor improvements, but otherwise stay the same). During the install, you could just select the desktop environment you wanted. "
It's called Debian and you can make it as big or as small as you like.
Link to Original Source
The following attributes are a must:
1.) Must be a pro-level/enterprise tool, meaning: When I learn it in the end I should be closer to typical enterprise products like jBoss, Glassfish, Oracle Whatever, SAP Whatnot, IBM Websphere, etc. with the knowledge gained. Ergo: Not some avantgarde experiment that has me crying myself to sleep once I get a gig at some Java shop that uses todays regular products, but something that prepares me for the things to come. At least a little.
2.) I'm willing to use some avantgarde stuff if it is stuff I can easyly integrate into existing enterprise toolstacks later in my career (SAP, Oracle, IBM, ect.) without having to install countless things below the regular Java level. Or obscure Java Libs that are a licencing liability to my employer/client.
3.) This one's a little contradiction with point 1: I which it to have absolutely zero fuss in integrating application and persistance. Think Zope/Plone. If I build a type/entity I want to do that exactly once and only once and I do not want to be manually editing XML in order to do so. Best would be if it had some kind of modeller where I can click together my entities and objects, maybe in some Java Application or a Web/Ajax Backend Interface (very fancy I know). I wish to avoid seperate persistance level logic programming with a specific language (read: No SQL or XML Situps!) entirely. In other words: In terms of persistance/applevel integration I really would like to leave the current state of things which to me appears to have been stuck in the early 90ies. I have no problem if this is all covered by fully automated scaffolding/crud or whatever and tons of autogenerated SQL in the background — I just would like to avoid having to deal with seperate layers alltogether whilst prototyping. Basically I'd like to stick to building my objects/types in Java and nothing else.
4.) The product should be either a one-command install on x86 Debian stable and other x86 Linux distros or should be easy to deploy manually with just a runtime as a prerequesite and a jar or something. Likewise it should be easy to deploy the required runtime environment and sub-libs on Mac OS X Snow Leopard. It should have a webserver option that is production ready and tried-and-true tested. It would be nice if that webserver option would either be an intergrated HTTP thingie inside the Java product or a first-choice integration with a FOSS HTTP Server binary that is *not* Apache, like lightHttpd or whatever the newest hype in enterprise ready lightweight HTTP-thingies is. I'd like to avoid Apache Configuration hassles just as I'd like to avoid SQL hassles.
6.) It should be established as a product — at least in the FOSS community (not just on one obscure mailinglist somewhere deep in the massive Apache Java Project grabbag) or be notably promising with a small company or dedicated team behind it. Something like PHPs ZendFW, Symphony, the Typo3 or Rails community — they've got a hang at pushing their stack in respective markets. (I.E.: Their websites don't look like shit and the projects opinion leaders actually know that marketing is important — even for a FOSS product) If it's a young but promising project I have no trouble helping out once I'm up to speed, so don't hesitate to advertise your own below, just don't ignore the requirements above completely.
Bonus points if the product has a braggable enterprise customer/user list and a real shot at pissing into the soup of the established players (Oracle, SAP, IBM, etc.).
Number 6 and 7 are nice to haves:
6.) Native integration with a well-established seasoned Ajax Toolkit like Sencha/Ext3, jQuery UI, Tipco GI or something of the sort. Perferably with a FOSS interface builder along with it.
7.) Built with zero-fuss Mobile App integration (Android & iOS) in mind, since I think we all agree that that is the next big thing. Perhaps Android/iOS Libs already in place/available or something like that.
Thanks for you input, it's allway a great help."