All the Microsoft patents that have been identified as relating to C#/CLR so far are irrelevant. For example, the patent you reference has no bearing on the Mono project; if it applies to anything, it applies as much to Java and C++ programs.
Sun's patents, if anything, look much more worrisome. For example, patent 6,477,702 patents the basic Java bytecode architecture and can be used by Sun to shut down any competing implementation. Furthermore, despite lots of cheery announcements, there is no indication that Sun has made a legally binding commitment to license this patent freely for open source implementations, let alone competing commercial implementations. The way it looks to me is that Sun is just stringing the community along with promises, and they will change their tune when they feel that they have established a secure enough market position. Sun has broken lots of Java-related promises; they are not to be trusted either.
In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA
There are so many things wrong with that that it's hard to know where to begin:
A bunch of web pages do not constitute a legally binding contract.
It is rather unclear what exactly the extent is to which these promises would open up Java.
For an open language standard, it is insufficient only to open up the standard to open source implementations.
Sun has renegged on several previous promises regarding Java: they failed to go through with standardization, twice, and they failed to deliver lots of functionality that they promised (e.g., value classes).
If Sun wanted to open up Java, they would go through a standardization process, identify all the relevant patents in question, and make a legally binding commitment as part of the standards process. Instead, we are just getting fuzzy promises while Sun keeps filing Java-related patents.
As far as I'm concerned, both Sun and Microsoft are greedy and untrustworthy, and the open source community would be foolish to throw their lot in with either company.
"Servers" don't run as CGI scripts, dynamic web applications do.
In any case, do you have data to back up your claim that "most" do not use CGI? I would actually bet that CGI is still by far the most widely used server side scripting approach when you look at number of distinct installations. Of course, high-volume sites like AOL or Yahoo!, etc., have some incentive to use non-CGI interfaces, but they are the exception.
CGI scripts aren't even a scalable way to do web programming under Unix,
My Linux machine easily manages 200 CGI script invocations per second without even breaking into a sweat; what fraction of installed web servers do you think needs to handle 200 hits per second to dynamically generated web pages? Tiny, I would guess. Furthermore, the overhead of starting a CGI script is actually negligible compared to the operations that most CGI scripts actually do.
much less media streaming
The primary overhead of command line programs vs. plug-ins is that the command line programs involve forks to start up. That's a complete non-issue for streaming. Therefore, if anything, multimedia processing is better, not worse, for a UNIX approach.
Also, I'm sure the folks at MPlayer and other Unix-native desktop video software were unaware that they had been corrupted by Windows methodologies.
They have been: most of the UNIX/Linux players use skinning, which means they don't behave properly as desktop applications, they are flaky, they are hard to install, and the video code they contain is almost completely non-reusable for other purposes. In short, they are designed and work just like their Windows counterparts.
What we really need is the equivalent of NetPBM for video. Transcode tries, but it's still ways off from being as clean and simple.
Just about every interesting CGI script on the web these days talks to "huge, monolothic" database server - think PHP.
Some do, some don't. And database servers are also way overused anyway, for pretty much the same reasons that people build monolithic programs: they have grown up on cumbersome platforms like Windows or mainframes, where they don't have a choice.
Small command-line tools are appropriate for hacking together text processing filters, but I can't see them being useful for building a multimedia pipeline.
Well, from personal experience, I can tell you: they work very well.
If you care about synchronization, then you need in-process and/or shared memory communication, not a unix pipe.
No, you don't. Even if you demultiplex and multiplex streams as part of the processing pipeline, pipes take care of the synchronization automatically. That's part of their power.
Of course, nobody is stopping you to use shared memory for communications among command line tools. But it's a lot harder to get the synchronization right with shared memory, so I wouldn't recommend it unless you really need to eliminate the (comparatively small) overhead of the read/write operations.
Your comment is pretty typical and it illustrates again how muddled the thinking of many multimedia developers actually is.
I really don't think it would be possible to put together a compelling end-user multimedia application with what you dub the "UNIX/Linux" approach (literally using small command line programs). Could you point to a successful end-user multimedia application that does?
We are talking about servers here, not end-user applications. On the server side, the UNIX approach has been highly successful: CGI scripts are very widely used.
The approach would work fine for desktop and viewer software as well; the reason it isn't used as much there is simply that that market is dominated by Microsoft software, Microsoft programmers, and Microsoft development tools. And on Microsoft platforms, huge, monolithic, single-program approaches are just a historical bad habit: the platform really didn't use to support anything else. The sooner people get over it even on Windows, the better for everybody.
What technical reason do you believe exists that you couldn't take a UNIX approach (small command line tools) to building these kinds of applications?
I think the design of software like Helix DNA is just driven by bad habits originating on the Windows platform.
If you look at the capabilities of Helix DNA, they would be much better provided by a set of small, specific command line programs, filters, network tools, and CGI programs. It would be much easier to reuse those tools for other purposes, to create new plug-ins, etc.
Instead, what we seem to be getting (but it's hard to tell because there is almost no documentation on the site), is some big, monolithic program with "plug-ins", which probably ends up being hard to extend, hard to modify, and hard to reuse.
People should really kick the cross-platform habit. The UNIX/Linux approach to building large software systems and servers out of small command line programs is better than the Windows approach. Having junk designed for Windows ported to Linux is not the right approach and fails to take advantage of the strenghts of the Linux platform.
The primary (sole?) reason someone needs IP-layer anonymity is so that they can launch attacks without getting caught.
I am guaranteed anonymity at the HTTP layer only if I know that I am anonymous at all the lower level protocols.
Why is everyone working so hard to protect this?
Because if the infrastructure is put in place to track people at the IP layer, there is no anonymity at all anymore.
Worse, it creates entirely new opportunities for identity theft: as long as identity isn't intended to be guaranteed at the IP level, nobody relies on it. As soon as there is the slighted indication that identiy at the IP level is "legally guaranteed", companies will use that as an excuse for using it for "easier" authentication schemes, placing everybody at risk. And that's just one of many potential abuses.
The notion that the "extreme" viewpoints on an issue are "biased" and that there is a supposedly "reasonable, moderate middle ground" has destroyed many political debates in this country. The reason is that it makes it advantageous for one side to make their claims more strongly so that the middle ground moves their way, and then the other side reacts. And in the process, the real issues get lost: at the end, people will pick a simplistic but ineffective "compromise", everybody pats themselves on the back about how "fair" they have been, it will get implemented, and nothing will change.
And what are your goals and what kind of data are you looking for anyway? The answers aren't going to be as simple as "strengthen gun control, reduce violence". Strengthening gun control in the US without doing anything else will probably not reduce violence; neither will increasing gun availability result in increased safety or increased political stability. Violence is a very deep rooted problem in American society, it is out of control compared to other western nations, and addressing it will require much more effort than a single quick-fix approach.
And when it comes down to it, people's needs differ: a wealthy resident of a town where violence is less of a problem may have the luxury of having grandiose notions of the constitutional role of gun ownership, while someone living in the slums of a major city may have more immediate concerns.
So, the answer to your request for an "unbiased analysis of gun control" is that you are asking the wrong question. You are looking for quick fixes and simple answers for problems that don't have simple solutions. Gun control won't make people's lives safer in the US--that will take profound social changes. However the willingness to accept gun control in the US would be an indication that the society has become safer, less violent, and less polarized. I think we are still decades away from that.
No, you don't. AOL sells by-the-minute plans for cash, at your local computer store.
2. You have to dial up to AOL through a land-line. AOL has caller ID.
We have these wonderful things called "pay phones". Some of them helpfully provide modem connections, others work with acoustic couplers.
What do you gain out of having anonymous IP that you can't have with anonymous HTTP? Why does everyone insist on having this anonymity at the IP layer and not the application layer?
Many attacks are easier to launch through IP than through HTTP.
Of course, as far as I'm concerned, it's a tempest in a teapot. If large chunks of the Internet goes down for a few hours, we can deal with it. If we can't, we should take steps so that we can.
So, where is the trending data over a few thousand years saying that man and his theorized greenhouse gases are heating things up?
It is debatable to what degree the current, measurable increases in global temperatures are due to human emissions of greenhouse gasses.
It is absolutely not debatable that human emissions of greenhouse gasses will lead to serious and costly problems sooner or later--that is just basic physics.
Yo, Slashdot editors, please loose the P.C. Crap.
When you don't like or understand the scientific realities, you just accuse people of political bias. Sadly, that's how a lot of political decision making happens in the US today.
News flash: Global warming itself is still theory. [...] it has never been proven that human activity of any form did cause, (or could stop) the climate change everyone seems so keen to label global warming.
Even if that were true, it would be irrelevant. CO2 emissions do cause increases in average global temperature; that is elementary physics. The only question is the degree and when those increases will lead to catastrophes. But increases and catastrophes will inevitably result sooner or later if emissions continue at current levels or grow.
But it would be just as irresponsible for us to run in and fix something we don't understand (and may well not be 'broken') as it would to wontonly destroy our atmosphere (which is what some are claiming we do).
Quite to the contrary: the only responsible thing to do is to greatly reduce our dependence on fossil fuels. Not only does that address issues of global warming as best we can, in developed nations like ours, it is also good for the economy, for defense, and for quality of life.
The only groups who don't benefit are entrenched interests afraid of change.
In fact, it was completely irresponsible to start such massive changes on a global scale in the first place, initiated by what amounts to a very small group of people, with no oversight and no democratic input from most of the affected populations.
Let's just not become couriers of FUD in the process.
Given the global and irreversible nature of these changes, fear, uncertainty, and doubt are completely justified.
What I find particularly ironic about the bogus arguments you are repeating is that they often come from the same people that formulate our drug policy on tenuous or disreputable scientific evidence. Apparently, it's not OK for me to voluntary inhale or ingest substances that only affect me and have never been demonstrated to be harmful. But it's perfectly OK for big companies to emit substances that I can't escape from and that the scientific mainstream pretty much agrees are going to have deleterious effects on people and the world.
Of course, it's a tool, in the same sense that algebra and calculus are tools.
I suppose C is evil because it abstracts memory handling in a common way to make it so more developers can understand.
C was just a tool that some people developed and others picked up; it wasn't generally hyped up as a solution to software engineering problems.
Perhaps if UML had been used in the first place, the developer who originally wrote the code could make a quick visual survey of the coupling and cohesion in the system and eliminate those side-effects (nuances by another name).
I suppose stranger things have happened, although I frankly can't think of any.
It's all about abstraction, and in the case of the UML, it's about having a common visual abstraction so that developers can share ideas and discuss (visually) the design of software.
That's the problem with UML: you can draw bubbles and boxes all you like, unless you actually express those abstractions as code, they are useless. And when you do, you don't need UML anymore.
It's "evil" because it promises salvation from software hell to desparate programmers but doesn't deliver. Selling stuff to desparate people isn't nice as far as I'm concerned.
To call UML evil is like calling gcc or gdb evil - as they are all just tools.
Some tools are good tools, some tools are bad tools, and some tools are bad tools that way overpromise.
UML achieves its intended purpose: to give programmers a rapid, easy-to-understand way of communicating the structure of an object-oriented program graphically.
And that's evil.
Why? For several reasons. First, it lets programmers go and hack around in the code with only a superficial, bird's-eye view of the code; they understand roughly where they need to fix things, but they haven't yet absorbed all the intricacies of the code. Second, the program source text is the only thing that ultimately matters to the compiler and to other program analysis tools, but by off-loading documentation and structuring into graphical tools, the source text becomes second class. That would be OK if UML were a fully graphical programming environment, but it isn't. The way it is, round-trip UML is like hacking in GNU C++ assembly language output and corresponding C++ source code at the same time. Finally, UML encourages far too complex and general object-oriented designs, rather than focussing on solving a specific problem with a specific piece of code.
The site is a hoax, but the laser is real and could have been developed using Victorian techniques.
Here is a modern description. You can put one together for a few dollars. It delivers nanosecond pulses of UV laser light that you can use to excite dye lasers and do other neat stuff with.
Secure, efficient, and easy C programming is no problem--if you use C++ but program it in a C style.
Many C++ programs and class libraries suffer from Smalltalk-envy. They want to be completely general frameworks, solving any possible future problem you might ever encounter. You find madness, bloat, and slipped deadlines if you go down that path.
But if you stick to the standard C library (which is part of C++) and approach C++ like you would C, you can write programs that work with C-like efficiency yet are considerably easier to make safe and secure.
For example, instead of the bloated and hard to debug STL, just define a 15 line template array class that does array bounds checking and deallocates its pointer when it's done.
Wrong -- it proves that it does work. None of those 100K books were cracked PDFs.
That's not what I get from the article, since it says that those books may have been cracked using other methods.
In any case, either way, it doesn't matter, since there are plenty of PDF readers that will just display "encrypted" PDFs for you without even the bother of cracking them. If you like, you can print to a file and re-encode to PS from those.
The main reason is that MSVC++ produces much smaller (and faster) code than g++ does.
I very seriously doubt that. At best, MSVC++ may produce slightly smaller or slightly faster code for some programs and not for others, and if my previous experience with it is any guide, at the cost of slight incompatibilities. Even you yourself claim only a 15% improvement. Note that optimization with gcc doesn't end with giving it a "-O2"; if you want better optimization, you need to tune the "-f" flags.
Moving to gcc 3.2 (once the Sun people get off their friggin' asses and compile Java with it)
That's the problem with relying on a proprietary piece of software like Java. Phoenix should simply upgrade to gcc 3.2--to hell with Sun Java.
But once you have anonymous connectivity, there's nothing stopping you from hacking into a few hundred hosts (maybe using a script) and setting up DDoS zombies on all of them. You can now use your anonymous connection to initiate a more severe attack without fear of getting caught.
Yup, and there are plenty of places that are selling anonymous connectivity, both in the US and overseas. AOL, for example.
Besides, there are plenty of ways in which terrorists can get other people's credit card numbers.
Secondly, an open Wi-Fi network is a perfect place to release a destructive virus or worm. You don't need a lot of bandwidth to do this.
No more or less perfect than any other Internet connection.
We know that (an attack) could bring down the network of this country very quickly.
If someone breaking into a bunch of 802.11b networks (at 10Mbps) can bring down the network of this country, the US portion of the Internet is flakier than I thought and we really have bigger problems than this.
In any case, people cut through major cables, there are earthquakes, there are software glitches, etc. Major chunks of the US Internet will go down, even without terrorists, sooner or later, just like major chunks of the telephone network have gone down from time to time. People better be prepared for that; it just shouldn't be a serious matter.
Rather, the report simply notes that these high-energy plasmas are created only with the company's catalysts.
If the composition of those "catalysts" remains proprietary, then the work is effectively not independently reproducible and should not get published in any journal. Saying "buy this magic powder from company X and it will do something spectacular" just isn't acceptable.
Not only does the lab coat look funny, it shows he can't be a real scientist. Real scientists wear WHITE lab coats, this guy is wearing a BLUE lab coat. I think blue coats are for sanitation workers.
Slashdot Mirror
Sun's patents, if anything, look much more worrisome. For example, patent 6,477,702 patents the basic Java bytecode architecture and can be used by Sun to shut down any competing implementation. Furthermore, despite lots of cheery announcements, there is no indication that Sun has made a legally binding commitment to license this patent freely for open source implementations, let alone competing commercial implementations. The way it looks to me is that Sun is just stringing the community along with promises, and they will change their tune when they feel that they have established a secure enough market position. Sun has broken lots of Java-related promises; they are not to be trusted either.
There are so many things wrong with that that it's hard to know where to begin:
Sun has renegged on several previous promises regarding Java: they failed to go through with standardization, twice, and they failed to deliver lots of functionality that they promised (e.g., value classes).
If Sun wanted to open up Java, they would go through a standardization process, identify all the relevant patents in question, and make a legally binding commitment as part of the standards process. Instead, we are just getting fuzzy promises while Sun keeps filing Java-related patents.
As far as I'm concerned, both Sun and Microsoft are greedy and untrustworthy, and the open source community would be foolish to throw their lot in with either company.
J2EE is a mess. Whether .NET matches up with it or not doesn't matter.
"Servers" don't run as CGI scripts, dynamic web applications do.
In any case, do you have data to back up your claim that "most" do not use CGI? I would actually bet that CGI is still by far the most widely used server side scripting approach when you look at number of distinct installations. Of course, high-volume sites like AOL or Yahoo!, etc., have some incentive to use non-CGI interfaces, but they are the exception.
CGI scripts aren't even a scalable way to do web programming under Unix,
My Linux machine easily manages 200 CGI script invocations per second without even breaking into a sweat; what fraction of installed web servers do you think needs to handle 200 hits per second to dynamically generated web pages? Tiny, I would guess. Furthermore, the overhead of starting a CGI script is actually negligible compared to the operations that most CGI scripts actually do.
much less media streaming
The primary overhead of command line programs vs. plug-ins is that the command line programs involve forks to start up. That's a complete non-issue for streaming. Therefore, if anything, multimedia processing is better, not worse, for a UNIX approach.
Also, I'm sure the folks at MPlayer and other Unix-native desktop video software were unaware that they had been corrupted by Windows methodologies.
They have been: most of the UNIX/Linux players use skinning, which means they don't behave properly as desktop applications, they are flaky, they are hard to install, and the video code they contain is almost completely non-reusable for other purposes. In short, they are designed and work just like their Windows counterparts.
What we really need is the equivalent of NetPBM for video. Transcode tries, but it's still ways off from being as clean and simple.
Some do, some don't. And database servers are also way overused anyway, for pretty much the same reasons that people build monolithic programs: they have grown up on cumbersome platforms like Windows or mainframes, where they don't have a choice.
Small command-line tools are appropriate for hacking together text processing filters, but I can't see them being useful for building a multimedia pipeline.
Well, from personal experience, I can tell you: they work very well.
If you care about synchronization, then you need in-process and/or shared memory communication, not a unix pipe.
No, you don't. Even if you demultiplex and multiplex streams as part of the processing pipeline, pipes take care of the synchronization automatically. That's part of their power.
Of course, nobody is stopping you to use shared memory for communications among command line tools. But it's a lot harder to get the synchronization right with shared memory, so I wouldn't recommend it unless you really need to eliminate the (comparatively small) overhead of the read/write operations.
Your comment is pretty typical and it illustrates again how muddled the thinking of many multimedia developers actually is.
We are talking about servers here, not end-user applications. On the server side, the UNIX approach has been highly successful: CGI scripts are very widely used.
The approach would work fine for desktop and viewer software as well; the reason it isn't used as much there is simply that that market is dominated by Microsoft software, Microsoft programmers, and Microsoft development tools. And on Microsoft platforms, huge, monolithic, single-program approaches are just a historical bad habit: the platform really didn't use to support anything else. The sooner people get over it even on Windows, the better for everybody.
What technical reason do you believe exists that you couldn't take a UNIX approach (small command line tools) to building these kinds of applications?
If you look at the capabilities of Helix DNA, they would be much better provided by a set of small, specific command line programs, filters, network tools, and CGI programs. It would be much easier to reuse those tools for other purposes, to create new plug-ins, etc.
Instead, what we seem to be getting (but it's hard to tell because there is almost no documentation on the site), is some big, monolithic program with "plug-ins", which probably ends up being hard to extend, hard to modify, and hard to reuse.
People should really kick the cross-platform habit. The UNIX/Linux approach to building large software systems and servers out of small command line programs is better than the Windows approach. Having junk designed for Windows ported to Linux is not the right approach and fails to take advantage of the strenghts of the Linux platform.
I am guaranteed anonymity at the HTTP layer only if I know that I am anonymous at all the lower level protocols.
Why is everyone working so hard to protect this?
Because if the infrastructure is put in place to track people at the IP layer, there is no anonymity at all anymore.
Worse, it creates entirely new opportunities for identity theft: as long as identity isn't intended to be guaranteed at the IP level, nobody relies on it. As soon as there is the slighted indication that identiy at the IP level is "legally guaranteed", companies will use that as an excuse for using it for "easier" authentication schemes, placing everybody at risk. And that's just one of many potential abuses.
And what are your goals and what kind of data are you looking for anyway? The answers aren't going to be as simple as "strengthen gun control, reduce violence". Strengthening gun control in the US without doing anything else will probably not reduce violence; neither will increasing gun availability result in increased safety or increased political stability. Violence is a very deep rooted problem in American society, it is out of control compared to other western nations, and addressing it will require much more effort than a single quick-fix approach.
And when it comes down to it, people's needs differ: a wealthy resident of a town where violence is less of a problem may have the luxury of having grandiose notions of the constitutional role of gun ownership, while someone living in the slums of a major city may have more immediate concerns.
So, the answer to your request for an "unbiased analysis of gun control" is that you are asking the wrong question. You are looking for quick fixes and simple answers for problems that don't have simple solutions. Gun control won't make people's lives safer in the US--that will take profound social changes. However the willingness to accept gun control in the US would be an indication that the society has become safer, less violent, and less polarized. I think we are still decades away from that.
No, you don't. AOL sells by-the-minute plans for cash, at your local computer store.
2. You have to dial up to AOL through a land-line. AOL has caller ID.
We have these wonderful things called "pay phones". Some of them helpfully provide modem connections, others work with acoustic couplers.
What do you gain out of having anonymous IP that you can't have with anonymous HTTP? Why does everyone insist on having this anonymity at the IP layer and not the application layer?
Many attacks are easier to launch through IP than through HTTP.
Of course, as far as I'm concerned, it's a tempest in a teapot. If large chunks of the Internet goes down for a few hours, we can deal with it. If we can't, we should take steps so that we can.
It is debatable to what degree the current, measurable increases in global temperatures are due to human emissions of greenhouse gasses.
It is absolutely not debatable that human emissions of greenhouse gasses will lead to serious and costly problems sooner or later--that is just basic physics.
Yo, Slashdot editors, please loose the P.C. Crap.
When you don't like or understand the scientific realities, you just accuse people of political bias. Sadly, that's how a lot of political decision making happens in the US today.
Even if that were true, it would be irrelevant. CO2 emissions do cause increases in average global temperature; that is elementary physics. The only question is the degree and when those increases will lead to catastrophes. But increases and catastrophes will inevitably result sooner or later if emissions continue at current levels or grow.
But it would be just as irresponsible for us to run in and fix something we don't understand (and may well not be 'broken') as it would to wontonly destroy our atmosphere (which is what some are claiming we do).
Quite to the contrary: the only responsible thing to do is to greatly reduce our dependence on fossil fuels. Not only does that address issues of global warming as best we can, in developed nations like ours, it is also good for the economy, for defense, and for quality of life. The only groups who don't benefit are entrenched interests afraid of change.
In fact, it was completely irresponsible to start such massive changes on a global scale in the first place, initiated by what amounts to a very small group of people, with no oversight and no democratic input from most of the affected populations.
Let's just not become couriers of FUD in the process.
Given the global and irreversible nature of these changes, fear, uncertainty, and doubt are completely justified.
What I find particularly ironic about the bogus arguments you are repeating is that they often come from the same people that formulate our drug policy on tenuous or disreputable scientific evidence. Apparently, it's not OK for me to voluntary inhale or ingest substances that only affect me and have never been demonstrated to be harmful. But it's perfectly OK for big companies to emit substances that I can't escape from and that the scientific mainstream pretty much agrees are going to have deleterious effects on people and the world.
Of course, it's a tool, in the same sense that algebra and calculus are tools.
I suppose C is evil because it abstracts memory handling in a common way to make it so more developers can understand.
C was just a tool that some people developed and others picked up; it wasn't generally hyped up as a solution to software engineering problems.
Perhaps if UML had been used in the first place, the developer who originally wrote the code could make a quick visual survey of the coupling and cohesion in the system and eliminate those side-effects (nuances by another name).
I suppose stranger things have happened, although I frankly can't think of any.
It's all about abstraction, and in the case of the UML, it's about having a common visual abstraction so that developers can share ideas and discuss (visually) the design of software.
That's the problem with UML: you can draw bubbles and boxes all you like, unless you actually express those abstractions as code, they are useless. And when you do, you don't need UML anymore.
It's "evil" because it promises salvation from software hell to desparate programmers but doesn't deliver. Selling stuff to desparate people isn't nice as far as I'm concerned.
To call UML evil is like calling gcc or gdb evil - as they are all just tools.
Some tools are good tools, some tools are bad tools, and some tools are bad tools that way overpromise.
And that's evil.
Why? For several reasons. First, it lets programmers go and hack around in the code with only a superficial, bird's-eye view of the code; they understand roughly where they need to fix things, but they haven't yet absorbed all the intricacies of the code. Second, the program source text is the only thing that ultimately matters to the compiler and to other program analysis tools, but by off-loading documentation and structuring into graphical tools, the source text becomes second class. That would be OK if UML were a fully graphical programming environment, but it isn't. The way it is, round-trip UML is like hacking in GNU C++ assembly language output and corresponding C++ source code at the same time. Finally, UML encourages far too complex and general object-oriented designs, rather than focussing on solving a specific problem with a specific piece of code.
There are several open source and/or free UML diagramming tools. Look on Freshmeat. Why you would want to any of them, however, is beyond me.
Here is a modern description. You can put one together for a few dollars. It delivers nanosecond pulses of UV laser light that you can use to excite dye lasers and do other neat stuff with.
Many C++ programs and class libraries suffer from Smalltalk-envy. They want to be completely general frameworks, solving any possible future problem you might ever encounter. You find madness, bloat, and slipped deadlines if you go down that path.
But if you stick to the standard C library (which is part of C++) and approach C++ like you would C, you can write programs that work with C-like efficiency yet are considerably easier to make safe and secure.
For example, instead of the bloated and hard to debug STL, just define a 15 line template array class that does array bounds checking and deallocates its pointer when it's done.
That's not what I get from the article, since it says that those books may have been cracked using other methods.
In any case, either way, it doesn't matter, since there are plenty of PDF readers that will just display "encrypted" PDFs for you without even the bother of cracking them. If you like, you can print to a file and re-encode to PS from those.
So, Adobe's ebook technology is broken, period.
I very seriously doubt that. At best, MSVC++ may produce slightly smaller or slightly faster code for some programs and not for others, and if my previous experience with it is any guide, at the cost of slight incompatibilities. Even you yourself claim only a 15% improvement. Note that optimization with gcc doesn't end with giving it a "-O2"; if you want better optimization, you need to tune the "-f" flags.
Moving to gcc 3.2 (once the Sun people get off their friggin' asses and compile Java with it)
That's the problem with relying on a proprietary piece of software like Java. Phoenix should simply upgrade to gcc 3.2--to hell with Sun Java.
Yup, and there are plenty of places that are selling anonymous connectivity, both in the US and overseas. AOL, for example.
Besides, there are plenty of ways in which terrorists can get other people's credit card numbers.
Secondly, an open Wi-Fi network is a perfect place to release a destructive virus or worm. You don't need a lot of bandwidth to do this.
No more or less perfect than any other Internet connection.
If someone breaking into a bunch of 802.11b networks (at 10Mbps) can bring down the network of this country, the US portion of the Internet is flakier than I thought and we really have bigger problems than this.
In any case, people cut through major cables, there are earthquakes, there are software glitches, etc. Major chunks of the US Internet will go down, even without terrorists, sooner or later, just like major chunks of the telephone network have gone down from time to time. People better be prepared for that; it just shouldn't be a serious matter.
Phoenix is a nice browser. But it's still an 8.9M download for Linux. Does XUL really have that much overhead? How far can this be squeezed down?
If the composition of those "catalysts" remains proprietary, then the work is effectively not independently reproducible and should not get published in any journal. Saying "buy this magic powder from company X and it will do something spectacular" just isn't acceptable.
Not only does the lab coat look funny, it shows he can't be a real scientist. Real scientists wear WHITE lab coats, this guy is wearing a BLUE lab coat. I think blue coats are for sanitation workers.