Actually the first Asynchronous Microprocessor (in VLSI) was developed in 1989:
The First Asynchronous Microprocessor: The Test Results. A.J. Martin, S.M. Burns, T.K. Lee, D. Borkovic, and P.J. Hazewindus. Computer Architecture News, 17(4), 95-110, June 1989. [CS-TR-89-06]
The Design of an Asynchronous Microprocessor. A.J. Martin, S.M. Burns, T.K. Lee, D. Borkovic, and P.J. Hazewindus. ARVLSI: Decennial Caltech Conference on VLSI, ed. C.L. Seitz, 351-373, MIT Press, 1989. [PS | CS-TR-89-02 ]
Allow me to change the other replier's "maybe overvoltage" comment to "absolutely, all it means is that you need to increase the voltage."
More voltage => more heat => same "overclocking" game.
Some numbers (sorry, old from the '90s) for an Asynchronous MIPS R3000 (Vdd, MIPS, power dissipiation (W)) (1.00, 9.66, 0.021) (1.51, 66, 0.29) (3.08, 165, 3.4) (3.30, 177, 4.2) (3.51, 185, 5.1) (4.95, 233.6, 13.7)
1) get the transistors to switch faster 2) reduce the number of transitions on the critial paths
This is the same for synchronous and asynchronous designs.
1) can be handled using voltage scaling (higher V, faster transitions) or simply with scaling (e.g. going from 180nm to 90nm). 2) This ultimately comes down to hyper-pipelining something which is slightly easier in asynchronous circuits.
I've never wanted a program that I couldn't run under FreeBSD--seriously!
Sure, a little 2k widget program you find somewhere coded especially for linux might be hard to compile on FreeBSD... but the solution is to just compile it on a linux machine (or trust a published linux binary). Why? FreeBSD runs linux binaries. It does this by emulating the linux system calls at almost no overhead and installing a set of libraries from Red Hat in/usr/compat/linux
The kernel/loader takes care of the rest. Basically, linux programs tend to just work unless they depend on some special kernel module.
As for native BSD binaries. You have ports (a push-button way to compile it yourself) or packages (a push-button way to have your computer fetch a precompiled binary from the FreeBSD build cluster).
The best part? FreeBSD maintains a vulnerability database for third-part software. Installing a program that depends on a library version with a known vulnerability? make install gives you a heads up warning. Concerned about people hacking into distribution sites and putting trojans into the source and/or source? The FreeBSD team maintains their own database of MD5 which is consulted to verify that the source is the same source that past inspection by the port maintainer.
Okay, but there isn't one best solution. There is that saying "jack of all trades" master of none. The BSDs tend to fork over major kernel architectual differences (rather than eye-candy or userland disagreements), but despite that they share and exchange code extensively. Maybe the linux approach would be okay if Linux really was a god and _knew_ exactly what the "best" solution was but that is the case. He's just a pretty smart guy like Matt Dillon of DragonflyBSD, Robert Watsom of FreeBSD, or Theo of OpenBSD.
Smart, informed people can disagree on how to do things. The variation on the BSDs allow those ideas to be realistically tested in practice.
So you could just as well make a diversity argument here. No one is betting the entire BSD farm on the one true and holy kernel architecture.
Also you make light of switching linux distributions. The BSDs tend to be much more similar in their operation and usage than linux distributions. The differences are under the hood or in the choices for default configuration, not in the man-machine interface.
Also, while people are pretty fond of saying OpenBSD for Security, FreeBSD for performance/stability... that sort of belies the complexity. Yeah, FreeBSD tends to have the best performance but it also has a really good security team. Is FreeBSD up to the same auditing level as OpenBSD? No, but it is audited to a very reasonable level.
To plug my own work, check out http://www.async.caltech.edu. We're nearing tape-out on an asynchronous implementation of an 8051.
You almost mention this but while limiting clock distribution is not responsible for a 3 GHz boundary as suggested by the original author. Chip clocks have been pushed much beyond that over very large die areas.
No. Clock distribution is quite complicated. What is required is phase consistency within a skew margin, not that the same clock pulse appear everywhere at the same time.
Even in a simple tree distrubution scheme, you just need to ensure that the skew between any two latches with intervening logic is tolerable.
This is just another reason to introduce latches (and thus pipelining).
You're also off the mark. It is almost certain that there is no electrical pathway that spans the chip without hitting some logic. The number in 90nm (for best performance) is about 12000\lambda (\lambda = 90nm). Often signals propogate much smaller distances in a cycle. I assure you in one cycle no one is making a signal traverse the entire core.
Modern CPUs are highly pipelined which is essentially to say that in one clock cycle data is transfered and processed within a very small section of the chip before being passed on to the next stage. This then frees the stage for the next bit of data.
see http://en.wikipedia.org/wiki/Pipelining
As a side consequence, what you mention is not the limiting the factor. Signals simply do not need to propogate across the chip in one cycle.
What has really happened is the drive current available from each transistor has gotten smaller as the transistor itself has shrunk. The wiring capacitance has remained the same and begun to predominate over the gate capacitence. Thus, making the transistors smaller does not make the circuit faster as it once did.
Also, as someone else pointed out, the mobility of electrons in semiconductors is no where near the numbers you quote. Electronics simply don't work the way you claim.
Not to mention that this upcoming release will have ndis support enabled by default... which should allow you to use a binary windows driver to get your card up and running.
In fact, that's why we signed the agreement to have this done almost a decade ago. Contrary to the politically motivated suggestions otherwise, this was _not_ a response to 2000 election.
We wanted to place monitors in other countries and got a response back something like, "Why don't you take monitors if you're so keen on this" and we said "sure".
AT&T has been working on this for many years now (they started really investigating VoIP back in '98 as part of their plan to use their (then) vast cable network to offer phone service in competition with the baby bells.)
This is not proprietary in the way you likely think it is. All of their work has been based on open standards (of which there is a confusion! of conflicting open standards). VoIP equipment vendors all tend to implement "something" which is sort of like some published standard but rarely works with other vendors equipment.
AT&T through years of work cobbled together guidelines to ensure interoperability. AT&T has made those guidelines public now and is inviting vendors to conform to them.
It is proprietary only in the sense of having been developed at AT&T. It isn't licensed. AT&T is a customer and, as a customer, has published its wish list for vendors... which is why this is intended to foster development...
You're being a little counterfactual there. We don't know whether the Consent Decree enabled the future. The what if game is hard to play.
I think it is interesting to look back at the telecom industry and see what has happened despite active sheparding by the government:
1) AT&T is shadow of its former self. One of history's most successful research labs is now almost gone.
2) MCI was overrun with debt. Their debt was relieved, and they still have finacial problems.
3) The telephone system is wrought with fraud
4) We still don't have widespread ISDN or fiber on the local loop (check to technology road maps prior to the divestiture, we were supposed to have ISDN to every home by the end of 80s)
From the article: "... For the first two-thirds of the 20th century, AT&T had manned Berlin Wall separating telecommunications and computing, but eventually, these two enormous technology tracks would be unified."
Sadly, this was not AT&T but the U.S. Justice Department which through a series of Consent Decrees required this harsh distinction.
The Consent Decree of 1956 forbid AT&T from engaging in any business other than "common carrier communication services"
Further restrictions appeared in the 1982 agreement.
These restraints were not removed until congress and the FCC asked them to be removed after the passage the 1996 Telecom Act.
The vaulted FreeBSD stability is mostly a matter of conservativism rather than the long history of the OS. Certainly much of FreeBSD was slowly evolved--and I think that applies to the 4.x series, but 5.x contains many aggressive changes to the Kernel. Thus, the history argument does not hold so much water.
Really, though, there are two kinds of stability. The uptime kind (really not that amazing in a UNIX OS, period.) and the system kind. FreeBSD is loved by administrators for its very well enforced POLA (policy of least astonishment). Point releases of the OS almost never break existing setups. E.g., 5.x will use use Bind9 and GCC 3.4 for it's entire existence. Should the originators of those programs neglect them, the FreeBSD project will step in and merge in fixes themselves. That sort of consistency is valued by many in critical applications.
A FreeBSD Kernel is not much different from modern Linux Kernels.
One of the big differences between the BSDs and Linux Distributions, though, is that the different BSD projects tend be distinguished by disagreements over system architecture--major design decisions at the Kernel level. Moreover, BSD projects tend to be focused on providing a complete, integrated system. Userland development and Kernel development always go hand-in-hand.
The author of ULE has been out of touch now for sometime. ULE had known issues at the time it was made default in -current, but it was hoped that visibility would generate the reports necessary to stablize it. Unfortunately, Jeff hasn't seemed to have the time to fix or even examine the issues uncovered.
The recent preemption changes drove ULE from being merely suboptimal (inefficient) in some situations to being unstable.
The FreeBSD model has always been that features and patches are tested in -current and then merged down to -stable and tested some more until it comes time for the next release from -stable.
This tiered approach exists to support three types of users: the developers (-current), sysadmin's test environment, impatient users (-stable), production environments, conservative users (-release).
5.0, 5.1, 5.2.1 were all preview releases--somewhat stabilized snapshpts of -current. 5.3 should be available for general adoption.
Thus, the existance of 6.0 does not reflect a change in developer focus but rather the adoption of conservativism on the 5.x branch (prior testing in -current required before merging) that is in keeping with it becoming a -stable branch from which real -releases are made. You can rest assured that bugs in 5.x will continue to be fixed and tested in 6.0-current and after some verification the fixed will be merged down to 5-Stable.
FreeBSD also maintains a POLA (principle of least astonishment) which prohibits any major behavioral/interface/abi changes from appearing in a -stable branch. (Basically you are nearly certain that an application that runs properly on n.0 will run properly on n.10).
6.0-Current exists as a proving ground for those features which would violate POLA.
Some other posters hinted at this, but to state more clearly.
A possible reading of the law: You are either buying a "disk" in which case it is your property which you are free to dispose of as you wish including examining it and running algorithms on it, and in which case, you are owed nothing when it breaks. "They" have no responsibility for it.
Otherwise you are buying a license to that data in which case, "They" do have a responsibility to ensure that you continue to have access to it--even including medium changes!
I think it would be very interesting for people to examine the RIAA/MPAA actions under the Sale/Licensing anti-trust cases of 50-60 years ago. It's been a while, but I recall that a monopolist cannot compel you to buy or license, but instead must accommodate people who wish to do either.
Re:Upgrading from 5.2.1 to 5.3-BETA1 a little bump
on
FreeBSD 5.3 Beta1
·
· Score: 5, Informative
You should only need to run mergemaster -p before the installworld stage (despite the description of the option in mergemaster). Doing a buildworld should not require any special users or groups.
The official procedure (from/usr/src/UPDATING) is: make buildworld make buildkernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE
"But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface,"
This was the point I was intending to make. Java does make encapsulation too hard and many the benefits of inheritence can be more safely achieved via encapsulation.
I am not arguing that inheritence is useless. Rather, my point is that encapsulation is clearly important and that Java should be faulted for stressing inheritence over encapsulation.
"This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part)."
Yeah, basically it is syntactic sugar.
"If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics."
For a langauge that gets these things "right" take a look at DECs modula-3.
I think my point was that you are mistaken to believe that they can be used in concert. They are two very incompatiable concepts--their objectives conflict.
As regards history, the past 40 years are full of projects that failed because of inadequate encapsulation.
"3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality)."
This is precisely the problem actually: Java's focus on Objects. The trouble with Java is that there are two "big" ideas in languages these days: encapsulation and inheritance. Trouble is that these two ideas are incompatible. It is much more difficult to determine ahead of time which internals to expose in a class that will have descendants (because the code reuse paradigm stops the original designer from knowing how the code will be extended in the future). The result: you end up exposing more than you should and encapsulation goes away. Even when the interface is properly designed creating derived classes still requires that you know the internals of the parent class. Oops, that's not encapsulation either. Java is supposed to give us "code reuse" but it does so only in a very dangerous way that it is unsuitable for any critical application or development cycle.
History (e.g. as expounded by the mythical man month) has shown us the importance of encapsulation and it is on this point that Java fails as a language.
No. It is not about assuming the male. He doubles as the gender neutral (epicene) pronoun--as is the case in many languages.
Unfortunately what has happened is that people started to learn to use he "just because" and so when it lost ground politically few stepped forward to defend it's usage.
It's a sad truth that "he", while grammatically correct and historically non-sexist, is too dated and can no longer be used neutrally thanks to the long campaign of politicizing the language.
"They" and "Their" have a nice history in the singular going back to the 14th century with many occurances in Jane Austin's novels for example.
Yeah, I've been involved in some of the staff discussions at one of the compromised institutions.
The vulnerabilities listed seem old because these attacks have been ongoing for a while now. Some of those vulnerabilities were actually discovered originally in relations to this situation.
What's important to realize is that this situation is very unlike what's happened to windows machines recently. Most of the Windows intrusions have been remote exploits via services.
We've been facing primarily local-root exploits. These people are breaking into accounts--usually by password sniffing, key-stroke logging, etc from other compromised machines.
Those accounts are then used to launch various known (and previously unknown) local-root exploits.
These people appear to be after other systems for an unknown purpose rather than just "games" or DoS attacks.
Most of the targeted institutions have substanial DARPA/government research contracts. It's reasonable that these attacks are being used to steal information.
The focus has not been on High Performance Clusters but rather on interactive clusters. These people are after information not computing power.
Slashdot Mirror
Actually the first Asynchronous Microprocessor (in VLSI) was developed in 1989: The First Asynchronous Microprocessor: The Test Results. A.J. Martin, S.M. Burns, T.K. Lee, D. Borkovic, and P.J. Hazewindus. Computer Architecture News, 17(4), 95-110, June 1989. [CS-TR-89-06] The Design of an Asynchronous Microprocessor. A.J. Martin, S.M. Burns, T.K. Lee, D. Borkovic, and P.J. Hazewindus. ARVLSI: Decennial Caltech Conference on VLSI, ed. C.L. Seitz, 351-373, MIT Press, 1989. [PS | CS-TR-89-02 ]
Allow me to change the other replier's "maybe overvoltage" comment to "absolutely, all it means is that you need to increase the voltage."
0 01.012
More voltage => more heat => same "overclocking" game.
Some numbers (sorry, old from the '90s) for an Asynchronous MIPS R3000
(Vdd, MIPS, power dissipiation (W))
(1.00, 9.66, 0.021)
(1.51, 66, 0.29)
(3.08, 165, 3.4)
(3.30, 177, 4.2)
(3.51, 185, 5.1)
(4.95, 233.6, 13.7)
source: http://resolver.library.caltech.edu/caltechCSTR:2
There are two solutions:
P S/2002_energyde layefficiency.ps.gz
1) get the transistors to switch faster
2) reduce the number of transitions on the critial paths
This is the same for synchronous and asynchronous designs.
1) can be handled using voltage scaling (higher V, faster transitions) or simply with scaling (e.g. going from 180nm to 90nm).
2) This ultimately comes down to hyper-pipelining something which is slightly easier in asynchronous circuits.
references:
http://www.async.caltech.edu/Pubs/
I've never wanted a program that I couldn't run under FreeBSD--seriously!
/usr/compat/linux
Sure, a little 2k widget program you find somewhere coded especially for linux might be hard to compile on FreeBSD... but the solution is to just compile it on a linux machine (or trust a published linux binary). Why? FreeBSD runs linux binaries. It does this by emulating the linux system calls at almost no overhead and installing a set of libraries from Red Hat in
The kernel/loader takes care of the rest. Basically, linux programs tend to just work unless they depend on some special kernel module.
As for native BSD binaries. You have ports (a push-button way to compile it yourself) or packages (a push-button way to have your computer fetch a precompiled binary from the FreeBSD build cluster).
The best part? FreeBSD maintains a vulnerability database for third-part software. Installing a program that depends on a library version with a known vulnerability? make install gives you a heads up warning. Concerned about people hacking into distribution sites and putting trojans into the source and/or source? The FreeBSD team maintains their own database of MD5 which is consulted to verify that the source is the same source that past inspection by the port maintainer.
Okay, but there isn't one best solution. There is that saying "jack of all trades" master of none. The BSDs tend to fork over major kernel architectual differences (rather than eye-candy or userland disagreements), but despite that they share and exchange code extensively. Maybe the linux approach would be okay if Linux really was a god and _knew_ exactly what the "best" solution was but that is the case. He's just a pretty smart guy like Matt Dillon of DragonflyBSD, Robert Watsom of FreeBSD, or Theo of OpenBSD. Smart, informed people can disagree on how to do things. The variation on the BSDs allow those ideas to be realistically tested in practice. So you could just as well make a diversity argument here. No one is betting the entire BSD farm on the one true and holy kernel architecture. Also you make light of switching linux distributions. The BSDs tend to be much more similar in their operation and usage than linux distributions. The differences are under the hood or in the choices for default configuration, not in the man-machine interface. Also, while people are pretty fond of saying OpenBSD for Security, FreeBSD for performance/stability... that sort of belies the complexity. Yeah, FreeBSD tends to have the best performance but it also has a really good security team. Is FreeBSD up to the same auditing level as OpenBSD? No, but it is audited to a very reasonable level.
Thus the interest in asynchronous design.
To plug my own work, check out http://www.async.caltech.edu. We're nearing tape-out on an asynchronous implementation of an 8051.
You almost mention this but while limiting clock distribution is not responsible for a 3 GHz boundary as suggested by the original author. Chip clocks have been pushed much beyond that over very large die areas.
No. Clock distribution is quite complicated. What is required is phase consistency within a skew margin, not that the same clock pulse appear everywhere at the same time. Even in a simple tree distrubution scheme, you just need to ensure that the skew between any two latches with intervening logic is tolerable. This is just another reason to introduce latches (and thus pipelining).
You're also off the mark. It is almost certain that there is no electrical pathway that spans the chip without hitting some logic. The number in 90nm (for best performance) is about 12000\lambda (\lambda = 90nm). Often signals propogate much smaller distances in a cycle. I assure you in one cycle no one is making a signal traverse the entire core. Modern CPUs are highly pipelined which is essentially to say that in one clock cycle data is transfered and processed within a very small section of the chip before being passed on to the next stage. This then frees the stage for the next bit of data. see http://en.wikipedia.org/wiki/Pipelining As a side consequence, what you mention is not the limiting the factor. Signals simply do not need to propogate across the chip in one cycle. What has really happened is the drive current available from each transistor has gotten smaller as the transistor itself has shrunk. The wiring capacitance has remained the same and begun to predominate over the gate capacitence. Thus, making the transistors smaller does not make the circuit faster as it once did. Also, as someone else pointed out, the mobility of electrons in semiconductors is no where near the numbers you quote. Electronics simply don't work the way you claim.
Not to mention that this upcoming release will have ndis support enabled by default... which should allow you to use a binary windows driver to get your card up and running.
In fact, that's why we signed the agreement to have this done almost a decade ago. Contrary to the politically motivated suggestions otherwise, this was _not_ a response to 2000 election. We wanted to place monitors in other countries and got a response back something like, "Why don't you take monitors if you're so keen on this" and we said "sure".
AT&T has been working on this for many years now (they started really investigating VoIP back in '98 as part of their plan to use their (then) vast cable network to offer phone service in competition with the baby bells.)
This is not proprietary in the way you likely think it is. All of their work has been based on open standards (of which there is a confusion! of conflicting open standards). VoIP equipment vendors all tend to implement "something" which is sort of like some published standard but rarely works with other vendors equipment.
AT&T through years of work cobbled together guidelines to ensure interoperability. AT&T has made those guidelines public now and is inviting vendors to conform to them.
It is proprietary only in the sense of having been developed at AT&T. It isn't licensed. AT&T is a customer and, as a customer, has published its wish list for vendors... which is why this is intended to foster development...
You're being a little counterfactual there. We don't know whether the Consent Decree enabled the future. The what if game is hard to play.
I think it is interesting to look back at the telecom industry and see what has happened despite active sheparding by the government:
1) AT&T is shadow of its former self. One of history's most successful research labs is now almost gone.
2) MCI was overrun with debt. Their debt was relieved, and they still have finacial problems.
3) The telephone system is wrought with fraud
4) We still don't have widespread ISDN or fiber on the local loop (check to technology road maps prior to the divestiture, we were supposed to have ISDN to every home by the end of 80s)
From the article: "... For the first two-thirds of the 20th century, AT&T had manned Berlin Wall separating telecommunications and computing, but eventually, these two enormous technology tracks would be unified."
Sadly, this was not AT&T but the U.S. Justice Department which through a series of Consent Decrees required this harsh distinction.
The Consent Decree of 1956 forbid AT&T from engaging in any business other than "common carrier communication services"
Further restrictions appeared in the 1982 agreement.
These restraints were not removed until congress and the FCC asked them to be removed after the passage the 1996 Telecom Act.
The vaulted FreeBSD stability is mostly a matter of conservativism rather than the long history of the OS. Certainly much of FreeBSD was slowly evolved--and I think that applies to the 4.x series, but 5.x contains many aggressive changes to the Kernel. Thus, the history argument does not hold so much water.
Really, though, there are two kinds of stability. The uptime kind (really not that amazing in a UNIX OS, period.) and the system kind. FreeBSD is loved by administrators for its very well enforced POLA (policy of least astonishment). Point releases of the OS almost never break existing setups. E.g., 5.x will use use Bind9 and GCC 3.4 for it's entire existence. Should the originators of those programs neglect them, the FreeBSD project will step in and merge in fixes themselves. That sort of consistency is valued by many in critical applications.
A FreeBSD Kernel is not much different from modern Linux Kernels.
One of the big differences between the BSDs and Linux Distributions, though, is that the different BSD projects tend be distinguished by disagreements over system architecture--major design decisions at the Kernel level. Moreover, BSD projects tend to be focused on providing a complete, integrated system. Userland development and Kernel development always go hand-in-hand.
The author of ULE has been out of touch now for sometime. ULE had known issues at the time it was made default in -current, but it was hoped that visibility would generate the reports necessary to stablize it. Unfortunately, Jeff hasn't seemed to have the time to fix or even examine the issues uncovered.
The recent preemption changes drove ULE from being merely suboptimal (inefficient) in some situations to being unstable.
The FreeBSD model has always been that features and patches are tested in -current and then merged down to -stable and tested some more until it comes time for the next release from -stable.
This tiered approach exists to support three types of users: the developers (-current), sysadmin's test environment, impatient users (-stable), production environments, conservative users (-release).
5.0, 5.1, 5.2.1 were all preview releases--somewhat stabilized snapshpts of -current. 5.3 should be available for general adoption.
Thus, the existance of 6.0 does not reflect a change in developer focus but rather the adoption of conservativism on the 5.x branch (prior testing in -current required before merging) that is in keeping with it becoming a -stable branch from which real -releases are made. You can rest assured that bugs in 5.x will continue to be fixed and tested in 6.0-current and after some verification the fixed will be merged down to 5-Stable.
FreeBSD also maintains a POLA (principle of least astonishment) which prohibits any major behavioral/interface/abi changes from appearing in a -stable branch. (Basically you are nearly certain that an application that runs properly on n.0 will run properly on n.10).
6.0-Current exists as a proving ground for those features which would violate POLA.
Some other posters hinted at this, but to state more clearly.
A possible reading of the law:
You are either buying a "disk" in which case it is your property which you are free to dispose of as you wish including examining it and running algorithms on it, and in which case, you are owed nothing when it breaks. "They" have no responsibility for it.
Otherwise you are buying a license to that data in which case, "They" do have a responsibility to ensure that you continue to have access to it--even including medium changes!
I think it would be very interesting for people to examine the RIAA/MPAA actions under the Sale/Licensing anti-trust cases of 50-60 years ago. It's been a while, but I recall that a monopolist cannot compel you to buy or license, but instead must accommodate people who wish to do either.
You should only need to run mergemaster -p before the installworld stage (despite the description of the option in mergemaster). Doing a buildworld should not require any special users or groups.
/usr/src/UPDATING) is:
The official procedure (from
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
mergemaster -p
make installworld
mergemaster
"But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface," This was the point I was intending to make. Java does make encapsulation too hard and many the benefits of inheritence can be more safely achieved via encapsulation. I am not arguing that inheritence is useless. Rather, my point is that encapsulation is clearly important and that Java should be faulted for stressing inheritence over encapsulation. "This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part)." Yeah, basically it is syntactic sugar. "If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics." For a langauge that gets these things "right" take a look at DECs modula-3.
I think my point was that you are mistaken to believe that they can be used in concert. They are two very incompatiable concepts--their objectives conflict. As regards history, the past 40 years are full of projects that failed because of inadequate encapsulation.
"3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality)."
This is precisely the problem actually: Java's focus on Objects. The trouble with Java is that there are two "big" ideas in languages these days: encapsulation and inheritance. Trouble is that these two ideas are incompatible. It is much more difficult to determine ahead of time which internals to expose in a class that will have descendants (because the code reuse paradigm stops the original designer from knowing how the code will be extended in the future). The result: you end up exposing more than you should and encapsulation goes away. Even when the interface is properly designed creating derived classes still requires that you know the internals of the parent class. Oops, that's not encapsulation either. Java is supposed to give us "code reuse" but it does so only in a very dangerous way that it is unsuitable for any critical application or development cycle.
History (e.g. as expounded by the mythical man month) has shown us the importance of encapsulation and it is on this point that Java fails as a language.
No. It is not about assuming the male. He doubles as the gender neutral (epicene) pronoun--as is the case in many languages.
Unfortunately what has happened is that people started to learn to use he "just because" and so when it lost ground politically few stepped forward to defend it's usage.
It's a sad truth that "he", while grammatically correct and historically non-sexist, is too dated and can no longer be used neutrally thanks to the long campaign of politicizing the language.
"They" and "Their" have a nice history in the singular going back to the 14th century with many occurances in Jane Austin's novels for example.
The biblical codenames correspond to those chips coming from Intel's Engineering Facility in Israel.
Yeah, I've been involved in some of the staff discussions at one of the compromised institutions. The vulnerabilities listed seem old because these attacks have been ongoing for a while now. Some of those vulnerabilities were actually discovered originally in relations to this situation. What's important to realize is that this situation is very unlike what's happened to windows machines recently. Most of the Windows intrusions have been remote exploits via services. We've been facing primarily local-root exploits. These people are breaking into accounts--usually by password sniffing, key-stroke logging, etc from other compromised machines. Those accounts are then used to launch various known (and previously unknown) local-root exploits. These people appear to be after other systems for an unknown purpose rather than just "games" or DoS attacks. Most of the targeted institutions have substanial DARPA/government research contracts. It's reasonable that these attacks are being used to steal information. The focus has not been on High Performance Clusters but rather on interactive clusters. These people are after information not computing power.