One big advantage is that Shared Folders work even if networking support is disabled. You can, for example, set up a VM with no virtual NIC to simulate a PC with no Internet connection, or you can disable the virtual NIC, but you can still used Shared Folders to get at files on your host. Shared Folders also keeps working if your PC becomes disconnected from the network, where bridged connections do not.
Another advantage is Shared Folders use the security privileges of your HOST, not the GUEST. This can be useful to access Windows domain resources from a guest that isn't part of the domain. This can also be useful if your VM can't access the domain resources directly due to technical limitations (no support for Active Directory, etc). You can map domain resources onto the host, then share those resources using Shared Folders into the guest.
I mostly use VMware Workstation on Windows, but I'm sure there are similar situations on a Linux host/guest where the Shared Folders feature can let you work around networking issues if you just need to get some files in and out of the VM.
I always play female characters in games, even single player games. Why? It's quite simple. Female characters are not as common, not as well implemented, and generally need to be supported more often.
For every game you find where you have the option of playing a female character, you can find countless other games that force you to play a male character. And even those games that allow you to play female characters often do not implement the female options as well as the male options. Female characters will have fewer models/clothes/faces to choose from, fewer sidequests, etc. In the worst cases, other characters will accidentally refer to you as "him" even though you're female. To be fair, female options have gotten better overall recently, but they still aren't as good as they should be.
What better way to ensure gender equality in video games than to play games as a female character and complain to the developers about any problems you have with the experience?
How many people actually say just "Linux" anyway? The term "Linux" itself has little meaning, unless you're referring specifically to the kernel. Usually, if I'm talking about a "Liunx" system, I'll say "RedHat," "Debian," "Slackware" or whatever the distribution's name is. Generally, the most specific name with the least ambiguity is the best name to use. Adding "GNU/" in from of "Linux" results in a name that is no more useful than just "Linux." You still don't know exactly what you're talking about (except that whatever it is uses some GNU software).
The only place where I see "GNU/Linux" being useful is if you want to talk about all the current, popular distributions of "Linux," which are based on GNU, like the FSF says.
Why are they setting dates in the first place? Can't they just say that they will release it when feature A, B and C are implemented and stable?
Setting a date helps to ensure that the project stays on track. It gives everyone a sense of a real goal, and urges developers to complete their portions of the project on time. If you just say "We'll release it when it's done," you often end up with everyone thinking "Oh, I've got lots of time... I'll work on my code tomorrow" and nothing gets done.
It's not setting development deadlines that's a bad thing. It's having deadlines that are cast in stone and set by people who have no appreciation for how long it takes to develop the software that is bad. I'm very glad to see that FreeBSD is setting deadlines, attempting to meet those deadlines, and adjusting those deadlines as required to ensure success of the project.
Having gone through 5 Co-Op terms as part of my CS degree at university, I can tell you that what you're experiencing is generally the way it is. The fact is, no company wants to hire an "uneducated student", give them lots of responsibilities, and lose more money when the student fails to meet the challenge than if they had simply hired a "trained professional". This is true when you first start working full-time as well. You'll almost certainly get no major responsibilities in the first few months. It takes time for people to get to know you, see how eager you are to perform and learn, and find the limits of your capabilities...
The best thing you can do right now is be eager to do as much as possible, within your own limits. If they give you grunt work, just do it without complaint, and do the best job you can. People will notice, eventually. Try to ask questions and appear interested in things you aren't currently working on as well. If you show an interest, and more importantly an understanding of more complicated tasks, you'll be more likely to have them assigned to you, or at least be asked to help.
As for what would make Co-Op programs better? Longer terms. The program I'm going through has alternating 4 month cycles of School/Co-Op. 4 months is fine for classes, but is too short to get to know the company and people you are working for. If the terms can't be lengthened, then you should definitely try to go back to the same company a second time, if you have the opportunity to do so. Once people know you, the whole experience is MUCH more rewarding, for both you and the company involved.
Slashdot Mirror
One big advantage is that Shared Folders work even if networking support is disabled. You can, for example, set up a VM with no virtual NIC to simulate a PC with no Internet connection, or you can disable the virtual NIC, but you can still used Shared Folders to get at files on your host. Shared Folders also keeps working if your PC becomes disconnected from the network, where bridged connections do not.
Another advantage is Shared Folders use the security privileges of your HOST, not the GUEST. This can be useful to access Windows domain resources from a guest that isn't part of the domain. This can also be useful if your VM can't access the domain resources directly due to technical limitations (no support for Active Directory, etc). You can map domain resources onto the host, then share those resources using Shared Folders into the guest.
I mostly use VMware Workstation on Windows, but I'm sure there are similar situations on a Linux host/guest where the Shared Folders feature can let you work around networking issues if you just need to get some files in and out of the VM.
I always play female characters in games, even single player games. Why? It's quite simple. Female characters are not as common, not as well implemented, and generally need to be supported more often.
For every game you find where you have the option of playing a female character, you can find countless other games that force you to play a male character. And even those games that allow you to play female characters often do not implement the female options as well as the male options. Female characters will have fewer models/clothes/faces to choose from, fewer sidequests, etc. In the worst cases, other characters will accidentally refer to you as "him" even though you're female. To be fair, female options have gotten better overall recently, but they still aren't as good as they should be.
What better way to ensure gender equality in video games than to play games as a female character and complain to the developers about any problems you have with the experience?
How many people actually say just "Linux" anyway? The term "Linux" itself has little meaning, unless you're referring specifically to the kernel. Usually, if I'm talking about a "Liunx" system, I'll say "RedHat," "Debian," "Slackware" or whatever the distribution's name is. Generally, the most specific name with the least ambiguity is the best name to use. Adding "GNU/" in from of "Linux" results in a name that is no more useful than just "Linux." You still don't know exactly what you're talking about (except that whatever it is uses some GNU software).
The only place where I see "GNU/Linux" being useful is if you want to talk about all the current, popular distributions of "Linux," which are based on GNU, like the FSF says.
Setting a date helps to ensure that the project stays on track. It gives everyone a sense of a real goal, and urges developers to complete their portions of the project on time. If you just say "We'll release it when it's done," you often end up with everyone thinking "Oh, I've got lots of time... I'll work on my code tomorrow" and nothing gets done.
It's not setting development deadlines that's a bad thing. It's having deadlines that are cast in stone and set by people who have no appreciation for how long it takes to develop the software that is bad. I'm very glad to see that FreeBSD is setting deadlines, attempting to meet those deadlines, and adjusting those deadlines as required to ensure success of the project.
Having gone through 5 Co-Op terms as part of my CS degree at university, I can tell you that what you're experiencing is generally the way it is. The fact is, no company wants to hire an "uneducated student", give them lots of responsibilities, and lose more money when the student fails to meet the challenge than if they had simply hired a "trained professional". This is true when you first start working full-time as well. You'll almost certainly get no major responsibilities in the first few months. It takes time for people to get to know you, see how eager you are to perform and learn, and find the limits of your capabilities...
The best thing you can do right now is be eager to do as much as possible, within your own limits. If they give you grunt work, just do it without complaint, and do the best job you can. People will notice, eventually. Try to ask questions and appear interested in things you aren't currently working on as well. If you show an interest, and more importantly an understanding of more complicated tasks, you'll be more likely to have them assigned to you, or at least be asked to help.
As for what would make Co-Op programs better? Longer terms. The program I'm going through has alternating 4 month cycles of School/Co-Op. 4 months is fine for classes, but is too short to get to know the company and people you are working for. If the terms can't be lengthened, then you should definitely try to go back to the same company a second time, if you have the opportunity to do so. Once people know you, the whole experience is MUCH more rewarding, for both you and the company involved.