I'm not sure that documentation is correct - there were some changes in the installer for F17 that lowered that memory requirement and we explicitly tested installs with 512 MiB (the hard coded minimum for install with Fedora 17). I've seen reports of successful installs with 384 MiB and enough swap (using the nomemcheck boot parameter) but AFAIK, that isn't supported and YMMV.
As far as why the installer needs that much memory, there are several things but yum, rpm and selinux are big memory users.
While it is a little old, one of the Anaconda (the name of the installer used in Fedora) developers did an analysis on where all the memory is used during installation [1] which I found to be rather interesting.
"Your browser fingerprint appears to be unique among the 2,155,876 tested so far."
Huh, that's awesome ... in a bad way. According to that page , both my system fonts and browser plugin details are unique among the browsers they've tested thus far.
Unfortunately, gnome-shell doesn't work well in VMs due to the fact that it requires 3D acceleration. AFAIK, virtualbox is the only platform that supports 3D emulation but I can't speak to how well it works because I haven't tried it myself.
However, software rendering support has been recently added to rawhide (which will become Fedora 17 in about 6 months). If you're interested in seeing gnome-shell in a VM, you may want to give Fedora 17 a try when it is released.
Yes, you can upgrade that way but it's not recommended (see the warning @ the top of that page). That upgrade method isn't really tested and may or may not work depending on your system.
You'd be much better off using PreUpgrade (making sure you update your system first) [1] or the install media. If you don't want to burn a DVD or CD, you can make a bootable USB stick with the iso [2].
Wow, it works for me with FF 7.0.1 and nouveau on Linux. A little laggy when I go fullscreen, sure but the last time I tried viewing WebGL FF told me that my 3D setup wasn't supported.
Anyhow, cool presentation. It's impressive to see how WebGL is progressing.
"Testing is a tool for helping you, not for using to engage in a 'more pious than thou' dick-swinging my Cucumber is bigger than yours idiocy. Testing is about giving you the developer useful and quick feedback about if you're on the right path, and if you've broken something, and for warning people who come after you if they've broken something. It's not an arcane methodology that somehow has some magical 'making your code better' side-effect..."
I liked this part; it made me laugh. I also get red flags whenever I hear "X is the one true way to do Y" statements. Personally, I don't think that there is much in life that is so black and white that there could be "one true way" to do anything.
My understanding of the original agile methodologies was that each team/company needed to do what worked for them. Sure, you could follow some book to the letter and hire some certified SCRUM master but odds are, some deviations from the written plan are needed for the best results.
Either way, I'm generally a fan of TDD, test automation and metrics ... where they make sense and where they aren't going to be abused. Use tools and methodologies that make sense for the current situation, not just because some book/person tells you that you'll fail unless you use them.
I've never applied for a job at Amazon but I have done the same thing with other companies. When I was last looking for a job, I found a couple of interesting positions whose HR systems would only take resumes in MS Word. I closed the tab and kept searching.
For me, it's a practical and ideological thing. My resume is written in LaTeX (with a plain text version) and unless I'm missing something, there is no good or easy way to convert from LaTeX to MS Word. I also have doubts about a company that insists on word documents - it smells like inflexibility and a heavy-handed top down management approach.
The CentOS kernel is just a rebuild, so there is no problem there. In the case of the centosplus kernel, because it may add patches, some extra steps might be needed. But again, that is not a major issue.
Disclosure: I do work for Red Hat, but not on RHEL. Just posting info I saw earlier.
One of the proposed long term goals (still going through the approval process) for the Fedora project is to lower the barrier of entry for new members (Not a great link but one of the better ones that I could find: https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-12...)
DISCLOSURE: I do work for Red Hat on the Fedora project but my interest in open source is also personal. I suggested this because it seemed appropriate and I'm familiar with it.
Yeah, I know what you mean about solutions. Actually solving the problem at hand is a whole different world than finding the problem.
I know that I've been guilty of not making/updating screenshots very frequently - they tend to be a pain. Something to keep in mind for the future, though.
A collaborative design environment is a hard one. I've found it really useful for code in the past but as you said, that doesn't help a whole lot on the design front. The only practical thing I can think of at the moment is sending links to static images back and forth over chat, but that doesn't get over the barrier to entry on chat.
The only other things I can think of there would be screencasting (which usually costs money and tends to be a little more one-way) and VNC but that requires a lot more trust than I have for strangers (or than I would expect them to have for me).
Team structure might be a hard one. I can't speak for all developers but I generally don't like having a formal team structure if it can be avoided. Do you think that the role part is important or just discrete, specific tasks? If you were thinking of more of a control thing, that might be even harder. Unless I'm the only developer, I generally don't expect to have much control over a specific area. Then again, I also wouldn't expect people to be jerks and completely change something I did without at least talking about it first.
As far as rapid prototypes for web applications go, I LOVE wicket (http://wicket.apache.org/) because your templates are pretty much CSS and HTML (none of that pseudo-code in templates crap) and you have pretty much complete control over your javascript. You can mock up an entire site in HTML and only need minimal changes to get it working with backend code.
I don't have as much experience with desktop applications but I wonder if rough HTML/CSS might also work for the interactive parts. I'd have to think about that one and it might be an excuse to try mocking up a desktop app I've been thinking about.
I don't know if you'd be interested or if it would work, but I'd be up for at least talking about less uncertain ways to get your students involved in open source.
I have a couple of ideas for projects that I'd love to get design help on as long as I'm not completely left out of the design loop. Getting more people (and especially non-coders) involved in open source and helping in education would be bonuses.
While my statement probably doesn't covey this very well, I certainly am not an advocate of amalgamating dirty hacks or throwing any thoughts about good design out the window in the name of speed. You are quite right that leaving design until the very end isn't incredibly efficient or effective.
I'm also not a big believer in the "big design effort up front" methodologies. I tend to think of design (of code, at least) as more of an iterative process. I can't think of a single project I've worked on where a big design effort up front hasn't gone through a huge change before project completion.
Why spend all that time on a huge, detailed design that will end up being partially thrown out in the end when you can make iterative changes and design some things as you go?
Granted, this doesn't work in all situations and you do need good developers who are willing and able to write good, testable code and throw it away at a moment's notice.
If I code something in the "first make it work" phase that isn't throwaway code or can't be completely ripped out and rewritten without too much risk/effort, then I have failed as a developer.
Another mantra I try to code by is: never let perfect be the enemy of good. Perfection is never done and the best design in the world means nothing if it never gets finished.
That's an interesting question. I also wonder how you would get designers to start open source projects without getting the opposite of a "developer-centric" project where developers are the second class citizens.
Can you (or others) elaborate a bit more on what a place where a designer could expect to create really great work would look like? Is it more of a personal aesthetic thing (something that is personally interesting)? Is it related to some of the other points in this thread (unfriendly tools, gruff face to the community, lack of control etc.)?
re: 2)
I can't speak for all developers, but I generally try to work with the mantra of "first make it work, then make it work well and then make it pretty or fast (depending on what the project is)". I guess that I am a little guilty of thinking of "design" as mostly eye candy and nice-to-have (when in reality, some parts of design probably should be part of making it work well). But I also abhor applications that have some shiny/slick interface and don't work well at all.
re: 4)
As a developer, I recognize that I am not the best at everything and don't pretend that I could design an awesome Wordpress theme if my life depended on it but as you point out, design is not just the "eye candy". At the same time, I am not just an codemonkey. I want to participate in making something awesome, I want to learn and I want to work with people who know more than I do (I learn more that way and will probably come up with a better result).
In my mind, there is a difference between working together and saying "developers can't design, just go over there and write some code to make my vision come true" (I realize that I'm exaggerating a bit here). Any hint of a "just shut up and color" mentality makes my hair stand up in ways that I just don't have words for.
I don't think that either extreme (designers are the only people who can design or 'I can do it myself') is the right answer in any projects where volunteers are involved. As you pointed out, the trick is finding a happy medium and some way for people who stereotypically think in different ways to find common ground.
Now I have some thinking to do about how I can help reach that common ground in the projects that I work on and will work on.
* Edited formatting because it was hard to read. I'm new here and learning.
[1] http://forums.fedoraforum.org/showthread.php?t=274611