The BRL-CAD project defines two levels of tasks geared towards new contributors. "Deuces" are small tasks expected to take less than 2 hours. "Quickies" take around 2 days:
You perhaps don't realize this, but a lot of people do not go by their first name.
Where I work, addresses were converted to firstname.m.lastname## and it has been a royal clusterfuck. There are hundreds of thousands of users, so there were even a ton of firstname.m.lastname conflicts (so they added numbers). It resulted in complete ambiguity with e-mails going to the wrong people all over the place and was made even worse by the assumption that their first name is always what people call themselves. Was Jim's address william.j.smith12 or william.j.smith13?
I think you'd be criminally liable to knowingly set up a new system that *automatically* creates ambiguity and confusion where there was none.
I believe the decision last year was that a student from any nation may apply, but they must be attending a university within the European Union.
Not really any less open than limiting the participation to full-time accredited university students. Unlike Google, their funding source isn't commercial, so it makes sense to try and keep it within their tax base. Moreover, I think explanation last year was something along the lines of there being an ESA mandate stating that more than 50% of their spending must stay within the EU.
As I see it, their money their rules. Nobody has to participate. It's great to see a large governmental organization stepping up to directly support open source regardless.
I used to love Palm until they became the company that acquired, sat on, and ultimately squandered BeOS. Good riddance and hopefully the door smacks your ass on your way out.
Apparently, other geeks/nerds find this article worthwhile. They're idiots or ignorant at best.:)
As you note, posters feeling otherwise is completely subjective (as is my view) and serves no basis of demonstrating right or wrong. It's purely anecdotal. As for why I respond, this is just an entertaining discussion on a topic I live, work, and breathe. Of course, I'll keep engaging in the discussion I started as long as I find it interesting to do so. I do not, however, see it as an argument or debate where we're going to come to some glorious agreement.
Like I said, we don't have to agree. We clearly do not. If you're not interested in discussing other notable CAD news (or even the PTC article), then leaving it at this end would be fitting. Have a great day!
That is a little cool actually, at least from a technical perspective. Z-sorting in code sucks big time. But yeah, it also sucks requiring specific hardware, the absolute latest drivers just to run, and without any backwards or hardware compatibility support. For the cost, they should be giving out free back rubs.
No more newsworthy than it would be to announce that Linux runs on AMD64.
Don't be an ass. Linux on AMD64 was huge news, especially as it was years before Microsoft and helped cement AMD's instruction set as the standard.
How's that being an ass? It was huge news. It wouldn't be if it were a headline posted today. We'd be asking what took so long, what were they waiting for. Adopting it after all your competitors doesn't make for news. It makes for shaking a little "me too" rattle. Good for PTC, but good grief. I expect more from billion dollar companies, which is what makes open source development all that more interesting a topic.
This isn't news to you. It is interesting and newsworthy to me[snip]
I would think that goes without saying; of course I only speak for myself. Defensive much? Shill? Trolling? I'll bite. I was commenting on how I perceive it (frankly as a paid-for posting) given the article's lack of content. Everyone's entitled to an opinion and fortunately we don't even have to agree on that point.
I agree with him completely. If you're not interested in this article, why don't you read and comment in another thread, one which you find interesting and newsworthy, instead of trying to convince us that this one isn't so.
Great, more power to you. I'm not trying to convince you of anything, contrary to your claim, but just replying to a thread I started. If it bothers you that much, you're just as welcome to disagree with someone else's thread too (or post your own).;)
Let's see. AMD, CAD, Pro/ENGINEER, GPU, wireframe rendering... Yup, pretty much spot-on geek nerd news. Or do you think the non-geek world would actually find this interesting?
Geek nerd topics, sure. Just not newsworthy. No more newsworthy than it would be to announce that Linux runs on AMD64. It's expectedbecause it's the smart thing to do. Pro/E is just behind the curve on this one. Most of the other CAD companies are already in bed with hardware optimizations. Still doesn't make it newsworthy though (did I miss a free Linux port or something? conversion to open source? those would be news!).
I never purported to speak for anyone else. My point was as stated -- that this isn't really geek nerd news. It's very much par for the course within the CAD industry. Hell, it's par for most big-industry fields these days, especially graphics-related ones.
The fact that Pro/E is jumping on a bandwagon says more about the wagon than the band. Understandably will be interesting to some people, but then so is the kid-got-shot-in-florida topic and it misses the target just as much.
Wow, talk about a blatant slashvertisement. As the summary states, it's not at all unusual for CAD/CAM software to ally with hardware so what exactly is the news for nerds here??
With more contributors working on improving BRL-CAD's usability and features, we'd have an open source alternative without the huge recurring price tag. Lots of ways to get involved are listed here: http://brlcad.org/wiki/Contributor_Quickies
BRL-CAD is a great project with an extensive legacy that doesn't get nearly enough developer attention. With hundreds of staff years effort invested across tons of functionality, it's really the *only* open source CAD system viable for production use, yet it's still in need of devs to help improve the interface and usability.
You'd think the massive market size of the CAD/CAM industry (estimated around $8B annual) would help, but that really just attracts LOTS of users. Thousands a month. Many understandably get put off by the steep learning curve and UNIX-style design or cry for features implemented in their favorite commercial CAD system that took loads of manpower.
The project is crazy active with the dozen or so devs that already do contribute, but the open source developer community at large doesn't seem to know about the project. Some are probably put off by the size of BRL-CAD (1M+ loc), but that's actually rather tiny for a production CAD system. The project deficiencies are well known (usability, interface!), but takes lots time and effort to make things better. Takers?
You're an applied mathematics student, so look for applied math projects. That way, you're newbie skills will be best put to use leveraging what you already know. There'll still be plenty you'll have to learn along the way, so put what you know to good use. Instead of projects like boost, sage, or octave, look for projects that have heavy applied math requirements like BRL-CAD, Blender, CGAL, and many many others.
Pick a community that interests you. Download the source code, compile and run the software, find their bug list, start fixing bugs. Introduce yourself when you have something useful to contribute (not just vaporware) or if you get stuck and need help.
These meters have been all around downtown Baltimore for a couple years now and while I agree that the round-trip to the ticket dispenser is annoying from an efficiency standpoint, it's still FAR better than coin meters if only for the sole reason that they take credit/debit cards. I don't keep change in my car (great way to get your car broken into in some parts). I haven't deliberately carried coins in my pockets for probably a decade.
The biggest problem I've had with the electronic meters is that you can't add time to an existing ticket. You have to either pay more in advance to 'make sure' you won't run out of time or you'll end up paying double for overlapping time. If I return back early and there's significant time remaining, I usually take the ticket back to the dispenser leaving it in the credit card slot or similar visible place so the next person can use it.
What do I really want? I'd like for people that touch my car while parallel parking to get an automatic citation. Let me decide whether to wave the fine or not. Hooking parking into the EZPass system would also be nice, so the parking spots know when I'm there, I'm automatically microbilled, and a ticket is no longer necessary.
It's not a big deal except to the PLplot devs as an arbitrary line being passed. Kudos to them for making ten thousand measured changes to their code, hope they make it to the next decimal place up. Probably not unlike the mild nod of appreciation you might feel when you hit 100,000.
It's a rather meaningless metric in general simply because there are massive differences in commit styles across projects and even within the same project. Even less meaningful than the meaningless lines-of-code metric. As an example, BRL-CAD's commits were almost universally 'huge' commits until it went open source. Then the more iterative 'chatter' commit style of most open source projects was adopted where they became much much smaller and considerably more frequent, communicating intent much better. Revision history that's actually useful! Even now, there are some devs that commit early, commit often, and others on the project that still have a tendency to commit big when left unchecked.
I'm certainly biased, but it's more than awesome in theory. The project has a lot of momentum and development going on not only towards addressing your concerns, but a lot of others as well. Most everything being worked on now is towards making the GUI much better.
That includes dropping Tk for the modeler (going to Qt now that it's LGPL). That includes implementing full BREP/NURBS support and multiple-representation geometry (no longer just unevaluated wireframes until render). That includes a fresh implementation of an OO geometry engine ala ACIS and Granite. That includes an extensible plug-in based application framework and a whole lot more.
BRL-CAD's main issues are 'cosmetic' problems that you don't even have to be a developer to help (vastly) improve. Docs, website, tools... The biggest problem (aside from needing more developers) is one of scope and expectations as CAD means a lot of different things to different people. Commercial CAD is major business with more than 2000 devs cranking features into the likes of CATIA, AutoCAD, Solidworks, NX, and Pro/E on a daily basis. BRL-CAD has two orders of magnitude less yet nearly the same expectations from users. The only way it's going to improve is through increasing development from the open source community at large to make things better, leverage the 500 staff-years invested, and push forward making great tools.
Slashdot Mirror
The BRL-CAD project defines two levels of tasks geared towards new contributors. "Deuces" are small tasks expected to take less than 2 hours. "Quickies" take around 2 days:
http://brlcad.org/wiki/Deuces
http://brlcad.org/wiki/Quickies
The project even provides a virtual machine disk image that has everything set up and ready to go.
You perhaps don't realize this, but a lot of people do not go by their first name.
Where I work, addresses were converted to firstname.m.lastname## and it has been a royal clusterfuck. There are hundreds of thousands of users, so there were even a ton of firstname.m.lastname conflicts (so they added numbers). It resulted in complete ambiguity with e-mails going to the wrong people all over the place and was made even worse by the assumption that their first name is always what people call themselves. Was Jim's address william.j.smith12 or william.j.smith13?
I think you'd be criminally liable to knowingly set up a new system that *automatically* creates ambiguity and confusion where there was none.
I believe the decision last year was that a student from any nation may apply, but they must be attending a university within the European Union.
Not really any less open than limiting the participation to full-time accredited university students. Unlike Google, their funding source isn't commercial, so it makes sense to try and keep it within their tax base. Moreover, I think explanation last year was something along the lines of there being an ESA mandate stating that more than 50% of their spending must stay within the EU.
As I see it, their money their rules. Nobody has to participate. It's great to see a large governmental organization stepping up to directly support open source regardless.
Search and ye shall find, lazy troll: http://sophia.estec.esa.int/socis2011/?q=node/16
I used to love Palm until they became the company that acquired, sat on, and ultimately squandered BeOS. Good riddance and hopefully the door smacks your ass on your way out.
At least now there's open source darling Haiku.
Didn't you know? Pretty people don't lie. Believe it. Because they're pretty.
Apparently, other geeks/nerds find this article worthwhile. They're idiots or ignorant at best. :)
As you note, posters feeling otherwise is completely subjective (as is my view) and serves no basis of demonstrating right or wrong. It's purely anecdotal. As for why I respond, this is just an entertaining discussion on a topic I live, work, and breathe. Of course, I'll keep engaging in the discussion I started as long as I find it interesting to do so. I do not, however, see it as an argument or debate where we're going to come to some glorious agreement.
Like I said, we don't have to agree. We clearly do not. If you're not interested in discussing other notable CAD news (or even the PTC article), then leaving it at this end would be fitting. Have a great day!
That is a little cool actually, at least from a technical perspective. Z-sorting in code sucks big time. But yeah, it also sucks requiring specific hardware, the absolute latest drivers just to run, and without any backwards or hardware compatibility support. For the cost, they should be giving out free back rubs.
No more newsworthy than it would be to announce that Linux runs on AMD64.
Don't be an ass. Linux on AMD64 was huge news, especially as it was years before Microsoft and helped cement AMD's instruction set as the standard.
How's that being an ass? It was huge news. It wouldn't be if it were a headline posted today. We'd be asking what took so long, what were they waiting for. Adopting it after all your competitors doesn't make for news. It makes for shaking a little "me too" rattle. Good for PTC, but good grief. I expect more from billion dollar companies, which is what makes open source development all that more interesting a topic.
This isn't news to you. It is interesting and newsworthy to me[snip]
I would think that goes without saying; of course I only speak for myself. Defensive much? Shill? Trolling? I'll bite. I was commenting on how I perceive it (frankly as a paid-for posting) given the article's lack of content. Everyone's entitled to an opinion and fortunately we don't even have to agree on that point.
I agree with him completely. If you're not interested in this article, why don't you read and comment in another thread, one which you find interesting and newsworthy, instead of trying to convince us that this one isn't so.
Great, more power to you. I'm not trying to convince you of anything, contrary to your claim, but just replying to a thread I started. If it bothers you that much, you're just as welcome to disagree with someone else's thread too (or post your own). ;)
As far as interesting and relevant CAD news goes, I still contend that there are plenty of better things to be discussing. Even the choice of "Creo" for a new product name is more newsworthy (and absurd ditching their Pro/E mark) or the fact that their stock has crashed nearly 25% this past quarter. Or GrabCAD's competition: http://www.zwsoft.com/en/about/press_center/press_releases/20120406/ZW3D-and-GrabCAD-Present-a-3D-CAD-Model-Challenge.html
Less defensiveness, more objectivity. It's a good thing.
Cheers!
Sean
Actually, I prefer big endian. Thanks.
Let's see. AMD, CAD, Pro/ENGINEER, GPU, wireframe rendering... Yup, pretty much spot-on geek nerd news. Or do you think the non-geek world would actually find this interesting?
Geek nerd topics, sure. Just not newsworthy. No more newsworthy than it would be to announce that Linux runs on AMD64. It's expectedbecause it's the smart thing to do. Pro/E is just behind the curve on this one. Most of the other CAD companies are already in bed with hardware optimizations. Still doesn't make it newsworthy though (did I miss a free Linux port or something? conversion to open source? those would be news!).
I never purported to speak for anyone else. My point was as stated -- that this isn't really geek nerd news. It's very much par for the course within the CAD industry. Hell, it's par for most big-industry fields these days, especially graphics-related ones.
The fact that Pro/E is jumping on a bandwagon says more about the wagon than the band. Understandably will be interesting to some people, but then so is the kid-got-shot-in-florida topic and it misses the target just as much.
Wow, talk about a blatant slashvertisement. As the summary states, it's not at all unusual for CAD/CAM software to ally with hardware so what exactly is the news for nerds here??
With more contributors working on improving BRL-CAD's usability and features, we'd have an open source alternative without the huge recurring price tag. Lots of ways to get involved are listed here: http://brlcad.org/wiki/Contributor_Quickies
You see what I did there.
Pinch me I must be dreaming!
Nah, you're just getting old. ;)
BRL-CAD is a great project with an extensive legacy that doesn't get nearly enough developer attention. With hundreds of staff years effort invested across tons of functionality, it's really the *only* open source CAD system viable for production use, yet it's still in need of devs to help improve the interface and usability.
You'd think the massive market size of the CAD/CAM industry (estimated around $8B annual) would help, but that really just attracts LOTS of users. Thousands a month. Many understandably get put off by the steep learning curve and UNIX-style design or cry for features implemented in their favorite commercial CAD system that took loads of manpower.
The project is crazy active with the dozen or so devs that already do contribute, but the open source developer community at large doesn't seem to know about the project. Some are probably put off by the size of BRL-CAD (1M+ loc), but that's actually rather tiny for a production CAD system. The project deficiencies are well known (usability, interface!), but takes lots time and effort to make things better. Takers?
Some of the best stuff isn't in the commit message but obscured in the commit text. One of the best resentment commits I've seen:
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/mged/mged.c?r1=31006&r2=31008&view=patch
Pure awesome.
You're an applied mathematics student, so look for applied math projects. That way, you're newbie skills will be best put to use leveraging what you already know. There'll still be plenty you'll have to learn along the way, so put what you know to good use. Instead of projects like boost, sage, or octave, look for projects that have heavy applied math requirements like BRL-CAD, Blender, CGAL, and many many others.
Pick a community that interests you. Download the source code, compile and run the software, find their bug list, start fixing bugs. Introduce yourself when you have something useful to contribute (not just vaporware) or if you get stuck and need help.
Plenty of math-specific projects at http://www.dmoz.org/Science/Math/Software/ too.
I, for one, welcome our new sushi overlords.
This gadget did quite a bit to define the decade as well.
These meters have been all around downtown Baltimore for a couple years now and while I agree that the round-trip to the ticket dispenser is annoying from an efficiency standpoint, it's still FAR better than coin meters if only for the sole reason that they take credit/debit cards. I don't keep change in my car (great way to get your car broken into in some parts). I haven't deliberately carried coins in my pockets for probably a decade.
The biggest problem I've had with the electronic meters is that you can't add time to an existing ticket. You have to either pay more in advance to 'make sure' you won't run out of time or you'll end up paying double for overlapping time. If I return back early and there's significant time remaining, I usually take the ticket back to the dispenser leaving it in the credit card slot or similar visible place so the next person can use it.
What do I really want? I'd like for people that touch my car while parallel parking to get an automatic citation. Let me decide whether to wave the fine or not. Hooking parking into the EZPass system would also be nice, so the parking spots know when I'm there, I'm automatically microbilled, and a ticket is no longer necessary.
Probably a very easy job.
http://despair.com/motivation.html
Pics or it didn't happen..
What?
It's not a big deal except to the PLplot devs as an arbitrary line being passed. Kudos to them for making ten thousand measured changes to their code, hope they make it to the next decimal place up. Probably not unlike the mild nod of appreciation you might feel when you hit 100,000.
It's a rather meaningless metric in general simply because there are massive differences in commit styles across projects and even within the same project. Even less meaningful than the meaningless lines-of-code metric. As an example, BRL-CAD's commits were almost universally 'huge' commits until it went open source. Then the more iterative 'chatter' commit style of most open source projects was adopted where they became much much smaller and considerably more frequent, communicating intent much better. Revision history that's actually useful! Even now, there are some devs that commit early, commit often, and others on the project that still have a tendency to commit big when left unchecked.
I'm certainly biased, but it's more than awesome in theory. The project has a lot of momentum and development going on not only towards addressing your concerns, but a lot of others as well. Most everything being worked on now is towards making the GUI much better.
That includes dropping Tk for the modeler (going to Qt now that it's LGPL). That includes implementing full BREP/NURBS support and multiple-representation geometry (no longer just unevaluated wireframes until render). That includes a fresh implementation of an OO geometry engine ala ACIS and Granite. That includes an extensible plug-in based application framework and a whole lot more.
BRL-CAD's main issues are 'cosmetic' problems that you don't even have to be a developer to help (vastly) improve. Docs, website, tools... The biggest problem (aside from needing more developers) is one of scope and expectations as CAD means a lot of different things to different people. Commercial CAD is major business with more than 2000 devs cranking features into the likes of CATIA, AutoCAD, Solidworks, NX, and Pro/E on a daily basis. BRL-CAD has two orders of magnitude less yet nearly the same expectations from users. The only way it's going to improve is through increasing development from the open source community at large to make things better, leverage the 500 staff-years invested, and push forward making great tools.