I've been running it for about 10 days now. It's basically BSD (Mach 3.0) with a Mac shell. It runs Mac OS 9 as an application and the major showstopper is that PPP can't be used (yet) with the older stuff. I leave a terminal window up at all times and switch between the two Mac OS shells and BSD on an as-needed basis. It makes the Windows NT 4.0 machine on the other desk look like a toy. (Of course, I've been a UNIX sysadmin.) Recommended.
Thanks for posting a URL to the patent. I have some technical concerns with security (such as cleartext passwords for everyone being available to the security administrator), and the claims do not appear to be very original. I suspect there are a number of equivalent packages available. I think we should remember that the PTO is funded by user fees, so it will tend to err on the side of credulity in assessing patent applications. I have heard there are some US patents for perpetual motion machines and other impossibilities. Unlike the Swiss patent office, we don't hire Einsteins.
The problems with VC++ and MFC are a frequent subject of discussion on comp.lang.C++.moderated--if you're interested in this issue, drop by.
To summarize the consensus there:
the compiler is not standard-compliant and is not likely to become standard-compliant in the foreseeable future. Microsoft seems to regard large corporations as its primary customers and the various versions of Windows, IE, Outlook and Office as its primary products. Everything else is frosting. Unless someone in MS is willing to push the technology in a second-tier product, nothing happens.
MFC appears to be incompatible with the new standard, and as the MS programmers use MFC, there is no internal force driving standards compliance.
Yes, the STL is nicer, more elegant, easier to use, less buggy, etc... In fact, the availability of the STL is perhaps the major advance in programming during the last decade. But, there are a lot of second-rank programmers who specialize in Windows applications and who will never use the STL.
Please remember, MS is software for the rest of us. The bug rate (software faults per KSLOC) in MS software appears to be about 3 times the rate that the Government is willing to accept from anyone else. You get what you pay for.
Unless the API is very well defined, having software developed at more than one site will increase the costs of development. The CoCoMo II model (Boehm et al.) treats the costs of software development as increasing as the organizations become more physically distributed. I can confirm this happens.
Security is much harder to ensure if software is outsourced internationally. Basically, if it turns out that someone has inserted a backdoor, it's harder to discover that it has happened and it's harder to do anything about it (legally).
Software engineering quality. If you want high quality software, you have to pay for the corresponding education/training.
In other words, trusted third party (as in Kerberos). See Bruce Schneier, Secrets and Lies: Digital Security in a Networked World, for some of the interesting pitfalls. Trust me, some perp will figure out a way to use it in a way that the vendor never expected nor wanted.
For most products, either the vendor warrents that it was built by craftsmen to specification, or the persons building it meet minimal standards of education and professionalism. Software is neither, which is a shame, because people's lives and money often do depend on the correct operation of the program. The software industry has become mature enough that some sort of warrenty protection is now appropriate.
This pattern of CS-savvy kids preferring IT jobs to college is not unique to the US; it is also being seen in Europe. I can understand the motivation of the kids--it's similar to basketball players choosing the pros over a degree.
But it's probably not the best decision in the long-term. Most academic CS programs deliberately avoid covering topics that are likely to become obsolete in 5 years. Instead, they try to provide a career foundation, emphasizing material that is likely to be important on multiple projects. At the same time, companies attempting to fill upper-tier software engineering jobs (at whatever level) tend to have a search image that includes both experience in the workplace and success in academic CS coursework. So not getting the academic background is likely to lead to a dead-end.
I've taught from the first edition of the text and have had to make the same sort of decision. We ended up using ecgs for the grading compiler, simply because Codewarrior didn't run on the Alpha. I prefer Codewarrior because it is a good deal more standard-compliant than the current ecgs. That means you'll probably be OK going from ecgs to CW, but you _will_ need to check things at the end.
That's generally what I do, too. Herb Sutter's new book is also good for getting new ideas. I will also stand back and refactor my program design to make it cleaner and sharper.
Programming is one of the most complicated and difficult human activities, particularly if the system is of any size. There is reason to believe (Rosen, 1985, Life Itself; Chaitin, 1987, Algorithmic Information Theory) that it cannot be formalized. That immediately implies code is a form of expression.
The purposes of a security audit trail are two: 1. to allow you to reconstruct what happened when your system was attacked or failed in some way, and 2. to serve as legal evidence, when you do go after someone.
The detail in the log and the degree of protection that you give it should reflect your goals, but remember that some malicious intruders trash the system they've hacked if they suspect someone is onto them. That would suggest some degree of care is warranted. If the audit trail is to be used as legal evidence, you'll need to demonstrate that it hasn't been modified after the event. If it is only to help you analyze what happened after the fact, you should at least protect it from malicious access, since the hacker would love to know what you know.
-Might I ask what leads you to draw this conclusion?
1. Garbage collection. That can lead to problems in two contexts--when the program decides to collect the garbage, and when memory gets so fragmented that finding a block to allocate is a day-long task.
2. The inheritance tree. Not only are reference types accessed indirectly, but construction and destruction has to pass through everything between the root and the type being constructed.
3. Lack of generics. User-defined algorithms and containers tend to be inefficient.
4. Strings being a reference class. In Java, the construction of temporaries (especially string temporaries) is a big slow-down.
5. The general tone of the language manual, and the tendency of MS to design things that slosh as they walk.
I went through the documentation. It's basically Java embraced and extended. No templates; no generics. Two categories of types: value and reference. Value types are like int and C structs, while the reference types are more like C++ and Java classes. Garbage collection. You can't alias value types, but you can't avoid it for reference types. All types inherit from an object type. Property lists. Closely tied to COM and the MS APIs. Performance is likely to be a problem. No sign of careful or deep thought being given to the language definition. Perhaps the COBOL of the new millenium?
The auditor is correct. You're supposed to pay use taxes on anything you purchase out of state--just like you're expected to pay for all your shareware.
The news reports make C# appear to be a Java clone designed to make use of the existing MS jvm. Given that Sun designed the jvm to support other languages than Java, I can see why MS has gone this direction. I suspect C# will have similar weaknesses to those seen for Java. Based on a discussion with a Java guru, these are likely to include: 1. High memory utilization (heh...) 2. Garbage collection preventing use in RT and near-RT applications. Also, object lifetimes are not well-defined--they may never run their finalization logic, which can be disasterous for persistent data objects. 3. Increasing memory fragmentation over time (also seen in MFC). 4. Object (especially String) instantiation as a big slowdown 5. The code associated with large objects being inefficient 6. Inadvertant memory leaks (multitudinous ways) 7. Class hierarchy explosions 8. Threads (heh...) If you follow the C++ language boards, you will have noticed that MS has shown little interest in VC++ becoming standard-compliant. This appears to be the same pattern. Comments?
The book is interesting, but as the reviewer noted only covers about 1/2 of the introductory semester (about what we would cover in a course for managers 8). Just to provide some insight from several years of teaching, I suspect that a C++ programmer needs 4 semesters of coursework in programming and data structures (including at least one major project) and a 5th semester in software engineering to be able to handle a job as an entry-level programmer in industry or business.
These results are of some interest to me, because my department (I'm a CS adjunct at GMU) has asked me to consider learning Java well enough to teach the third-year OOP course in it; my daytime employer has asked me to get up to speed in it for a proposal; I'm very interested in multithreading (which C++ is not so hot at); and I'm currently using a Java application (CCTool, built using the IBM compiler) to write security targets for a gov't agency. Current Java compilers remind me of the first Ada compilers back in the early 1980s. The Java application sloshes as it walks around, mostly due to thrashing. The thread features and the garbage collection are just a bit dangerous to use, and I've been told that Java applications have to be carefully written if you want them to run faster than a turtle. The posted comparisons don't seem to fit the real world experience I've been having, but most such comparisons tend to be cooked to favor one or another language. Cheers,
Yes, some people set up honeypots (see Amoroso's and Bace's books on intrusion detection). I also suspect some folks have developed trap systems that actively counterattack attempted intrusions, even if launched through innocent third parties. I have even heard there is a phone company in Southern California that uses these approaches for revenue enhancement--if they catch you, they bill you. I can't say any of these approaches are particularly good ideas. The back-fire potential appears to be high. Of course, I might be an old fogy...
Slashdot Mirror
I've been running it for about 10 days now. It's basically BSD (Mach 3.0) with a Mac shell. It runs Mac OS 9 as an application and the major showstopper is that PPP can't be used (yet) with the older stuff. I leave a terminal window up at all times and switch between the two Mac OS shells and BSD on an as-needed basis. It makes the Windows NT 4.0 machine on the other desk look like a toy. (Of course, I've been a UNIX sysadmin.) Recommended.
Thanks for posting a URL to the patent. I have some technical concerns with security (such as cleartext passwords for everyone being available to the security administrator), and the claims do not appear to be very original. I suspect there are a number of equivalent packages available. I think we should remember that the PTO is funded by user fees, so it will tend to err on the side of credulity in assessing patent applications. I have heard there are some US patents for perpetual motion machines and other impossibilities. Unlike the Swiss patent office, we don't hire Einsteins.
The problems with VC++ and MFC are a frequent subject of discussion on comp.lang.C++.moderated--if you're interested in this issue, drop by.
To summarize the consensus there:
the compiler is not standard-compliant and is not likely to become standard-compliant in the foreseeable future. Microsoft seems to regard large corporations as its primary customers and the various versions of Windows, IE, Outlook and Office as its primary products. Everything else is frosting. Unless someone in MS is willing to push the technology in a second-tier product, nothing happens.
MFC appears to be incompatible with the new standard, and as the MS programmers use MFC, there is no internal force driving standards compliance.
Yes, the STL is nicer, more elegant, easier to use, less buggy, etc... In fact, the availability of the STL is perhaps the major advance in programming during the last decade. But, there are a lot of second-rank programmers who specialize in Windows applications and who will never use the STL.
Please remember, MS is software for the rest of us. The bug rate (software faults per KSLOC) in MS software appears to be about 3 times the rate that the Government is willing to accept from anyone else. You get what you pay for.
There are at least three:
Unless the API is very well defined, having software developed at more than one site will increase the costs of development. The CoCoMo II model (Boehm et al.) treats the costs of software development as increasing as the organizations become more physically distributed. I can confirm this happens.
Security is much harder to ensure if software is outsourced internationally. Basically, if it turns out that someone has inserted a backdoor, it's harder to discover that it has happened and it's harder to do anything about it (legally).
Software engineering quality. If you want high quality software, you have to pay for the corresponding education/training.
I hope that helps.
In other words, trusted third party (as in Kerberos). See Bruce Schneier, Secrets and Lies: Digital Security in a Networked World, for some of the interesting pitfalls. Trust me, some perp will figure out a way to use it in a way that the vendor never expected nor wanted.
For most products, either the vendor warrents that it was built by craftsmen to specification, or the persons building it meet minimal standards of education and professionalism. Software is neither, which is a shame, because people's lives and money often do depend on the correct operation of the program. The software industry has become mature enough that some sort of warrenty protection is now appropriate.
This pattern of CS-savvy kids preferring IT jobs to college is not unique to the US; it is also being seen in Europe. I can understand the motivation of the kids--it's similar to basketball players choosing the pros over a degree.
But it's probably not the best decision in the long-term. Most academic CS programs deliberately avoid covering topics that are likely to become obsolete in 5 years. Instead, they try to provide a career foundation, emphasizing material that is likely to be important on multiple projects. At the same time, companies attempting to fill upper-tier software engineering jobs (at whatever level) tend to have a search image that includes both experience in the workplace and success in academic CS coursework. So not getting the academic background is likely to lead to a dead-end.
I've taught from the first edition of the text and have had to make the same sort of decision. We ended up using ecgs for the grading compiler, simply because Codewarrior didn't run on the Alpha. I prefer Codewarrior because it is a good deal more standard-compliant than the current ecgs. That means you'll probably be OK going from ecgs to CW, but you _will_ need to check things at the end.
Very interesting paper. Actually, the process is more general than vision--bats seem to use something similar in echolocation to localize insect prey.
That's generally what I do, too. Herb Sutter's new book is also good for getting new ideas. I will also stand back and refactor my program design to make it cleaner and sharper.
Programming is one of the most complicated and difficult human activities, particularly if the system is of any size. There is reason to believe (Rosen, 1985, Life Itself; Chaitin, 1987, Algorithmic Information Theory) that it cannot be formalized. That immediately implies code is a form of expression.
The purposes of a security audit trail are two: 1. to allow you to reconstruct what happened when your system was attacked or failed in some way, and 2. to serve as legal evidence, when you do go after someone.
The detail in the log and the degree of protection that you give it should reflect your goals, but remember that some malicious intruders trash the system they've hacked if they suspect someone is onto them. That would suggest some degree of care is warranted. If the audit trail is to be used as legal evidence, you'll need to demonstrate that it hasn't been modified after the event. If it is only to help you analyze what happened after the fact, you should at least protect it from malicious access, since the hacker would love to know what you know.
Transmeta is privately held and has plenty of capital.
--Performance is likely to be a problem
-Might I ask what leads you to draw this conclusion?
1. Garbage collection. That can lead to problems in two contexts--when the program decides to collect the garbage, and when memory gets so fragmented that finding a block to allocate is a day-long task.
2. The inheritance tree. Not only are reference types accessed indirectly, but construction and destruction has to pass through everything between the root and the type being constructed.
3. Lack of generics. User-defined algorithms and containers tend to be inefficient.
4. Strings being a reference class. In Java, the construction of temporaries (especially string temporaries) is a big slow-down.
5. The general tone of the language manual, and the tendency of MS to design things that slosh as they walk.
I went through the documentation. It's basically Java embraced and extended. No templates; no generics. Two categories of types: value and reference. Value types are like int and C structs, while the reference types are more like C++ and Java classes. Garbage collection. You can't alias value types, but you can't avoid it for reference types. All types inherit from an object type. Property lists. Closely tied to COM and the MS APIs. Performance is likely to be a problem. No sign of careful or deep thought being given to the language definition. Perhaps the COBOL of the new millenium?
The auditor is correct. You're supposed to pay use taxes on anything you purchase out of state--just like you're expected to pay for all your shareware.
The news reports make C# appear to be a Java clone designed to make use of the existing MS jvm. Given that Sun designed the jvm to support other languages than Java, I can see why MS has gone this direction. I suspect C# will have similar weaknesses to those seen for Java. Based on a discussion with a Java guru, these are likely to include: 1. High memory utilization (heh...) 2. Garbage collection preventing use in RT and near-RT applications. Also, object lifetimes are not well-defined--they may never run their finalization logic, which can be disasterous for persistent data objects. 3. Increasing memory fragmentation over time (also seen in MFC). 4. Object (especially String) instantiation as a big slowdown 5. The code associated with large objects being inefficient 6. Inadvertant memory leaks (multitudinous ways) 7. Class hierarchy explosions 8. Threads (heh...) If you follow the C++ language boards, you will have noticed that MS has shown little interest in VC++ becoming standard-compliant. This appears to be the same pattern. Comments?
The book is interesting, but as the reviewer noted only covers about 1/2 of the introductory semester (about what we would cover in a course for managers 8). Just to provide some insight from several years of teaching, I suspect that a C++ programmer needs 4 semesters of coursework in programming and data structures (including at least one major project) and a 5th semester in software engineering to be able to handle a job as an entry-level programmer in industry or business.
These results are of some interest to me, because my department (I'm a CS adjunct at GMU) has asked me to consider learning Java well enough to teach the third-year OOP course in it; my daytime employer has asked me to get up to speed in it for a proposal; I'm very interested in multithreading (which C++ is not so hot at); and I'm currently using a Java application (CCTool, built using the IBM compiler) to write security targets for a gov't agency. Current Java compilers remind me of the first Ada compilers back in the early 1980s. The Java application sloshes as it walks around, mostly due to thrashing. The thread features and the garbage collection are just a bit dangerous to use, and I've been told that Java applications have to be carefully written if you want them to run faster than a turtle. The posted comparisons don't seem to fit the real world experience I've been having, but most such comparisons tend to be cooked to favor one or another language. Cheers,
Yes, some people set up honeypots (see Amoroso's and Bace's books on intrusion detection). I also suspect some folks have developed trap systems that actively counterattack attempted intrusions, even if launched through innocent third parties. I have even heard there is a phone company in Southern California that uses these approaches for revenue enhancement--if they catch you, they bill you. I can't say any of these approaches are particularly good ideas. The back-fire potential appears to be high. Of course, I might be an old fogy...
There's evidence (Rosen) that life can't been effectively simulated.