It's not that simple with Free Software vs proprietary software.
He believes that it is that simple.
I don't think he believes it's as bad as murder, but I do think he believes that people's rights are being taken away from them, in the same way that we cry out when people's right to free speech/free association/etc. is taken away.
Murder is a bad example, because it does tend to be quite clear (but I could easily bring up revolutions, capital punishment & abortion. They don't have as much agreement), but if you compare it to other "rights" like free speech, it becomes clearer. RMS treats the loss of software freedoms the same way as he treats the loss of other basic freedoms. A lot of people make a lot of noise about free speech, and rightly so. And in Stallman's world view it is just as appropriate to make the same noise about free software.
from what I can tell you (and/or others in this thread) are saying "Don't rant about it so much, it's not such a big deal". My point is that the key to that argument is the second part, not the former.
You can only convince him to tone it down, if you can convince him that it's not a big deal. I don't think you could get to him to a state where he still thought it was a big deal, but didn't talk about. And I would hate to see that happen - I think people should stand up for what they believe.
I support Free Softare, but I don't think it is such a big deal that it warrants RMS's stand on it. But for as long as he believes it is, I want him to keep saying it.
Not that hard, if you actually put your brain to the task.:) There is a core set of behavior that is damaging to society as a whole, whether the behavior is practiced by politicians or criminals (the same class!) or whatever. Murder is in this class of behavior. This behavior, when let run wild (as in the favorite cite of Nazism) isn't just damaging to the world we live in, it can potentially destroy the whole world and all of human existence. Therefore, for pragmatic reasons, this behavior shouldn't be allowed by the forces that be, and if they practice this behavior, they should be thrown out and new powers installed.
But Stallman's position is that the use/production of non-free software is also in that class of behaviour. That the production of non-free software is so limiting to the freedoms of the citizens that it is immoral and should not be allowed to occur. [Well that's my paraphrasing of him].
Given that he holds that belief, it makes every sense for him to continually argue his point. Because he believes he is fighting for a cause that attempts to rescue society from an unchecked evil, he in fact has a responsibility to pursue change in every way.
I am of the opinion that if society is committing an immoral act (e.g. Mass murder) then those people who see the error that is occuring have a responsibility to rise up against it. Stallman believes he is in that situation.
So, the issue (to me) isn't whether Stallman should be arguing so much, it's whether he is right in his belief about Free Software.
I don't think he is - but I'm not going to tell him to shutup, because I don't want to silence people who seek to remedy evils in our society.
I would argue against his beliefs if I thought it would do any good, but I consider that the effort would be wasted, and that it is not of particular importance.
Or are you suggesting that Java's library is simpler than C++'s?
I think that's true, but I don't think it's the main reason why I prefer writing in java.
In my mind the problem with C++ is the patterns - there's too many of them.
Pass by value, pass by reference, who takes ownership of this memory, is it shared?
Difference groups of people do it a different way, and so each time you use their code, you have to work out what patterns they use, and find a way to bind them into your design.
That problem is made worse by the fact that the std library is quite small, and historically was even smaller - lots of people wrote lots of libraries and there's no common theme.
In java it's easier. Most things follow the same pattern - partly because there are less patterns to chose from (all the memory managament ones dissappear) and partly because the library is more cohesive.
an extra step that's not necessary with Ant as all the tasks are written in Java and therefore cross-platform without requiring platform-specific configuration.
Bah!
The step's there, it's just that the Ant developers have already done the work.
Getting Ant to work on Netware was an amusing exercise to watch.
Ant isn't really anymore cross-platform that the solution suggested by the previous poster, it just hides the platform differences in a different place.
If he writes a platform.cfg and uses it for every project then the "extra step" is already done, and his solution is pretty much the same as Ant.
You compile it on one platform and run it on many others -- you don't recompile your Java code on each platform!
Ummm... this is open source.
People download the source and modify and compile it on whatever platform they want.
Ant was specifically written to make it easier for people to compile Tomcat 3.x across a variety of platforms.
Distributing a set of makefiles that would work on all possible platforms was a nightmare, writing a simpler cross-platform tool was the best solution.
Unfortunately the users of that tool then went and decided that it suitable for all java development, and Ant was unleashed on the world.
If they have outstanding ability then you would not need XP to begin with
No, but they may want it.
The biggest thing I like about XP (and other agile methodologies) is the requirements approach.
I'm sick of projects where the requirements change, but there's no formal process to handle the change.
The team has to keep changing things to cover the requirements change, but process doesn't officially recognise the change, things just go crazy.
The biggest benefit of agile is that it recognises that change happens. It happens because, over thel ife of a project, the business needs change, and also because it is very hard for people to even know, let alone explain what they want up front.
XP is great, but add into it a shaky designer, a loner in the team, or a delusionned manager, and the whole thing will crash down in flames.
I'm not sure it's that black and white.
I would suggest that in XP (and most other agile methodologies) you need the following three roles to be well filled:
Architect
Project Manager
Lead Developer
Depending on your project/team size, one person may fill more than 1 role, (or you may need 2 people for a given role).
I don't think the developers need to be that great. It obviously helps - better people produce better results - but it's not required.
I guess if they're hopeless developers then they won't cope, but I think that's true in all methodologies.
Other methodologies will possibly cope without those roles, but they will still (ultimately) be failures (assuming the project has sufficient complexity).
We took an existing development team that was decent, but not brilliant, an enthusiastic project manager and added a couple of experienced people (an architect and a developer), and the project is working very well. Much better than any previous methodologies we used.
Part of that is due to the people we brought in, but they're really only there because we needed some architectural guidance for this project (we were using some technology that was new to our existing architects) and we wanted a mentor (both for XP and for the technology).
Once we get enough people with experience, we won't need them anymore, and I think we will still be successful - but you don't need people to fill those roles.
if you have the enthusiastic involvement of upper management you can probably get ANY project to succeed.
You seriously believe that?
The enthusiastic involvement of upper management can help, but it's by no means a sufficient condition.
I've seen lots of anthusiastic managers who don't notice when their teams is saying
The requirements don't make sense
We don't have time
You need to invest in more testing
This project is doomed
It's not about enthusiasm, it's about management being supportive of the development team, and the development team being right.
If you don't have both of those, then you will have problems.
In my experience management can kill a project, and they can help a project avoid death, but they can't make a project actually work.
Re:Natural Selection is Fantastic
on
Gaming Goodness
·
· Score: 1
However, people with "Excellent" karma shouldn't abuse the bounus (which is +1, not +2) by using it on contentless posts.
I think the "No Score +1 Bonus" is back-to-front.
You should have to manually tick a box each time before you can get the bonus, so you at least have to spend a micro-second thinking about it. Asking people to volunteer to give up their bonus is giving them more credit that most/.-ers deserve.
Even better would be if it was only available to select after preview.
Re:Balancing Issues in NS
on
Gaming Goodness
·
· Score: 5, Interesting
I agree with what you say, but I'd like to make my own comments.
Th designer need to draw a distinction between a "full frontal assault" (FFA) and a "full frontal assault in the first 5 minutes" (rushing).
The FFA should be an acceptable tactic. If you're a marine, it is a good strategy to wait until half the alien team is away from their hive, and then go in with guns blazing. It just sucks when you do it in the first 5 minutes, and the game is pretty much decided from that point on.
So, they key is really to make it relatively easier to defend than attack, during the first few minutes.
How do you do that? Lots of ways
e.g. Give the team a useful defensive weapon that has limited lifetime (pehaps a fixed number of proximity mines), so that they can lock down their base for a short period, while they build up.
Or, make the maps harder to navigate. Have doors that don't open straight away etc. Make it hard to get to the other team in the first 5 minutes.
Now, I haven't played NS yet, but in general the key really is to make it hard to attack at the very beginning. It's not really about balancing the sides, it's about making sure the game last long enough for the strengths/weakneses of each team to come out.
You need to decide what it is you want to stop, and then you can evaluate the options.
the tendancy for some users to open executable attachments no matter what they are told
There's two parts to that:
some users
executable attachments
The simplest solution is to strip all executable attachments. Save them somewhere and add a piece of text to the mail saying Attachment 'blah.exe' stripped for virus protection. To get a copy of this attachment please call the helpdesk and quote 'Attachment Id: 44591'
It's a bit painful, but it stops people from randomly clicking on attachments.
If they need the file they can call the helpdesk and they can release it for them. It tends to work.
You can also throw in the first point of "some users", and have this based on user.
It depends on how you want to balance the factors of:
Risk of letting a virus through
Risk of false-positives
Annoyance to users
Cost to implement
Cost to run
You really need to think about those, and come up with a solution that's right for your organisation.
also trying out something like ant instead of the various forms of make
I'll avoid my anti-ant rant here, but will suggest that you don't need to throw out make to go cross-platform. GNU make will run on *nix and Windows (cygwin).
You can have cross platform makefiles.
Especially if you have control over all the platform.
I don't think it'd be that difficult to migrate their existing makefiles into ant-usable xml build files.
Doing a very rudimentary conversion wouldn't be too hard, but Ant doesn't natively support a lot of stuff that make gives you out of the box. Converting that is not going to be easy.
The biggest issues with using Ant on such a project would be:
Lack of good C/C++ tasks. Various people have proposed tasks, but I've not yet seen one that is well tested and well supported.
Poor dependancy analysis. Ant just simply doesn't do dependancies that way make does. You can do your own dependancy analysis if you want, but Ant's premise is completely different to make.
Ant works on the idea that you build a system by going through a series of tasks. Compile the code, package it up,... That's fine for java, but for large C/C++ systems it isn't so useful.
Ant build scripts get very compliacted very quickly. I don't believe that Ant scales well to large projects. Make struggles, but it has features that make it a better solution.
Ant and Make a fundamentally different concepts. Converting from one to the other is not easy, and trying to use the ant method on non-java code is (IMHO) a bad idea.
I don't see what benefit Ant would give a C/C++ developer.
Ant is kind of nice for Java work, but if you're writing a C++ app then using Ant is bordering on the insane.
Ant does not simplify a build process unless you're running a fairly standard Java project, or you don't have anyone who knows how to use make properly (writing simple things in Ant is easier than writing simple things in make, but Ant doesn't scale)
If you want cross platform, just use GNU make on all your platforms, and put wrappers around the compilers so they accepts the same commandlines.
The solution to your issue seems to be:
Use cygwin on Windows so that all your platforms have similar tools.
Install bash and GNU make on all your *nix boxes. (You could use cons or jam, but it doesn't appear that you need to)
Use the native compilers for speed.
Write a compile.sh shell script that takes the same commandline syntax on all platforms, and converts that into the correct syntax for the native tool. That way you don't have to worry about putting all that logic into the makefile.
Do the same for linking, dependancy generation, etc. etc.
That should clean up your build process. If you need to hire a build engineer, then do it. Get a professional in for a month to pull everything in to place.
As for the code...
If you've been doing this for so long then why is it an issue any more?
Surely you have established patterns to solve common problems.
Abstract!
Don't solve threading problems more than once, put a common abstraction layer into your code.
If one compiler doesn't support templates properly, then document it, and tell the team not to use templates in that way.
You have a fixed set of compilers to work with - it shouldn't take that much work to learn where they differ and document ways to work around the differences.
It would appear as though at least 12% of the invention was funded by the tax payer?
If the univercity owns IP, it does so on behalf of its "share-holders" (for want of a better term), and that income should not be considered to be self-earned.
Re:Time to buy SUN stocks ...
on
Yahoo Moving to PHP
·
· Score: 3, Interesting
I know you're being funny, but Yahoo runs on FreeBSD.
In fact one of the reasons they didn't use Java instead of PHP is that Java on FreeBSD isn't up to par.
So it's time to invest in Walnut Creek... no wait it's BSDI... no wait it's WindRiver... oh damn it! I give up.
*BSD is dying...
Slashdot Mirror
He believes that it is that simple.
I don't think he believes it's as bad as murder, but I do think he believes that people's rights are being taken away from them, in the same way that we cry out when people's right to free speech/free association/etc. is taken away.
Murder is a bad example, because it does tend to be quite clear (but I could easily bring up revolutions, capital punishment & abortion. They don't have as much agreement), but if you compare it to other "rights" like free speech, it becomes clearer. RMS treats the loss of software freedoms the same way as he treats the loss of other basic freedoms. A lot of people make a lot of noise about free speech, and rightly so. And in Stallman's world view it is just as appropriate to make the same noise about free software.
from what I can tell you (and/or others in this thread) are saying "Don't rant about it so much, it's not such a big deal". My point is that the key to that argument is the second part, not the former.
You can only convince him to tone it down, if you can convince him that it's not a big deal. I don't think you could get to him to a state where he still thought it was a big deal, but didn't talk about. And I would hate to see that happen - I think people should stand up for what they believe.
I support Free Softare, but I don't think it is such a big deal that it warrants RMS's stand on it. But for as long as he believes it is, I want him to keep saying it.
But Stallman's position is that the use/production of non-free software is also in that class of behaviour. That the production of non-free software is so limiting to the freedoms of the citizens that it is immoral and should not be allowed to occur. [Well that's my paraphrasing of him].
Given that he holds that belief, it makes every sense for him to continually argue his point. Because he believes he is fighting for a cause that attempts to rescue society from an unchecked evil, he in fact has a responsibility to pursue change in every way.
I am of the opinion that if society is committing an immoral act (e.g. Mass murder) then those people who see the error that is occuring have a responsibility to rise up against it. Stallman believes he is in that situation.
So, the issue (to me) isn't whether Stallman should be arguing so much, it's whether he is right in his belief about Free Software.
I don't think he is - but I'm not going to tell him to shutup, because I don't want to silence people who seek to remedy evils in our society.
I would argue against his beliefs if I thought it would do any good, but I consider that the effort would be wasted, and that it is not of particular importance.
Artima has a couple of recent interviews with Andy+Dave that are worth reading.
Angel dark, it has ongoing story lines, and a little thing called "direction".
Buffy has gone of for so many series that Joss doesn't know what to do with it anymore.
Or are you suggesting that Java's library is simpler than C++'s?
I think that's true, but I don't think it's the main reason why I prefer writing in java.
In my mind the problem with C++ is the patterns - there's too many of them.
Pass by value, pass by reference, who takes ownership of this memory, is it shared?
Difference groups of people do it a different way, and so each time you use their code, you have to work out what patterns they use, and find a way to bind them into your design.
That problem is made worse by the fact that the std library is quite small, and historically was even smaller - lots of people wrote lots of libraries and there's no common theme.
In java it's easier. Most things follow the same pattern - partly because there are less patterns to chose from (all the memory managament ones dissappear) and partly because the library is more cohesive.
You think they'd have fixed it by now.
Bah!
The step's there, it's just that the Ant developers have already done the work.
Getting Ant to work on Netware was an amusing exercise to watch.
Ant isn't really anymore cross-platform that the solution suggested by the previous poster, it just hides the platform differences in a different place.
If he writes a platform.cfg and uses it for every project then the "extra step" is already done, and his solution is pretty much the same as Ant.
No it's not.
It's a cross-platform tool that attempts to solve a similar problem to that solved by make.
Make is a hell of a lot more powerful than ant, but some people are willing to trade in that power for the perceived simplicity of Ant.
Ummm... this is open source.
People download the source and modify and compile it on whatever platform they want.
Ant was specifically written to make it easier for people to compile Tomcat 3.x across a variety of platforms.
Distributing a set of makefiles that would work on all possible platforms was a nightmare, writing a simpler cross-platform tool was the best solution.
Unfortunately the users of that tool then went and decided that it suitable for all java development, and Ant was unleashed on the world.
No, but they may want it.
The biggest thing I like about XP (and other agile methodologies) is the requirements approach.
I'm sick of projects where the requirements change, but there's no formal process to handle the change.
The team has to keep changing things to cover the requirements change, but process doesn't officially recognise the change, things just go crazy.
The biggest benefit of agile is that it recognises that change happens. It happens because, over thel ife of a project, the business needs change, and also because it is very hard for people to even know, let alone explain what they want up front.
I'm not sure it's that black and white.
I would suggest that in XP (and most other agile methodologies) you need the following three roles to be well filled:
- Architect
- Project Manager
- Lead Developer
Depending on your project/team size, one person may fill more than 1 role, (or you may need 2 people for a given role).I don't think the developers need to be that great. It obviously helps - better people produce better results - but it's not required.
I guess if they're hopeless developers then they won't cope, but I think that's true in all methodologies.
Other methodologies will possibly cope without those roles, but they will still (ultimately) be failures (assuming the project has sufficient complexity).
We took an existing development team that was decent, but not brilliant, an enthusiastic project manager and added a couple of experienced people (an architect and a developer), and the project is working very well. Much better than any previous methodologies we used.
Part of that is due to the people we brought in, but they're really only there because we needed some architectural guidance for this project (we were using some technology that was new to our existing architects) and we wanted a mentor (both for XP and for the technology).
Once we get enough people with experience, we won't need them anymore, and I think we will still be successful - but you don't need people to fill those roles.
You seriously believe that?
The enthusiastic involvement of upper management can help, but it's by no means a sufficient condition.
I've seen lots of anthusiastic managers who don't notice when their teams is saying
It's not about enthusiasm, it's about management being supportive of the development team, and the development team being right.
If you don't have both of those, then you will have problems.
In my experience management can kill a project, and they can help a project avoid death, but they can't make a project actually work.
I think the "No Score +1 Bonus" is back-to-front. /.-ers deserve.
You should have to manually tick a box each time before you can get the bonus, so you at least have to spend a micro-second thinking about it. Asking people to volunteer to give up their bonus is giving them more credit that most
Even better would be if it was only available to select after preview.
Th designer need to draw a distinction between a "full frontal assault" (FFA) and a "full frontal assault in the first 5 minutes" (rushing).
The FFA should be an acceptable tactic. If you're a marine, it is a good strategy to wait until half the alien team is away from their hive, and then go in with guns blazing. It just sucks when you do it in the first 5 minutes, and the game is pretty much decided from that point on.
So, they key is really to make it relatively easier to defend than attack, during the first few minutes.
How do you do that? Lots of ways
e.g. Give the team a useful defensive weapon that has limited lifetime (pehaps a fixed number of proximity mines), so that they can lock down their base for a short period, while they build up.
Or, make the maps harder to navigate. Have doors that don't open straight away etc. Make it hard to get to the other team in the first 5 minutes.
Now, I haven't played NS yet, but in general the key really is to make it hard to attack at the very beginning. It's not really about balancing the sides, it's about making sure the game last long enough for the strengths/weakneses of each team to come out.
The English team is a big letdown.
the tendancy for some users to open executable attachments no matter what they are told
There's two parts to that:
The simplest solution is to strip all executable attachments. Save them somewhere and add a piece of text to the mail saying
Attachment 'blah.exe' stripped for virus protection. To get a copy of this attachment please call the helpdesk and quote 'Attachment Id: 44591'
It's a bit painful, but it stops people from randomly clicking on attachments.
If they need the file they can call the helpdesk and they can release it for them. It tends to work.
You can also throw in the first point of "some users", and have this based on user.
It depends on how you want to balance the factors of:
- Risk of letting a virus through
- Risk of false-positives
- Annoyance to users
- Cost to implement
- Cost to run
You really need to think about those, and come up with a solution that's right for your organisation.I'll avoid my anti-ant rant here, but will suggest that you don't need to throw out make to go cross-platform. GNU make will run on *nix and Windows (cygwin).
You can have cross platform makefiles.
Especially if you have control over all the platform.
Doing a very rudimentary conversion wouldn't be too hard, but Ant doesn't natively support a lot of stuff that make gives you out of the box. Converting that is not going to be easy.
The biggest issues with using Ant on such a project would be:
- Lack of good C/C++ tasks. Various people have proposed tasks, but I've not yet seen one that is well tested and well supported.
- Poor dependancy analysis. Ant just simply doesn't do dependancies that way make does. You can do your own dependancy analysis if you want, but Ant's premise is completely different to make.
... That's fine for java, but for large C/C++ systems it isn't so useful.
- Ant build scripts get very compliacted very quickly. I don't believe that Ant scales well to large projects. Make struggles, but it has features that make it a better solution.
Ant and Make a fundamentally different concepts. Converting from one to the other is not easy, and trying to use the ant method on non-java code is (IMHO) a bad idea.Ant works on the idea that you build a system by going through a series of tasks. Compile the code, package it up,
I don't see what benefit Ant would give a C/C++ developer.
Ant is kind of nice for Java work, but if you're writing a C++ app then using Ant is bordering on the insane.
Ant does not simplify a build process unless you're running a fairly standard Java project, or you don't have anyone who knows how to use make properly (writing simple things in Ant is easier than writing simple things in make, but Ant doesn't scale)
If you want cross platform, just use GNU make on all your platforms, and put wrappers around the compilers so they accepts the same commandlines.
The solution to your issue seems to be:
- Use cygwin on Windows so that all your platforms have similar tools.
- Install bash and GNU make on all your *nix boxes. (You could use cons or jam, but it doesn't appear that you need to)
- Use the native compilers for speed.
- Write a compile.sh shell script that takes the same commandline syntax on all platforms, and converts that into the correct syntax for the native tool. That way you don't have to worry about putting all that logic into the makefile.
- Do the same for linking, dependancy generation, etc. etc.
That should clean up your build process. If you need to hire a build engineer, then do it. Get a professional in for a month to pull everything in to place.As for the code...
If you've been doing this for so long then why is it an issue any more?
Surely you have established patterns to solve common problems.
Abstract!
Don't solve threading problems more than once, put a common abstraction layer into your code.
If one compiler doesn't support templates properly, then document it, and tell the team not to use templates in that way.
You have a fixed set of compilers to work with - it shouldn't take that much work to learn where they differ and document ways to work around the differences.
80% of your non-performance critical code in Java, and the later 10& in C/C++
And throw the remaining 10% out?
The super-parent post wasn't actually employing sarcasm.
</pedant>
Everything I ever needed to know about computer games, I learned from Penny Arcade
It would appear as though at least 12% of the invention was funded by the tax payer?
If the univercity owns IP, it does so on behalf of its "share-holders" (for want of a better term), and that income should not be considered to be self-earned.
In fact one of the reasons they didn't use Java instead of PHP is that Java on FreeBSD isn't up to par.
So it's time to invest in Walnut Creek... no wait it's BSDI... no wait it's WindRiver... oh damn it! I give up.
*BSD is dying...
Why does it work with Moz?
You can set the UserAgent in the mozilla prefs.js