I've worked as a programmer for Autodesk for a few years. Autodesk has a number of very mature products, and a lot of very old code. Some of the projects have matured better than others and as a result there were some good lessons to be learned from those projects.
A couple of things I picked up while I was there:
- Anytime you touch a piece of code you should improve it. This will result in the software always improving over time, rather than degrading over time.
- Always write the simplest code possible to solve a problem. That is don't over-engineer a solution by designing/building unnecessary elaborate flexible object models for requirements that *might* come down the road.
- Assuming you have written the simplest code possible, and that you want to always *improve* the software... If you do get a requirement that the current code doesn't support w/o a kludge then immediately refactor it, but only as much as you need to solve the current problem.
All software still must meet strict products liability. That is, if your software causes users physical harm then the software developer is still liable. For example, if navigation software causes a boat owner to drive his boat onto a sandbar and someone is hurt or killed, the software make is still liable.
That said, you don't have to agree to the license. If you don't like the license, then pay more money for a piece of software that has a license that you agree with. As with all contract negotiations, you have to pay more if you expect the other party to accept more responsibility. If you look around, you will find plenty of software that does accept more liability. It is usually sold to the military, airlines, etc, but it does exist. If you want it in mainstream accounting software you will have to graduate from quickbooks, and negotiate directly with the company selling the software.
That's just not true. I *occasionally* dabble with Gentoo, and it took me 10 minutes and a tv show to get enlightenment dr17 up and running several months ago. I did nothing special, didn't translate the bible, or jump through any other hoops. It just worked by accepting ~x86.
--Craig
ROFL... Someone should let the FCC know that a GPS doesn't work indoors.
Re:Cain and VoIP Sniffing
on
VoIP Security
·
· Score: 1
You can get both sides of the conversation by putting two NICs in your winxp box and creating a bridge.
1. Plug a cable into your hub (not necessary) or ca ble/DSL modem and the other end into one of your laptop's NICs.
2. Plug a cable into the VOIP modem and the other end into the other NIC.
3. Network Connections and create a bridge that uses both NICs. This will run all packets to/from the VOIP box across the bridge.
4. Fire up CAIN and sniff the bridge
The TIGER® Trademark The Census Bureau has trademarks on a number of our TIGER-related product names*. The purpose of trademarking these terms is so that customers buying products with those names can be confident in identifying the origin (the Census Bureau in this case) of the products (data) being sold. That shouldn't dissuade anyone from creating products using the TIGER/Line data or even citing our original products as the source of all or part of their product. In fact, many of our products are resold or redistributed by others. Vendors take the basic product, add value to it (snazzier interface, more data, etc.) and resell it. Sometimes they just resell exact copies of the data. That's all perfectly legal and we are happy to see the data redistributed and get wider usage.
The existence of the trademark means, basically, that you shouldn't name your product with one of our trademarked terms, i.e., either calling your product "TIGER", "TIGER/Line", etc. or use a Census Bureau trademark within the name of the product or service. You may refer to the Census trademark in describing the Bureau's component of your product or service. For example, you could say in a product description or advertisement something like this: "Acme Map Data, based on Census Bureau TIGER/Line® files". Ideally, we would also appreciate a statement to the effect that the referenced trademark is a registered trademark of the U.S. Census Bureau. The above discussion is not intended to be a legal brief on trademark law but just a quick summary of the general trademark issues relating to our products.
The Geography Division of the U.S. Census Bureau will consent to license one of its trademarks only under the following conditions. The potential licensee must be a government agency, either domestic or foreign, with whom we have an established working arrangement for common products or cooperative programs. Such an authority is not granted automatically by the preexisting working arrangements but must be requested in writing of the Geography Division. The trademark or trademarks that would be eligible for such licensing would be those directly related to these program activities. The license would last only as long as the working arrangements are in effect. This determination would be the sole purview of the Geography Division. The licensee would not have the authority to "sublicense" to another organization the use of any Geography Division trademark that would be part of the agreement.
In 2000, the State of Maine purchased a laptop computer for every student. They tracked the students grades, and the scores went up significantly.
Perhaps the problem is with computers that are only partially integrated into a students life instead of a computer that actually belongs to the students. Using the schools, or your parents computer is not the same thing as using/owning your own computer.
Apple has a free COM API available to developers on their website. It is feasable that someone could develop a Windows XP Embedded based player using this API. Just because the market hasn't embraced this option doesn't mean that Apple is at fault.
I have the sleeve and the cargo bag. The strap is adjustable on my cargo bag. It is one of those bags that "just works". For example, when you have the bag over your shoulder, you will notice that the zipper on the outer pouch is at a perfect angle to get in and out of (like a pocket on a pair of trousers). The bags all look great, protect great, have comfortable straps, and work outstanding.
We do need such a project, but no matter how you evaluate it, it would require a tremendous amount of human editing. Even if one were to begin with the TIGER data, and then have people upload their GPS data where data were missing it would still be useless for navigation. NavTech's data is more than just a bunch of lines that get put on a page, each road is a vector that is connected to other vectors via nodes. This is called topology. In addition, because they are vectors they have direction. This basic information is how a route is calcuated. Above and beyond that, each vector has attributes so that speed, road quality, etc can be taken into account when calculating routes.
The other important thing is called vertical integration. If a road, is for example split with one lane going northbound, and the other southbound there are two vectors. Each vector can be capture d with a GPS to +/- 10m. With that amount of wiggle room, it is entirely possible that the raw arcs would overlap at some point when put into a common spatial database. The arcs need to be corrected so that they do not overlap (as do streams, points of interest, lake boundaries, etc). The problem gets even more difficult when you start overlaying the vector data on top of sattelite imagery, digital orthophotos, etc. While the latter is probably not relevent to a basic vector road database, it is important when making maps, or calculating routes. Spatial data from NavTech (TeleAtlas, or others) is far more than just raw GPS data, it is vector data with topology and attributes, as well as some attention to vertical integration. Oh... and NavTech doesn't sell maps.
Slashdot Mirror
Well, if you are guessing, you know you are going to get the requirements wrong anyway, right? :-)
I've worked as a programmer for Autodesk for a few years. Autodesk has a number of very mature products, and a lot of very old code. Some of the projects have matured better than others and as a result there were some good lessons to be learned from those projects. A couple of things I picked up while I was there: - Anytime you touch a piece of code you should improve it. This will result in the software always improving over time, rather than degrading over time. - Always write the simplest code possible to solve a problem. That is don't over-engineer a solution by designing/building unnecessary elaborate flexible object models for requirements that *might* come down the road. - Assuming you have written the simplest code possible, and that you want to always *improve* the software... If you do get a requirement that the current code doesn't support w/o a kludge then immediately refactor it, but only as much as you need to solve the current problem.
All software still must meet strict products liability. That is, if your software causes users physical harm then the software developer is still liable. For example, if navigation software causes a boat owner to drive his boat onto a sandbar and someone is hurt or killed, the software make is still liable.
That said, you don't have to agree to the license. If you don't like the license, then pay more money for a piece of software that has a license that you agree with. As with all contract negotiations, you have to pay more if you expect the other party to accept more responsibility. If you look around, you will find plenty of software that does accept more liability. It is usually sold to the military, airlines, etc, but it does exist. If you want it in mainstream accounting software you will have to graduate from quickbooks, and negotiate directly with the company selling the software.
ok... I'll bite, and spell it out. The point is, this isn't news. DR17 has been widely available for months.
That's just not true. I *occasionally* dabble with Gentoo, and it took me 10 minutes and a tv show to get enlightenment dr17 up and running several months ago. I did nothing special, didn't translate the bible, or jump through any other hoops. It just worked by accepting ~x86. --Craig
I'm not a Gentoo apologist or advocate, but it has had DR17 available as an ebuild (like the rest of the distribution) for months.
ROFL... Someone should let the FCC know that a GPS doesn't work indoors.
You can get both sides of the conversation by putting two NICs in your winxp box and creating a bridge. 1. Plug a cable into your hub (not necessary) or ca ble/DSL modem and the other end into one of your laptop's NICs. 2. Plug a cable into the VOIP modem and the other end into the other NIC. 3. Network Connections and create a bridge that uses both NICs. This will run all packets to/from the VOIP box across the bridge. 4. Fire up CAIN and sniff the bridge
Interesting, the term TIGER is also trademarked by the US Census Bureau. http://www.census.gov/geo/www/tiger/overview.html
The TIGER® Trademark
The Census Bureau has trademarks on a number of our TIGER-related product names*. The purpose of trademarking these terms is so that customers buying products with those names can be confident in identifying the origin (the Census Bureau in this case) of the products (data) being sold. That shouldn't dissuade anyone from creating products using the TIGER/Line data or even citing our original products as the source of all or part of their product. In fact, many of our products are resold or redistributed by others. Vendors take the basic product, add value to it (snazzier interface, more data, etc.) and resell it. Sometimes they just resell exact copies of the data. That's all perfectly legal and we are happy to see the data redistributed and get wider usage.
The existence of the trademark means, basically, that you shouldn't name your product with one of our trademarked terms, i.e., either calling your product "TIGER", "TIGER/Line", etc. or use a Census Bureau trademark within the name of the product or service. You may refer to the Census trademark in describing the Bureau's component of your product or service. For example, you could say in a product description or advertisement something like this: "Acme Map Data, based on Census Bureau TIGER/Line® files". Ideally, we would also appreciate a statement to the effect that the referenced trademark is a registered trademark of the U.S. Census Bureau. The above discussion is not intended to be a legal brief on trademark law but just a quick summary of the general trademark issues relating to our products.
The Geography Division of the U.S. Census Bureau will consent to license one of its trademarks only under the following conditions. The potential licensee must be a government agency, either domestic or foreign, with whom we have an established working arrangement for common products or cooperative programs. Such an authority is not granted automatically by the preexisting working arrangements but must be requested in writing of the Geography Division. The trademark or trademarks that would be eligible for such licensing would be those directly related to these program activities. The license would last only as long as the working arrangements are in effect. This determination would be the sole purview of the Geography Division. The licensee would not have the authority to "sublicense" to another organization the use of any Geography Division trademark that would be part of the agreement.
In 2000, the State of Maine purchased a laptop computer for every student. They tracked the students grades, and the scores went up significantly.
Perhaps the problem is with computers that are only partially integrated into a students life instead of a computer that actually belongs to the students. Using the schools, or your parents computer is not the same thing as using/owning your own computer.
Apple has a free COM API available to developers on their website. It is feasable that someone could develop a Windows XP Embedded based player using this API. Just because the market hasn't embraced this option doesn't mean that Apple is at fault.
Yeah... it is definately in your best interest to not neglect that.
I have the sleeve and the cargo bag. The strap is adjustable on my cargo bag. It is one of those bags that "just works". For example, when you have the bag over your shoulder, you will notice that the zipper on the outer pouch is at a perfect angle to get in and out of (like a pocket on a pair of trousers). The bags all look great, protect great, have comfortable straps, and work outstanding.
We do need such a project, but no matter how you evaluate it, it would require a tremendous amount of human editing. Even if one were to begin with the TIGER data, and then have people upload their GPS data where data were missing it would still be useless for navigation. NavTech's data is more than just a bunch of lines that get put on a page, each road is a vector that is connected to other vectors via nodes. This is called topology. In addition, because they are vectors they have direction. This basic information is how a route is calcuated. Above and beyond that, each vector has attributes so that speed, road quality, etc can be taken into account when calculating routes. The other important thing is called vertical integration. If a road, is for example split with one lane going northbound, and the other southbound there are two vectors. Each vector can be capture d with a GPS to +/- 10m. With that amount of wiggle room, it is entirely possible that the raw arcs would overlap at some point when put into a common spatial database. The arcs need to be corrected so that they do not overlap (as do streams, points of interest, lake boundaries, etc). The problem gets even more difficult when you start overlaying the vector data on top of sattelite imagery, digital orthophotos, etc. While the latter is probably not relevent to a basic vector road database, it is important when making maps, or calculating routes. Spatial data from NavTech (TeleAtlas, or others) is far more than just raw GPS data, it is vector data with topology and attributes, as well as some attention to vertical integration. Oh... and NavTech doesn't sell maps.