The better question is how to keep people from forging the documents on which the "RealID" is based? The article does not say that authorities were busting rings of people forging state-issued drivers' licenses (although I know that happens as well), the article talks about forging birth certificates and social security cards.
So, what is to stop people from applying for a "RealID" based on forged credentials, even supposing the ID itself were unforgable? Given that someone else has an ID in your name, how do you prove who you are?
So, even if this is a problem worth solving, it looks like overhauling birth (or naturalization) certificates and social security cards is a better approach. But what do you do when someone loses their birth certificate? What do you do when someone needs more copies of their birth certificate? (There are several processes which require sending copies of birth certificates to various folks). These are harder questions than DHS likes to admit.
This is a question which comes up from time to time on Slashdot. I think the best approach is to pick an existing Open Source project and add a feature to it. That way students have to deal with an existing structure, existing policies, coding standards, etc., none of which are likely to be perfect, much as they would in the real world. Additionally, by focusing on a (non-trivial) feature, there is greater likelihood of actually completing the job in the time allotted. It gives the students a public chunk of code and a public acknowledgment they can point to. Lastly, it does the world some good. Different teams in the class can focus on different features if you like.
I met you several times while you worked with SolidTech. I was a happy user of Solid myself and through several clients. In particular, it made a great development database since it was lightweight and highly standardized (API-wise).
I found it easy to get small clients to invest in Solid for deployment which made it easier for me. I had trouble getting larger clients to use it for either development or deployment. They gnerally said the licenses were 'expensive' and then went and bought Oracle. Over time, as Solid Server disappeared, I moved to PostgreSQL.
Anyway, my question is, what made you go from Solid to MySQL and what do you think was Solid Server's failure? Was it just the competition from the FLOSS alternatives, or was there something more?
The problem is you need to make sure your software runs under *Home* edition; one of the best ways to do that kind of testing is in a VM, at least during active development. We always had images of a few standard end-user windows installs ready to load into VMWare on any of the development boxes. Every so many builds someone would test on real hardware just as a sanity check, but most testing was in a VM.
Testing Windows products is already a major pain. Being able to run in a VM with a rollback feature on another OS (Mac, Linux) makes it a bit more bearable. You want your VM image to be as basic as possible, definitely not a special development edition.
If you are careful and pay yourself last, you at least have some leeway to walk away from specific jobs. You can choose to take the hit financially in order to avoid a situation which would compromise either your ethics or standards. It is not a card you can play often, but it is one you do not have as an employee.
As someone else said, entrepreneurs have different goals than venture capitalists.
Build something or sell a service you like. Don't base the product on *just* you and your buddies, but if you do no like what you are making or providing, you'll hate yourself. Feeling good about yourself and having someplace worth going to every morning is worth much more than getting rich from an IPO. There will be plenty of opportunities to do something you don't like even when making a product you love. One of the best things about having your own business is that you can walk away. It may take food off your table, but you have the *choice*.
Doing something you like just plain sells better, too. Customers know when you are really excited about your product, and they know when you are just handing them a line. The worst sales job is selling something you don't care about, or worse, that you actively hate, to people you do not respect. Respect your customers, find out about *their* needs, but, at the end of the day, deliver something you care about or walk away. I never made it rich as an entrepreneur, but I would do it again in a heartbeat.
I agree wholeheartedly, but still hope things will work themselves out short of violence. Like many people, I have a family to protect and plan for, both their means of living and the things that make it worth living for. I am a moderate myself, and, in today's climate, that makes me a radical. Politics tends to swing like a pendulum: often it takes the leadership going to an extreme before the moderates start to wake up and drag things back to the center, but they tend to overreact and the situation drags the other way for the next generation to clean up.
[I live nearby; if you want to meet at some point, email me.]
Certainly you could have - but the officer in question was not there just to stop you from doing that. He was there to be a *witness* that you performed such an act. Its a bit of locking the door after admittedly, but its a darn sight better than nothing.
True, but if I had done something subtle like installed a back door or sent data somewhere, it would be hard for the officer to know just what he was a witness to.
When I was waiting for my TS clearance while working at the Pentagon (I had an interim clearance), I had to have an air force officer shadowing me the entire time, including, at points, typing for me as I dictated. The officer in question was not an IT person and had no idea what I was doing (or was supposed to do) with the UNIX systems under my care.
I could have typed, or told him to type "cd/; rm -rf *" at any point, or done many more subtle things, especially since I had to create accounts and such for Oracle or other applications.
In the end, the only way you can police your IT people is to have IT people you can trust, which means that the managers have to know enough IT to know what is going on and what it means without micromanaging. Very few managers have that ability. Very few IT people have the management ability to cross-train into a high-level manager. I, myself, had to bring in someone else to help with the business/finance side when running my own company. I knew what I was doing but was simply not as good at the business side as the IT work and sales.
I've worked alongside the publishing industry before. The big win with an electronic format is lack of risk. They already have the content and they have a marginal printing/storage cost. They do not have the risk of printing 1000 copies that sit in a warehouse or get returned by the retail chain. That is why many publishers (e.g. Baen Books, O'Reilley with some titles, AWL with some titles, many small publishers, etc.) give away the PDF or HTML versions of their books now. As other posters have said, many people consider the electronic form a bonus on top of the physical book they own. People who are happy with the electronic version never would have bought a hard copy anyway, but, if you hook them, they might in the future.
Well, one of the advantages of JIT compilation is compile-on-demand. If only 10.2 million lines of code are used in the course of a use of the application (say, the help system and macro system and template system and make-me-an-orange-julius subsystem is never loaded), then that is all that has to be compiled. If the program runs for an hour, it has that long to compile and optimize the code. If something is demanded before it is ready, the code can be interpreted the first time. The JIT has up-to-the-moment statistics on what is being used most and what is costing the most performance to concentrate optimization where it is needed.
Now, one advantage of compiling off-line is that you can add additional power (parallel compilation) to make your build go faster and spend more computing power on optimizations. However, much of that power is wasted on routines that real users will hardly run--- unless you have the time/money to get a panel of users to generate real and detailed profile information. I have seen this actually done once in my entire carreer. Generally, optimization is "best guess", especially when you do not have a large enough lab to get the profiling information on every sub-architecture your system will need to run on (Windows-single, Windows-dual, Windows-core-duo, Windows-quad, Linux-single, Linux-dual, Linux-core-duo, etc, etc.
As a quick reply to the Gentoo user, I would almost consider Gentoo a hybrid of online and offline compiling, where it is compiled specially for the user's own machine. Shipping Java byte-code (or whatever) and compiling it on platform is not much different.
That all being said, I think that the interpreted or byte compiled langauges will probably be designed better for this role in the future. Java byte code is not all that well designed for use as an intermediate compilation step. There are a lot of ways things can be improved to better convey the program intent and increase opportunites for optimization.
True, but platform specific bugs happen on every platform. The VMs are never perfect at insulating you. Sometimes it is an underlying OS bug but often the Java programmer took liberties with the language in assuming something the specification just does not guarantee. I have seen that often with threading code. There is a lot of threading behavior unspecified and this was worse in the past. The programmer thinks that because their code works on their test box that it is correct. Often it just worked by accident.
We had problems with Sun's JVM on Windows in a large server project when I was contracted to IBM. The JVM would not release closed socket handles and the pool would eventually run out, necessitating a reboot. At the rate the server was taking requests, "eventually" was very thirty minutes or so. Linux and Sun had no problem. As soon as IBMs own JVM became stable, we switched, but their JVM had subtle glitches too, though they were not as serious and it ran much faster.
Threading is really hard to do cross platform, and one of the main problems/benefits of Java is that every program is threaded.
Your argument actually points out how much *more* valuable interpreted and JIT languages will get. Are you going to compile new binaries for every architecture and combination of cores? Or, are you going to encode the logic of the application and have your JIT figure out how to optimize for the specific platform. Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.
Secondly, if it is a question of taking too long to compile, realize that you can always ship optimized binaries from high-level languages (e.g. GCJ), but you cannot readily make your optimized native code work on a new platform.
It was a PS/2 cluster with IBM DB/2 on AIX. If I remember right, it had 25 (4 processor) nodes when we built it, with 50 planned for launch and an increase to 75 within the first year. It was the second largest SP/2 cluster at te time. The largest, Deep Blue (yes, that one), is what we tested on.
The actual program to receive the CDRs and make the database inserts was the hardest and most processor intensive component. It was written in C but designed in an OO fashion. We needed very low-level control over allocation and execution that C++ did not (easily) give us. It processed the records, spread the database inserts across the nodes and sent each batch to a near-line storage system (tape robot). Everything had to have an audit trail to make sure that all the records were processed and nothing was tampered with.
The database expired records on a regular basis and tapes were overwritten (I forget what time period they decided on). This was so their burden in the case of subpoenas was strictly limited (ironic, no?).
We opted to eschew threading and just run multiple processes synchronized through file locks where necessary. It turned out to be seldom necessary and avoided a lot of potential thread-safety issues. There were still under-cooked routines in the AIX threaded C library that we would have needed. The other nicety is that the lock state gave us a lot of information when/if the system went down.
The hardest part of the project was dealing with poor specifications for the CDRs. They used ASN.1 for the encoding, but did not use it to actually *define* the fields, so we had the overhead of converting over-the-wire formats, but no benefit of portability. The sample data we were given was mostly empty (so we *still* had no idea what many fields contained). The database fields and conversion routines were changing daily right up to the testing phase.
Another extremely annoying part was trying to figure out the base times for the records. Each switch reported the call time in its own local time but did not note its time zone or its location. This lead to calls of negative lengths and all sorts of trouble when the program guessed wrong.
Anyway, it was an interesting project. It was actually quite fun to soak test the database loader and get to the point where we could throw essentially anything at it and have it synchronize and throttle correctly. DB/2 handled most of the database side psuedo-automatically. Once the schema was set up, it just worked. The Oracle rep said they could not have guaranteed proper performance over 100+ processors.
Indeed, my oath when I got my TS clearance specifically included "defending The Constitution". Even the oath itself recognizes that a higher cause trumps strict secrecy. That being said, I was never in contact with information that put me in that position. I do not envy people who are asked to decide between their oaths.
I, as an IT nerd, helped Sprint PCS design the database that collects the data which the NSA uses. With the terrabytes of CDRs coming off of their switches every day, it was a hell of a challenge.
The problem with your statement is that this database, like so many others, was developed for a good reason: streamlined, more accurate billing, and fraud detection. The problem, just like with guns, writable DVDs, and UWB scanners is most often in the way the technology is used, not in what it is. How do you separate the legitimate need from the abusive one? How do you separate knowledge of nucleonics that tells us how our Sun works from that which lets us construct bombs?
This is what law is for. This is also why government oversite exists. Both have failed.
My take is that the ISVs are not as much concerned by the fact that things are changing, but that the product is supposed to be in late beta, and they have no idea what the model is changing *to*. The old interface has gone away and the new interface is incomplete. They will not get a chance to design/develop/test anything during the beta period. This is odd considering that betas exist for *exactly* this reason.
The fact that an architectural change is happening this late in the process is yet another clue into the very ugly inner workings of the MS development team. I can see, perhaps, having some stubbed calls at this point, but not having the API even complete is ludicrous. It also gives MS a major advantage on any security apps it wants to ship.
True enough. I don't know if the product was ever finished per se. The cost overrun was absorbed by the client (time and materials), but the contract ran out. I left the company before the new contract over an even larger debacle: I worked a hundred-plus hour week and drove my team like a slaver to finish a deliverable that had been canceled the week before. Nobody told us--- even when I gave them a status report. I got an offer and left. They did lose something in the end.
True, those technologies are widely used at the margins of publishing. They take on specialized tasks, but there are many specialized tasks (Music, math, chemistry, computers & tech, reproduction of old manuscripts, multi-lingual texts, etc.)
HBJ does a good deal of textbook publishing where I would be suprised if they did not make use of markup-based formatters at some level, but I take your point.
The other thing of course which inevitably happens is that as soon as fast as Open Source tools stabilize they are incorporated. Many DPT packages can manipulate XML these days; word processors now commonly export to HTML/XML and there is an ISO standard format for it. Over time, special tools become mainstream and then are no longer seen as specialized.
I am specifically talking about LaTeX, which is built on top of TeX. Styles can be written in TeX while content is written in LaTeX. It is fairly easy to develop custom styles in LaTeX which express whatever your domain concepts are (e.g.: \method, \formula) while leaving the formatting and layout issues to the layout specialist.
It is also very easy to separate LaTeX documents into chunks which can be written/editted and version controled separatly. When combined into the master document, it is simple to update your TOC, LOF, index, etc. For a multi-author project with occasional outline changes, this is a big thing.
The problem comes in when a business goes with a proprietary solution when it is *known not to work* and they do not have the ability (are not allowed to) adapt it. As an example, I worked on a team at one point producing a 300 plus page analysis/rationale document for a large system where the document was being actively edited by 9 people and needed to be well indexed (as well as TOC, LOF, Code Listings, etc.) This was a good few years ago, but has stuck in my mind as a lesson to learn.
They decided to use Word for this because it was "standard" even though the tech writer said it could not be done. I recommended LaTeX: teach everyone on the team the bare minimum to mark up their sections and the tech writer and I (team lead) would write the glue to version control, assemble, and generate all the necessary indices. I had a proof of concept working. They still used Word. Managing the document was a nightmare which took more effort than all the writingcombined and the indices, while complete, were always wrong. Other errors in style or versioning were all over the document.
The lesson here is that proprietary apps are great within their domain. Certain Open Source Apps shine when you are doing something which has not been attempted, is seldom attempted, or is unique to your circumstances. Drawing that line is hard and is seldom done well.
Addison Wesley for one. The American Mathematical Society for another. It is still used for technical content, though DocBook is making inroads, too. Its clean separation of content and layout makes it ideal in many places where frequent layout changes are made and conventional DTP applications are nightmares. Since LaTeX directly generates typesetting formats (e.g. Postscript, DVI), it is not much harder for them.
I know that Andy Hunt and Dave Thomas have used LaTeX for every one of their books. They have some home-grown macros to make compiling and checking the example code automatic. This just cannot be done with Word or FrameMaker and is critical for eliminating copy errors.
For papers or books where the content is quite complex
Have them write a help system and user guide for an application, possibly an Open Source project which needs it.
Documentation needs to be clear, concise, and complete. There is enough style dfference between online help and tutorial/user guide to give some choice in how to write. Choose an application that would interest most students.
Another possibility is Wikipedia articles. Articles also need to be short, clear, and concise. Some may need to be created from scrathc and some edited. There is a wide range of topics, but you could choose a subset, like "biology," which would include everything from biochemistry-related topics to biographies of scientists.
In both cases, the students are *doing* something, which has a better chance of engaging interest than anything else. In both cases, students can have a bit of choice in what to write.
Yet another one is writing pamphlets or copy for a local charity or free newspaper. Newspaper articles follow a well-defined format and must be (you guessed it) clear, concise, and complete.
It's not so much a matter of hundreds of people formally reviewing code, though that, in fact does happen sometimes. The big thing is that to contribute to an OS project, you have to learn the existing system. That means at least several days staring at the code to figure out what the $%&#$$!! they were thinking. Sometimes it makes sense finally, some times it doesn't. When it does not make sense, newbies ask 'stupid' questions, and many times those questions end up uncovering flaws.
Surpisingly, even mass formal review of OS code happens. OS projects are often used as teaching tools. I have assigned interns to formally review OS code before and I know others who do as well. Further, some businesses or agencies who depend on certain OS products also formally review the code on a regular basis. These are often programming groups who are funded to contribute to an outside project and have to meet their own process requirements.
As another poster points out, there is such a rule. There are, in fact many rules to prevent this kind of patent from being granted or enforced. The problem is simply that none of the rules are *followed*.
I really want to see a class-action lawsuit against the USPTO.
Slashdot Mirror
The better question is how to keep people from forging the documents on which the "RealID" is based? The article does not say that authorities were busting rings of people forging state-issued drivers' licenses (although I know that happens as well), the article talks about forging birth certificates and social security cards.
So, what is to stop people from applying for a "RealID" based on forged credentials, even supposing the ID itself were unforgable? Given that someone else has an ID in your name, how do you prove who you are?
So, even if this is a problem worth solving, it looks like overhauling birth (or naturalization) certificates and social security cards is a better approach. But what do you do when someone loses their birth certificate? What do you do when someone needs more copies of their birth certificate? (There are several processes which require sending copies of birth certificates to various folks). These are harder questions than DHS likes to admit.
This is a question which comes up from time to time on Slashdot. I think the best approach is to pick an existing Open Source project and add a feature to it. That way students have to deal with an existing structure, existing policies, coding standards, etc., none of which are likely to be perfect, much as they would in the real world. Additionally, by focusing on a (non-trivial) feature, there is greater likelihood of actually completing the job in the time allotted. It gives the students a public chunk of code and a public acknowledgment they can point to. Lastly, it does the world some good. Different teams in the class can focus on different features if you like.
Sorry I am late to the game with a question, but:
I met you several times while you worked with SolidTech. I was a happy user of Solid myself and through several clients. In particular, it made a great development database since it was lightweight and highly standardized (API-wise).
I found it easy to get small clients to invest in Solid for deployment which made it easier for me. I had trouble getting larger clients to use it for either development or deployment. They gnerally said the licenses were 'expensive' and then went and bought Oracle. Over time, as Solid Server disappeared, I moved to PostgreSQL.
Anyway, my question is, what made you go from Solid to MySQL and what do you think was Solid Server's failure? Was it just the competition from the FLOSS alternatives, or was there something more?
The problem is you need to make sure your software runs under *Home* edition; one of the best ways to do that kind of testing is in a VM, at least during active development. We always had images of a few standard end-user windows installs ready to load into VMWare on any of the development boxes. Every so many builds someone would test on real hardware just as a sanity check, but most testing was in a VM.
Testing Windows products is already a major pain. Being able to run in a VM with a rollback feature on another OS (Mac, Linux) makes it a bit more bearable. You want your VM image to be as basic as possible, definitely not a special development edition.
If you are careful and pay yourself last, you at least have some leeway to walk away from specific jobs. You can choose to take the hit financially in order to avoid a situation which would compromise either your ethics or standards. It is not a card you can play often, but it is one you do not have as an employee.
As someone else said, entrepreneurs have different goals than venture capitalists.
Build something or sell a service you like. Don't base the product on *just* you and your buddies, but if you do no like what you are making or providing, you'll hate yourself. Feeling good about yourself and having someplace worth going to every morning is worth much more than getting rich from an IPO. There will be plenty of opportunities to do something you don't like even when making a product you love. One of the best things about having your own business is that you can walk away. It may take food off your table, but you have the *choice*.
Doing something you like just plain sells better, too. Customers know when you are really excited about your product, and they know when you are just handing them a line. The worst sales job is selling something you don't care about, or worse, that you actively hate, to people you do not respect. Respect your customers, find out about *their* needs, but, at the end of the day, deliver something you care about or walk away. I never made it rich as an entrepreneur, but I would do it again in a heartbeat.
I agree wholeheartedly, but still hope things will work themselves out short of violence. Like many people, I have a family to protect and plan for, both their means of living and the things that make it worth living for. I am a moderate myself, and, in today's climate, that makes me a radical. Politics tends to swing like a pendulum: often it takes the leadership going to an extreme before the moderates start to wake up and drag things back to the center, but they tend to overreact and the situation drags the other way for the next generation to clean up.
[I live nearby; if you want to meet at some point, email me.]
True, but if I had done something subtle like installed a back door or sent data somewhere, it would be hard for the officer to know just what he was a witness to.
When I was waiting for my TS clearance while working at the Pentagon (I had an interim clearance), I had to have an air force officer shadowing me the entire time, including, at points, typing for me as I dictated. The officer in question was not an IT person and had no idea what I was doing (or was supposed to do) with the UNIX systems under my care.
/; rm -rf *" at any point, or done many more subtle things, especially since I had to create accounts and such for Oracle or other applications.
I could have typed, or told him to type "cd
In the end, the only way you can police your IT people is to have IT people you can trust, which means that the managers have to know enough IT to know what is going on and what it means without micromanaging. Very few managers have that ability. Very few IT people have the management ability to cross-train into a high-level manager. I, myself, had to bring in someone else to help with the business/finance side when running my own company. I knew what I was doing but was simply not as good at the business side as the IT work and sales.
I've worked alongside the publishing industry before. The big win with an electronic format is lack of risk. They already have the content and they have a marginal printing/storage cost. They do not have the risk of printing 1000 copies that sit in a warehouse or get returned by the retail chain. That is why many publishers (e.g. Baen Books, O'Reilley with some titles, AWL with some titles, many small publishers, etc.) give away the PDF or HTML versions of their books now. As other posters have said, many people consider the electronic form a bonus on top of the physical book they own. People who are happy with the electronic version never would have bought a hard copy anyway, but, if you hook them, they might in the future.
Well, one of the advantages of JIT compilation is compile-on-demand. If only 10.2 million lines of code are used in the course of a use of the application (say, the help system and macro system and template system and make-me-an-orange-julius subsystem is never loaded), then that is all that has to be compiled. If the program runs for an hour, it has that long to compile and optimize the code. If something is demanded before it is ready, the code can be interpreted the first time. The JIT has up-to-the-moment statistics on what is being used most and what is costing the most performance to concentrate optimization where it is needed.
Now, one advantage of compiling off-line is that you can add additional power (parallel compilation) to make your build go faster and spend more computing power on optimizations. However, much of that power is wasted on routines that real users will hardly run--- unless you have the time/money to get a panel of users to generate real and detailed profile information. I have seen this actually done once in my entire carreer. Generally, optimization is "best guess", especially when you do not have a large enough lab to get the profiling information on every sub-architecture your system will need to run on (Windows-single, Windows-dual, Windows-core-duo, Windows-quad, Linux-single, Linux-dual, Linux-core-duo, etc, etc.
As a quick reply to the Gentoo user, I would almost consider Gentoo a hybrid of online and offline compiling, where it is compiled specially for the user's own machine. Shipping Java byte-code (or whatever) and compiling it on platform is not much different.
That all being said, I think that the interpreted or byte compiled langauges will probably be designed better for this role in the future. Java byte code is not all that well designed for use as an intermediate compilation step. There are a lot of ways things can be improved to better convey the program intent and increase opportunites for optimization.
True, but platform specific bugs happen on every platform. The VMs are never perfect at insulating you. Sometimes it is an underlying OS bug but often the Java programmer took liberties with the language in assuming something the specification just does not guarantee. I have seen that often with threading code. There is a lot of threading behavior unspecified and this was worse in the past. The programmer thinks that because their code works on their test box that it is correct. Often it just worked by accident.
We had problems with Sun's JVM on Windows in a large server project when I was contracted to IBM. The JVM would not release closed socket handles and the pool would eventually run out, necessitating a reboot. At the rate the server was taking requests, "eventually" was very thirty minutes or so. Linux and Sun had no problem. As soon as IBMs own JVM became stable, we switched, but their JVM had subtle glitches too, though they were not as serious and it ran much faster.
Threading is really hard to do cross platform, and one of the main problems/benefits of Java is that every program is threaded.
Your argument actually points out how much *more* valuable interpreted and JIT languages will get. Are you going to compile new binaries for every architecture and combination of cores? Or, are you going to encode the logic of the application and have your JIT figure out how to optimize for the specific platform. Before you say that JITs cannot hack this, remember that they use exactly the same technology as your 'standard' compilers.
Secondly, if it is a question of taking too long to compile, realize that you can always ship optimized binaries from high-level languages (e.g. GCJ), but you cannot readily make your optimized native code work on a new platform.
It was a PS/2 cluster with IBM DB/2 on AIX. If I remember right, it had 25 (4 processor) nodes when we built it, with 50 planned for launch and an increase to 75 within the first year. It was the second largest SP/2 cluster at te time. The largest, Deep Blue (yes, that one), is what we tested on.
The actual program to receive the CDRs and make the database inserts was the hardest and most processor intensive component. It was written in C but designed in an OO fashion. We needed very low-level control over allocation and execution that C++ did not (easily) give us. It processed the records, spread the database inserts across the nodes and sent each batch to a near-line storage system (tape robot). Everything had to have an audit trail to make sure that all the records were processed and nothing was tampered with.
The database expired records on a regular basis and tapes were overwritten (I forget what time period they decided on). This was so their burden in the case of subpoenas was strictly limited (ironic, no?).
We opted to eschew threading and just run multiple processes synchronized through file locks where necessary. It turned out to be seldom necessary and avoided a lot of potential thread-safety issues. There were still under-cooked routines in the AIX threaded C library that we would have needed. The other nicety is that the lock state gave us a lot of information when/if the system went down.
The hardest part of the project was dealing with poor specifications for the CDRs. They used ASN.1 for the encoding, but did not use it to actually *define* the fields, so we had the overhead of converting over-the-wire formats, but no benefit of portability. The sample data we were given was mostly empty (so we *still* had no idea what many fields contained). The database fields and conversion routines were changing daily right up to the testing phase.
Another extremely annoying part was trying to figure out the base times for the records. Each switch reported the call time in its own local time but did not note its time zone or its location. This lead to calls of negative lengths and all sorts of trouble when the program guessed wrong.
Anyway, it was an interesting project. It was actually quite fun to soak test the database loader and get to the point where we could throw essentially anything at it and have it synchronize and throttle correctly. DB/2 handled most of the database side psuedo-automatically. Once the schema was set up, it just worked. The Oracle rep said they could not have guaranteed proper performance over 100+ processors.
Indeed, my oath when I got my TS clearance specifically included "defending The Constitution". Even the oath itself recognizes that a higher cause trumps strict secrecy. That being said, I was never in contact with information that put me in that position. I do not envy people who are asked to decide between their oaths.
I, as an IT nerd, helped Sprint PCS design the database that collects the data which the NSA uses. With the terrabytes of CDRs coming off of their switches every day, it was a hell of a challenge.
The problem with your statement is that this database, like so many others, was developed for a good reason: streamlined, more accurate billing, and fraud detection. The problem, just like with guns, writable DVDs, and UWB scanners is most often in the way the technology is used, not in what it is. How do you separate the legitimate need from the abusive one? How do you separate knowledge of nucleonics that tells us how our Sun works from that which lets us construct bombs?
This is what law is for. This is also why government oversite exists. Both have failed.
My take is that the ISVs are not as much concerned by the fact that things are changing, but that the product is supposed to be in late beta, and they have no idea what the model is changing *to*. The old interface has gone away and the new interface is incomplete. They will not get a chance to design/develop/test anything during the beta period. This is odd considering that betas exist for *exactly* this reason.
The fact that an architectural change is happening this late in the process is yet another clue into the very ugly inner workings of the MS development team. I can see, perhaps, having some stubbed calls at this point, but not having the API even complete is ludicrous. It also gives MS a major advantage on any security apps it wants to ship.
True enough. I don't know if the product was ever finished per se. The cost overrun was absorbed by the client (time and materials), but the contract ran out. I left the company before the new contract over an even larger debacle: I worked a hundred-plus hour week and drove my team like a slaver to finish a deliverable that had been canceled the week before. Nobody told us--- even when I gave them a status report. I got an offer and left. They did lose something in the end.
True, those technologies are widely used at the margins of publishing. They take on specialized tasks, but there are many specialized tasks (Music, math, chemistry, computers & tech, reproduction of old manuscripts, multi-lingual texts, etc.)
HBJ does a good deal of textbook publishing where I would be suprised if they did not make use of markup-based formatters at some level, but I take your point.
The other thing of course which inevitably happens is that as soon as fast as Open Source tools stabilize they are incorporated. Many DPT packages can manipulate XML these days; word processors now commonly export to HTML/XML and there is an ISO standard format for it. Over time, special tools become mainstream and then are no longer seen as specialized.
I am specifically talking about LaTeX, which is built on top of TeX. Styles can be written in TeX while content is written in LaTeX. It is fairly easy to develop custom styles in LaTeX which express whatever your domain concepts are (e.g.: \method, \formula) while leaving the formatting and layout issues to the layout specialist.
It is also very easy to separate LaTeX documents into chunks which can be written/editted and version controled separatly. When combined into the master document, it is simple to update your TOC, LOF, index, etc. For a multi-author project with occasional outline changes, this is a big thing.
The problem comes in when a business goes with a proprietary solution when it is *known not to work* and they do not have the ability (are not allowed to) adapt it. As an example, I worked on a team at one point producing a 300 plus page analysis/rationale document for a large system where the document was being actively edited by 9 people and needed to be well indexed (as well as TOC, LOF, Code Listings, etc.) This was a good few years ago, but has stuck in my mind as a lesson to learn.
They decided to use Word for this because it was "standard" even though the tech writer said it could not be done. I recommended LaTeX: teach everyone on the team the bare minimum to mark up their sections and the tech writer and I (team lead) would write the glue to version control, assemble, and generate all the necessary indices. I had a proof of concept working. They still used Word. Managing the document was a nightmare which took more effort than all the writingcombined and the indices, while complete, were always wrong. Other errors in style or versioning were all over the document.
The lesson here is that proprietary apps are great within their domain. Certain Open Source Apps shine when you are doing something which has not been attempted, is seldom attempted, or is unique to your circumstances. Drawing that line is hard and is seldom done well.
Addison Wesley for one. The American Mathematical Society for another. It is still used for technical content, though DocBook is making inroads, too. Its clean separation of content and layout makes it ideal in many places where frequent layout changes are made and conventional DTP applications are nightmares. Since LaTeX directly generates typesetting formats (e.g. Postscript, DVI), it is not much harder for them.
I know that Andy Hunt and Dave Thomas have used LaTeX for every one of their books. They have some home-grown macros to make compiling and checking the example code automatic. This just cannot be done with Word or FrameMaker and is critical for eliminating copy errors.
For papers or books where the content is quite complex
Have them write a help system and user guide for an application, possibly an Open Source project which needs it.
Documentation needs to be clear, concise, and complete. There is enough style dfference between online help and tutorial/user guide to give some choice in how to write. Choose an application that would interest most students.
Another possibility is Wikipedia articles. Articles also need to be short, clear, and concise. Some may need to be created from scrathc and some edited. There is a wide range of topics, but you could choose a subset, like "biology," which would include everything from biochemistry-related topics to biographies of scientists.
In both cases, the students are *doing* something, which has a better chance of engaging interest than anything else. In both cases, students can have a bit of choice in what to write.
Yet another one is writing pamphlets or copy for a local charity or free newspaper. Newspaper articles follow a well-defined format and must be (you guessed it) clear, concise, and complete.
It's not so much a matter of hundreds of people formally reviewing code, though that, in fact does happen sometimes. The big thing is that to contribute to an OS project, you have to learn the existing system. That means at least several days staring at the code to figure out what the $%&#$$!! they were thinking. Sometimes it makes sense finally, some times it doesn't. When it does not make sense, newbies ask 'stupid' questions, and many times those questions end up uncovering flaws.
Surpisingly, even mass formal review of OS code happens. OS projects are often used as teaching tools. I have assigned interns to formally review OS code before and I know others who do as well. Further, some businesses or agencies who depend on certain OS products also formally review the code on a regular basis. These are often programming groups who are funded to contribute to an outside project and have to meet their own process requirements.
As another poster points out, there is such a rule. There are, in fact many rules to prevent this kind of patent from being granted or enforced. The problem is simply that none of the rules are *followed*.
I really want to see a class-action lawsuit against the USPTO.