It's a programming error in that Programmers misunderstood the specifications and built a program that didn't understand metric, while the rest of the system was written in metric.
It's also a QA error that allowed the program to be used at all, considering that it wasn't working when the spacecraft was launched. It was only after the launch that the program was finally tested.
Even now, with highly abstract languages, we still have computer languages that only trained users can understand. In my company, we are always trying to make applications where the business logic can be changed by business users, so that, say, the finance guy can log into the system and change the process for paying bills. This is because as highly regulated/complex industries move more processes to computers, they need business-person control over their systems. It's very easy for a bank to have a business analyst change an online form because a regulation changed; it's harder to call up the program vendor and rewrite the program. The problem is that there needs to be an easy-to-use language for describing the new form. Currently many such languages are business domain only; expect them to grow and become more powerful; soon a business person will be able to put together an entire web application from "scratch" with a good framework.
The bitkeeper distributed repository concept basically creates a tree of repositories, with developers working off of leaves of the tree. Developers can push changes up the tree to the parent repository; other developers using the same parent can then pull down the changes. It's essentially the same as branching in any other SCCS.
However, there is additional flexibility in Bitkeeper where you can push bundles of changes in other directions; such as horizontally across leaves or to other arbitrary locations in the tree. You can do this by hand with branches, however it's harder. I'm disappointed with Bitkeeper's free license; it seemed like such a good tool but now I won't waste any more of my time evaluating it. Maybe if my employer decides to switch away from Rational ClearCase, I'll try to get them to look at BitKeeper.
You sound like you're from the camp that believes Linux NEEDS to be user friendly. To me, the endless configurability is a tradeoff for the power and stability you get, among other things. And let's not forget the reason many of us don't use MS in the first place -- everything DOESN'T "just work" all the time.. and when it doesnt you often have no recourse. With an open system I *always* have the power to fix the problem, and it's usually not hard.
Don't forget that your ability to configure/fix the system by hand does not mutually exclude my ability to use a gui for some or all system administration. Most programs' config files are just a set of stored data; it's usually easy to slap a gui on it. Some programs have more complicated config files that resemble code; these are harder to automate. But you can't tell me that the Samba SWAT tool makes it impossible for me to edit my SMB.CONF file by hand.
The thing that's important is that the GUI should be available for people who are just starting out. I used to use a gui for some config files, and now I edit the source by hand because it's often faster. But the Mandrake system setup tool or the KDE control center sure make it easy to change a whole pile of settings all at once. So even if they aren't NEEDED, they are still an added value. And that value is more important when your users know less.
Finally, about your comment re: appliances. Yes, embedded or appliance-like devices need to be totally user-friendly etc. But that doesn't mean that there can't be "advanced" options or true configurability. User-friendliness is really about programmer attention to detail, and understanding your target audience. It's not really about whether you're making a cell-phone, a PVR, or a network administration tool.
My point wasn't to disagree with your points, just to illustrate that Integer and Boolean objects can be useful. I'll admit that Java doesn't really use these to the fullest extent that they can; this was a conscious decision made for performance reasons. You don't do math with an Integer object because it's too much overhead. However, you can store an int in an Integer object, which is handy if you want to store primitive types in collections that only store Objects.
Yes the "pure OO" paradigm falls apart a little here in the Java world. But it's intentional, because in 1995 the extra overhead of doing all the conversion between objects and primitives wasn't worth it. It's just an example of an engineering tradeoff between "correctness" (from an academic perspective) and "efficiency" (from a performance perspective, and possibly other perspectives).
My main gripe with your original comment was that you are picking on the primitive type wrappers, when they do not really illustrate your point as well as some other Java flaws, like the weird array objects. Now THOSE break up the paradigm; if I make an array of ints (primitive types), it (the array itself) suddenly is also an object... even experienced java programmers find it confusing. I'm not really sure how it could be cleaned up and made nicer though.
I'd have to disagree about your description of the separation between really good programmers and average/bad programmers.
I'd say that a programmer's primary job is software development, not algorithm design. Some people can write really good algorithms, but can not assemble an application. Some people aren't great at inventing new sorting methods or queue theories, but they can write code that is easy to debug, fix and maintain. That's what programming is about: developing a cost-effective solution in a limited time, while keeping future maintenance costs down. Algorithm design is Computer Science, and is not practiced by 99% of programmers.
Well, in Java, and int is 4 bytes. An Integer is an object wrapped around an int, as you put it. This object is useful for many things. Math isn't really one of them. For plain math, use plain ints.
C#, however, has automatic wrapping of primitive types with objects. This is supposedly done on an as-needed basis. I've never tried it, but I'd assume that the wrapping happens only when it's required, otherwise the VM will preserve the basic types for performance reasons.
As to reasons for why there is a Boolean object, it's really just a question of convenience. The Boolean class contains methods for manipulating booleans, like making Strings out of them, or making new booleans from strings. What's the harm in extending this helper class to also represent a boolean value? It's still an object. Maybe you never need to subclass it? That doesn't mean it shouldn't be an object.
I agree that a distinction has to be made between OOD and algorithms and basic programming fundamentals. I would say that a good way to learn software development would be as follows:
First, learn basics like arrays, data types, operators, functions, pointers, structures. Learn one or two languages.
Second, learn about algorithms and data structures. Learn about sorting and merging lists, learn about heaps, stacks, trees, etc. Learn about algorithm complexity. Make sure to emphasize modularization; that is, if you are learning about trees, make sure the code you write to manipulate the tree is cohesive.
Learn about objects and OOA/OOD. Learn how data structures lead to classes and objects. Learn about data hiding, iheritence and polymorphism.
Learn design patterns. Show how solutions to certain families of problems can be re-used. Show how algorithms can be made more generic by using polymorphism.
Somewhere along the line you should learn more about algorithm complexity, various programing paradigms (like functional programing), low-level languages like assembly, operating system and networking concepts, and any advanced topics like databases and distributed programming and real-time programming. But these are all extras. I still think that a programmer needs to learn what a loop is before he should be concerned about what an object is.
You won't likely be able to compile the linux kernel because it uses GCC specific extensions. Also, the kernel does many tricks to increase performance, and some of these tricks depend on particular compilers. Also, only a few versions of the compilers are supported by each given kernel. Even new GCC compilers often break the kernel.
Since TCP has flow control and UDP doesn't, you can actually cause your network connection to saturate with a couple UDP connections and then you won't be able to make any TCP connections. UDP doesn't play very well with others. I believe there is a new protocol in the works that is like UDP but plays better with TCP.
Also, some TCP stacks are implemented in a way that if you start TCP connections one-after-another, after you let the latest one peak in its bandwidth usage, the third or higher TCP connections will not be able to grab any bandwidth. This is appearantly a problem with windows 9x and some ADSL connections. The TCP flow control lets the first two connections split the bandwidth between each other, but the third connection can't ramp up enough bandwidth and just chokes. Appearantly this problem is mitigated by using different types of network connections or different operating systems.
I'm sure that the one thing that will make those disadvantaged children break out of their ruts and become the model citizens we want them to be is for them to be well organized with their shiny new handsprings.
Come on, as if a PDA is what a school-child (in any socio-economic condition) needs. What ever happend to reading books? and doing math by hand? I was in a stationery store the other day and noticed that the math sets (compass, dividers, rulers, triangles, etc) now include a calculator. Sheesh! As if people weren't already bad enough at math!
I'm all for having a computer in the classroom. Heck, I think learning to program a computer is a useful activity because it encourages problem solving and creativity. However, teaching students to use a Handspring seems a little pointless. Students need to learn concepts, not tools. They need to learn English and grammar, not how to run the spell-checker.
There is one exception to my anti-Handspring stance. If the school had some learning activity that could only realistically be done on a set of Handsprings, and that wasn't technology related, then I'd agree that having a class set, that must be signed-in/out for each class, might be a good idea. Just like how my school had microscopes, not so that we could learn optics, but so that we could learn about cells, it would be acceptable for the school to use computing devices (of any nature) to achieve some other goal. However, if it's just data collection, I'd say it's not really worth it.
There needs to be a focus on learning the principles. For example, when teaching a student about navigation and maps and orienteering, don't give them a GPS. Give them a compass and teach them how to pace out a path. When teaching students about graphing weather trends, make them graph it on paper. They won't have so much data that they need a computer to do it. If they WANT to use a computer, maybe it's ok if they learn it on their own, but don't make it the objective.
Amen! I had to write a software engineering exam where most of the exam was UML diagrams. You can imagine how messy these diagrams became after mistakes were discovered and I forgot to add stuff in the "first time around". I personally hate diagramming on paper since I can't easily erase stuff and move it around.
That said, everyone in an exam situation is under the same circumstances, so I don't think that pencil-paper exams are unfair.
Re:Available NOW at Gap....
on
DRM Helmet
·
· Score: 1
Remember that George Lucas doesn't want AotC appearing in any theatre that doesn't meet his "approval". That's why AotC had to open on fewer screens, because there weren't as many. Granted, if Spidey wasn't ALSO playing there might be more screens for star wars, but I doubt it'd be THAT significant... most multiplexes don't want to show just ONE movie.
I detect a troll here. Sorry, but the article you linked to does not support the statement that Java was created to allow pedophiles to find pictures of little girls on the 'net.
Besides, the problems of a creator of a technology do not make the technology good or evil. Sheesh.
I'd agree that most games are not speech. But come on, just because they AREN'T doesn't mean they can't be. Just the other day I was in a game store and I found a game that tells Bible stories and stuff. It's some kind of first-person-shooter or something, where the character has to make moral decisions and fight the good fight against the evil, fallen angels. You can't tell me that THAT game is not speech.
I would say that it's pretty darn cold on Mars, so the body might not decompose, but probably any organisms would be frozen. So all we have to do is not thaw out any bodies of sick astronauts.
I've worked with a school board that decided to roll their own for every single school in the county. Each school theoretically had the same setup, but what really happened was that for each phase of the project the machines changed, both in terms of their hardware and their software. This became a huge headache for replacement of the machine parts.
For example, the vendor ran out of a certain video card and so provided us with the model one-up as an RMA when one of the video cards died. This means the user gets an improved card, however what it really means is a driver headache (the ghost image for all those PCs has to be upgraded to support the new vid card as well as the old one) and a possibly non-working configuration since the new card hasn't been tested.
Then, you run into the asset management of keeping track of the different phases of the project. This was a large project, so there were lots of different configurations to keep track of. If you are planning on keeping the number of distinct phases small, you may be able to make it work. However, keep in mind that when a 2 year old computer fails, warranty or no warranty you may have trouble replacing a component with exactly the same one. Even a hard drive can cause a headache, if the replacement is larger than some BIOS or OS limitation and your ghost image fails on it.
The keys to the success of this project are as follows:
1. Always have spare parts on hand, for each phase. I'd say you'd ideally have at least one spare box, maybe two depending on the size of the phase, and maybe a few hard drives and cdroms. As you find certain parts more problematic than others, get more spares in future phases.
2. Asset management (hardware, software, firmware, drivers, etc) is crucial. You must know what's in each box; sometimes even a BIOS "upgrade" will screw you up.
3. Using something like Ghost to transfer operating systems is great until users start storing data on local disks. You will need to make sure that they at least use a separate partition, or even better a network storage.
If you keep the number of phases small, it should ideally be no problem. In theory there are only a few different PCs to fix, so once you can fix one, you can fix them all. But once you let non-standard software and hardware creep into the different boxes the theory breaks down and support becomes a nightmare.
I believe that Unisys's patent on GIF actually applies to the compression algorithm. And incidentally, it's not USING gifs that's illegal, it's creating them. Also, I think the patent expired.
The difference between Apple bundling everything with the Mac and MS bundling with the OS is that Apple is the only Mac vendor, where as MS is not a vendor. So it's more like if Compaq bundled everything with the computer. Compaq would do that to make their platform look better than any other OEM's platform. MS puts tons of stuff into the OS not to make the OS look better... after all, the OS has a monopoly, so people pretty much HAVE to buy it. No, they put that stuff in the OS so that other companies can't make the same stuff. Putting Windows Media Player into Windows doesn't make Windows a better choice than Linux. It just makes it harder for Real to compete.
Nothing stops OEMs from taking the 'lite' version of windows and loading it down with tons of stuff... they always did that anyway.
It's really a case of using the right tool for the right job. After all, some data is not well expressed in a tree, while some is not well expressed in a relational database. Does this mean it's more right to use one or the other? Too often I see people using XML just because it's new, and not because it actually makes the data easier to work with.
As for the Object hierarchy in Java, it really doesn't limit what you can do with the objects and classes... you can still have a class with no data and only static methods, which is just like a function in C. The nice thing about the automatic Object superclass is that it makes generic, heterogenous containers really easy to use.
Slashdot Mirror
It's a programming error in that Programmers misunderstood the specifications and built a program that didn't understand metric, while the rest of the system was written in metric.
It's also a QA error that allowed the program to be used at all, considering that it wasn't working when the spacecraft was launched. It was only after the launch that the program was finally tested.
Even now, with highly abstract languages, we still have computer languages that only trained users can understand. In my company, we are always trying to make applications where the business logic can be changed by business users, so that, say, the finance guy can log into the system and change the process for paying bills. This is because as highly regulated/complex industries move more processes to computers, they need business-person control over their systems. It's very easy for a bank to have a business analyst change an online form because a regulation changed; it's harder to call up the program vendor and rewrite the program. The problem is that there needs to be an easy-to-use language for describing the new form. Currently many such languages are business domain only; expect them to grow and become more powerful; soon a business person will be able to put together an entire web application from "scratch" with a good framework.
The bitkeeper distributed repository concept basically creates a tree of repositories, with developers working off of leaves of the tree. Developers can push changes up the tree to the parent repository; other developers using the same parent can then pull down the changes. It's essentially the same as branching in any other SCCS.
However, there is additional flexibility in Bitkeeper where you can push bundles of changes in other directions; such as horizontally across leaves or to other arbitrary locations in the tree. You can do this by hand with branches, however it's harder. I'm disappointed with Bitkeeper's free license; it seemed like such a good tool but now I won't waste any more of my time evaluating it. Maybe if my employer decides to switch away from Rational ClearCase, I'll try to get them to look at BitKeeper.
You sound like you're from the camp that believes Linux NEEDS to be user friendly. To me, the endless configurability is a tradeoff for the power and stability you get, among other things. And let's not forget the reason many of us don't use MS in the first place -- everything DOESN'T "just work" all the time .. and when it doesnt you often have no recourse. With an open system I *always* have the power to fix the problem, and it's usually not hard.
Don't forget that your ability to configure/fix the system by hand does not mutually exclude my ability to use a gui for some or all system administration. Most programs' config files are just a set of stored data; it's usually easy to slap a gui on it. Some programs have more complicated config files that resemble code; these are harder to automate. But you can't tell me that the Samba SWAT tool makes it impossible for me to edit my SMB.CONF file by hand.
The thing that's important is that the GUI should be available for people who are just starting out. I used to use a gui for some config files, and now I edit the source by hand because it's often faster. But the Mandrake system setup tool or the KDE control center sure make it easy to change a whole pile of settings all at once. So even if they aren't NEEDED, they are still an added value. And that value is more important when your users know less.
Finally, about your comment re: appliances. Yes, embedded or appliance-like devices need to be totally user-friendly etc. But that doesn't mean that there can't be "advanced" options or true configurability. User-friendliness is really about programmer attention to detail, and understanding your target audience. It's not really about whether you're making a cell-phone, a PVR, or a network administration tool.
My point wasn't to disagree with your points, just to illustrate that Integer and Boolean objects can be useful. I'll admit that Java doesn't really use these to the fullest extent that they can; this was a conscious decision made for performance reasons. You don't do math with an Integer object because it's too much overhead. However, you can store an int in an Integer object, which is handy if you want to store primitive types in collections that only store Objects.
Yes the "pure OO" paradigm falls apart a little here in the Java world. But it's intentional, because in 1995 the extra overhead of doing all the conversion between objects and primitives wasn't worth it. It's just an example of an engineering tradeoff between "correctness" (from an academic perspective) and "efficiency" (from a performance perspective, and possibly other perspectives).
My main gripe with your original comment was that you are picking on the primitive type wrappers, when they do not really illustrate your point as well as some other Java flaws, like the weird array objects. Now THOSE break up the paradigm; if I make an array of ints (primitive types), it (the array itself) suddenly is also an object... even experienced java programmers find it confusing. I'm not really sure how it could be cleaned up and made nicer though.
I'd have to disagree about your description of the separation between really good programmers and average/bad programmers.
I'd say that a programmer's primary job is software development, not algorithm design. Some people can write really good algorithms, but can not assemble an application. Some people aren't great at inventing new sorting methods or queue theories, but they can write code that is easy to debug, fix and maintain. That's what programming is about: developing a cost-effective solution in a limited time, while keeping future maintenance costs down. Algorithm design is Computer Science, and is not practiced by 99% of programmers.
Well, in Java, and int is 4 bytes. An Integer is an object wrapped around an int, as you put it. This object is useful for many things. Math isn't really one of them. For plain math, use plain ints.
C#, however, has automatic wrapping of primitive types with objects. This is supposedly done on an as-needed basis. I've never tried it, but I'd assume that the wrapping happens only when it's required, otherwise the VM will preserve the basic types for performance reasons.
As to reasons for why there is a Boolean object, it's really just a question of convenience. The Boolean class contains methods for manipulating booleans, like making Strings out of them, or making new booleans from strings. What's the harm in extending this helper class to also represent a boolean value? It's still an object. Maybe you never need to subclass it? That doesn't mean it shouldn't be an object.
Somewhere along the line you should learn more about algorithm complexity, various programing paradigms (like functional programing), low-level languages like assembly, operating system and networking concepts, and any advanced topics like databases and distributed programming and real-time programming. But these are all extras. I still think that a programmer needs to learn what a loop is before he should be concerned about what an object is.
I believe it's Gigawatts, since most North Americans mis-pronounce the Giga prefix as "gigga".
You won't likely be able to compile the linux kernel because it uses GCC specific extensions. Also, the kernel does many tricks to increase performance, and some of these tricks depend on particular compilers. Also, only a few versions of the compilers are supported by each given kernel. Even new GCC compilers often break the kernel.
Since TCP has flow control and UDP doesn't, you can actually cause your network connection to saturate with a couple UDP connections and then you won't be able to make any TCP connections. UDP doesn't play very well with others. I believe there is a new protocol in the works that is like UDP but plays better with TCP.
Also, some TCP stacks are implemented in a way that if you start TCP connections one-after-another, after you let the latest one peak in its bandwidth usage, the third or higher TCP connections will not be able to grab any bandwidth. This is appearantly a problem with windows 9x and some ADSL connections. The TCP flow control lets the first two connections split the bandwidth between each other, but the third connection can't ramp up enough bandwidth and just chokes. Appearantly this problem is mitigated by using different types of network connections or different operating systems.
I'm sure that the one thing that will make those disadvantaged children break out of their ruts and become the model citizens we want them to be is for them to be well organized with their shiny new handsprings.
Come on, as if a PDA is what a school-child (in any socio-economic condition) needs. What ever happend to reading books? and doing math by hand? I was in a stationery store the other day and noticed that the math sets (compass, dividers, rulers, triangles, etc) now include a calculator. Sheesh! As if people weren't already bad enough at math!
I'm all for having a computer in the classroom. Heck, I think learning to program a computer is a useful activity because it encourages problem solving and creativity. However, teaching students to use a Handspring seems a little pointless. Students need to learn concepts, not tools. They need to learn English and grammar, not how to run the spell-checker.
There is one exception to my anti-Handspring stance. If the school had some learning activity that could only realistically be done on a set of Handsprings, and that wasn't technology related, then I'd agree that having a class set, that must be signed-in/out for each class, might be a good idea. Just like how my school had microscopes, not so that we could learn optics, but so that we could learn about cells, it would be acceptable for the school to use computing devices (of any nature) to achieve some other goal. However, if it's just data collection, I'd say it's not really worth it.
There needs to be a focus on learning the principles. For example, when teaching a student about navigation and maps and orienteering, don't give them a GPS. Give them a compass and teach them how to pace out a path. When teaching students about graphing weather trends, make them graph it on paper. They won't have so much data that they need a computer to do it. If they WANT to use a computer, maybe it's ok if they learn it on their own, but don't make it the objective.
Computers are a tool; a means, not an end.
It happened to Coca-Cola. They didn't trademark their name properly, which is why Pepsi can make "Pepsi-Cola" and cola is now a household word.
Amen! I had to write a software engineering exam where most of the exam was UML diagrams. You can imagine how messy these diagrams became after mistakes were discovered and I forgot to add stuff in the "first time around". I personally hate diagramming on paper since I can't easily erase stuff and move it around.
That said, everyone in an exam situation is under the same circumstances, so I don't think that pencil-paper exams are unfair.
> (110 volts. BZZZT!)
:)
Remember, it's not the volts, it's the AMPS
Remember that George Lucas doesn't want AotC appearing in any theatre that doesn't meet his "approval". That's why AotC had to open on fewer screens, because there weren't as many. Granted, if Spidey wasn't ALSO playing there might be more screens for star wars, but I doubt it'd be THAT significant... most multiplexes don't want to show just ONE movie.
I detect a troll here. Sorry, but the article you linked to does not support the statement that Java was created to allow pedophiles to find pictures of little girls on the 'net.
Besides, the problems of a creator of a technology do not make the technology good or evil. Sheesh.
I'd agree that most games are not speech. But come on, just because they AREN'T doesn't mean they can't be. Just the other day I was in a game store and I found a game that tells Bible stories and stuff. It's some kind of first-person-shooter or something, where the character has to make moral decisions and fight the good fight against the evil, fallen angels. You can't tell me that THAT game is not speech.
I would say that it's pretty darn cold on Mars, so the body might not decompose, but probably any organisms would be frozen. So all we have to do is not thaw out any bodies of sick astronauts.
A transplanted organism with no 'predators' would be a bad thing. Just look at what happened to Australia after Bart brought his frog there.
I've worked with a school board that decided to roll their own for every single school in the county. Each school theoretically had the same setup, but what really happened was that for each phase of the project the machines changed, both in terms of their hardware and their software. This became a huge headache for replacement of the machine parts.
For example, the vendor ran out of a certain video card and so provided us with the model one-up as an RMA when one of the video cards died. This means the user gets an improved card, however what it really means is a driver headache (the ghost image for all those PCs has to be upgraded to support the new vid card as well as the old one) and a possibly non-working configuration since the new card hasn't been tested.
Then, you run into the asset management of keeping track of the different phases of the project. This was a large project, so there were lots of different configurations to keep track of. If you are planning on keeping the number of distinct phases small, you may be able to make it work. However, keep in mind that when a 2 year old computer fails, warranty or no warranty you may have trouble replacing a component with exactly the same one. Even a hard drive can cause a headache, if the replacement is larger than some BIOS or OS limitation and your ghost image fails on it.
The keys to the success of this project are as follows:
1. Always have spare parts on hand, for each phase. I'd say you'd ideally have at least one spare box, maybe two depending on the size of the phase, and maybe a few hard drives and cdroms. As you find certain parts more problematic than others, get more spares in future phases.
2. Asset management (hardware, software, firmware, drivers, etc) is crucial. You must know what's in each box; sometimes even a BIOS "upgrade" will screw you up.
3. Using something like Ghost to transfer operating systems is great until users start storing data on local disks. You will need to make sure that they at least use a separate partition, or even better a network storage.
If you keep the number of phases small, it should ideally be no problem. In theory there are only a few different PCs to fix, so once you can fix one, you can fix them all. But once you let non-standard software and hardware creep into the different boxes the theory breaks down and support becomes a nightmare.
Mark
I believe that Unisys's patent on GIF actually applies to the compression algorithm. And incidentally, it's not USING gifs that's illegal, it's creating them. Also, I think the patent expired.
The difference between Apple bundling everything with the Mac and MS bundling with the OS is that Apple is the only Mac vendor, where as MS is not a vendor. So it's more like if Compaq bundled everything with the computer. Compaq would do that to make their platform look better than any other OEM's platform. MS puts tons of stuff into the OS not to make the OS look better... after all, the OS has a monopoly, so people pretty much HAVE to buy it. No, they put that stuff in the OS so that other companies can't make the same stuff. Putting Windows Media Player into Windows doesn't make Windows a better choice than Linux. It just makes it harder for Real to compete.
Nothing stops OEMs from taking the 'lite' version of windows and loading it down with tons of stuff... they always did that anyway.
It's really a case of using the right tool for the right job. After all, some data is not well expressed in a tree, while some is not well expressed in a relational database. Does this mean it's more right to use one or the other? Too often I see people using XML just because it's new, and not because it actually makes the data easier to work with.
As for the Object hierarchy in Java, it really doesn't limit what you can do with the objects and classes... you can still have a class with no data and only static methods, which is just like a function in C. The nice thing about the automatic Object superclass is that it makes generic, heterogenous containers really easy to use.
It's like the Model T Ford. You can have it in any colour you like, as long as it's black. That's what Raskin wants to see.