Its really disturbing to see so many people getting +5, insightful moderation for posts that really don't address the fundamentals of global warming at all.
The basic theory from physics is that as CO2 levels rise, the atmosphere stays transparent to the visual radiation from the sun, while it becomes more opaque to the appx 300K black body radiation from the earth itself. You can understand this basic principle very simply from very well known physical facts. We know what the absorbtion spectra is of the major components of the atmosphere (N2, O2, CO2) and theoretically since CO2 is a more complex molecule than N2 or O2 it has many more vibrational and oscillatory modes in the infrared where it aborbs more radiation. More CO2 in the atmosphere means more opacity of the atmosphere to infrared radiation, which means a hotter Earth.
I will grant that this is theoretical, but its really the only good information that we have to go on. You can argue about little ice ages and natural climate cycles and plants consuming more CO2, but there is one simple fact that we are very sure of, which is that if we release enough CO2 into the atmosphere we'll wind up looking like venus (800K in the shade). In the absence of any really convincing proof that we're not doing any harm to the environment, I'm personally going to assume that we have to take the cautious approach and try to reduce greenhouse gases. The costs if we're wrong and global warming really isn't a problem are that we might slow down the economy a bit. The costs if we continue on our present course and global warming turns out to be a real problem could be devastating. I think its very obvious on which side we should bet our future.
No, they assumed, naturally, that it meant the established meaning of the wording that he copied.
What's amusing is that the OSS license most closely resembling the IPF license is the BSD license which states:
"Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [..etc...]"
In the context of the BSD license it seems clear that his deliberately leaving out the clause pertaining to modification of source code was meant to prohibit that right.
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license, and that therefore do not apply to the distributions before those restrictions were added (this is perfectly valid as it applies to the software distributed with the new releases, of course).
Unfortunately, under copyright law all rights which are not specified revert to the holder of the copyright. He doens't have to give an itemized list of all the ways using his software is prohibited. All he is required to do is to grant your privaleges. Anything else is prohibited. So the fact that the restriction was not originally stated does not change anything. Since it was originally allowed it was prohibited. It always existed there in a legal sense.
Go ahead and talk to a laywer if you don't believe me. This is Copyright Law 101.
especially when a clarification like this reveals restrictions that weren't explicitly mentioned previously, but are assumed to apply retroactively.
*sigh*
The fact here is that nothing is "being assumed to apply retroactively." Under copyright law generally "all other rights are reserved." I'm quite sure that you've seen that phrase used over and over and over. It does, in fact, impart a specific legal meaning. And even if a copyright license does not expressly state that phrase, it is implied.
Now, nowhere in the license did Darren Reed ever grant the right for others to modify his software. That means that you did not have that right and never had that right. There is nothing "retroactive" about it.
To further illustrate, lets look at the BSD license:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
[...etc...]
The BSD license looks oddly similar to Darren Reed's IPF license except that it explicitly grants you the right to redistribute the source and binary code with modification. Since it explicitly gives you that right, you have that right and it is not reserved. On the other hand, had that phrase been left out of the BSD license then you would not have been granted that right. Since Darren Reed left that off of IPFs license, you do not have that right. There is no "but it looks like a BSD license, he's trying to fool me!" defense in copyright law.
All that Darren Reed has done with this action is that he's obviously gotten fed up with people confusing his license with the BSD license and decided to clarify it so that he doesn't have to deal with the headaches. He could have left the clarification off and you still wouldn't have the right to modify his software. The clarification does not legally change his license at all.
I know that as time goes by Linux's performance in this area will overtake and suprass that of HP-UX.
And how is it that you "know" this. My own opinion on the matter is that Linux is playing catch up and will still be playing catch up after HP-UX and other major unix vendors have moved on.
Also, as to FreeBSD, I've found the -stable branch to be much more stable than the supposedly "stable" branch of Linux. I've had filesystem corruption problems on running filesystems (and totally swapping hardware did not help) in 2.2 kernels as late as 2.2.14. I'm still not going to trust 2.4 in production systems until around 2.4.10. The Linux kernel coding community just doesn't seem to adhere to particularly strong standards of "stability."
I also hate the binary distribution method. There are problems that I run into with the ports tree in FreeBSD from time-to-time, but they don't compare with the glibc-du-jour headache that I get with linux (very similar to the Windoze DLL versioning problems that contribute to the instability of that O/S). Recompiling RPMs is always an "option" but since less attention is paid to people recompiling RPMs this option seems to have much more trouble than the FBSD ports tree when you have a differently configured system than the person who built the RPM.
IDE RAID is silly. For one thing, you need to turn off the write buffering for the IDE drive or you can corrupt data if your power fails. Do the right thing and use SCSI.
stream numbers seem to correlate tightly with my application performance.
That's why the P4 and RDRAM is better for you. Sequential memory bandwidth is the one thing that the P4 is really good at. OTOH, if you had a more cache intensive application that gained benefit from the K7's larger L1 cache, the P4 would suck pretty hard. In reality, for most applications the P4's cache is puny, you've got a specialized application where the its ability to stream from memory benefits you.
Lets ignore for the moment that this is really just a plea to continue mass media's grip on our information sources. Lets ignore the fact that substantially different viewpoints such as some of mine (socialism, drug legalization, etc) would almost never be presented as "must run" articles for popular sites. Lets also ignore the fact that I don't think that balkanization of concepts is necessarily bad -- it may instead lead to people needing to tolerate other people's viewpoints out of a necessity of having to work with people who don't share your viewpoint.
But the really important fact here, is that people usually don't like to completely limit their information sources. Who hasn't taken some guilty pleasure in dialing the radio into some talk show (be it Limbaugh or NPR) that you vehemently disagree with and yelling your responses back at the host, letting them get lost in the traffic noise? And who hasn't read the alternative viewpoints on slashdot that seem to regularly get moderated up by having four idiots think it deserves a +1, insightful just for disagreeing with the majority? And lots of people go looking for forums to start arguments with people who disagree with them vehemently. I know that in my early 20s I spent a *lot* of time on Usenet getting into arguments with people whose viewpoints I did not share. I think the only problem with the internet right now is that its hard to find forums that have substantial content -- there's too many trolls, too many Natalie Portmans, too many first posts...
So I think the premise is just crap. They're inventing a problem and an issue in order to try to retain homogenization in how people get their information and how people think.
very cool. hopefully they can get optical confirmation of extrasolar planets in addition to many other things...
Re:CISC, RISC, and VLIW. It's very simple.
on
Emergence of SMT
·
· Score: 2
The point of SMT is that if one thread gets a cache stall because it has to hit main memory, then another execution thread has its instructions loaded into the CPU. SMT is actually one way to help reduce the CPUMEMORY botttleneck.
Pay particular note to the fact that you can take an existing superscalar chip and add SMT for only about a 10% chip real estate premium, while it should be able to double throughput. That's a lot better than trying to double throughput by adding another CPU to a machine or by adding two cores to a CPU.
Also note that it isn't recommended to run processes with different address spaces simultaneously on the processor because that would thrash the TLBs. Its only suggested that you let multithreaded apps (oracle, perhaps future versions of apache) load more than one thread into the processor at the same time.
You need to prove that you're over the hump and can do real work in the real world. That you can work with a team, rather than try to out-score the other team members. That you can handle a project with multiple solutions and not go for the "best" one over an "adequate and quick" or "easy to get right" one. That you can handle something longer, tougher, and more unknown than a class assignment, something without a canned solution. That you'll read the manual. That you'll pull a stock design for a wheel FROM a manual rather than trying to reinvent it.
Wow, that gave me a good laugh. From my experience, that isn't what the college grads are doing, that's what the veterans are doing. Life in the "real world" outside of the "ivory tower" seems to install those attitudes, rather than diminish them from everything I've seen.
I mean in college you've only got grades to compete against each other for. Outside of college everyone is competing for money.
2) the world runs off of money. since nobody seems to be interested in doing the work for free, someone will have to be hired and paid to maintain this mailng list.
3) it is common practice to keep vulnerabilities "secret" for a time in order to give the vendor
a headstart in fixing the problem (e.g. RFPolicy). this list facilitates that, and presumably will shorten the time between discovery of a security bug in bind and release to the public.
4) write your own OpenBind if you don't like ISC / Paul Vixie. quit yer bitchin.
so, don't use suidperl! i strip the suid bit off
of that on any machine that i really care about
having security. the only reason why you'd need
it is if you're writing suid perl scripts.
meanwhile, this argument is kind of stupid. there are no security holes "in perl" any more than there are security holes "in C." but both languages allow you to write bad code that has security holes. a properly educated programmer can avoid the pitfalls in both languages.
"The U.S. codified the idea of constitutionally-guaranteed privacy[...]"
Check your facts and read the Constitution again. There is no constitutional guaranteed right of privacy. It has been argued that there is an implicit right of privacy, and federal judges have tried to manufacture a right of privacy, but the US constitution does not have a right to privacy anywhere in it. Some states have a right to privacy in their constitution (Alaska for example) but federally there is no right to privacy.
I've started reading Jon Katz's rants up until the point when he makes his first factual error. Nice to see that I didn't even get through the first sentence this time.
From what I can understand, you only take a 10% penalty in transistor count, while you can run 4 threads simultaneously (probably not getting a speedup of 4x, but you don't get 4x with 4 CPUs either). And a benefit is that if your this is your database box running oracle, that the multithreaded oracle app can immediately take advantage of this. Make apache multithreaded instead of multiprocess and it would take advantage of it as well. (All assuming your OS supports the SMT features of the chip).
Properly configured, Oracle should scream on these processors...
Nobody in the real world knew what the net was back in the early nineties. Usenet freaked out everytime an even slightly critical article came out about the net in the print media.
Yes, DEC/Compaq should have better access controls on their services. Yes, the university was being stupid. Even so, part of the problem was that I would have needed about 5 firewalls in different parts of the campus to firewall about 20 machines and didn't have the money for those firewalls. The best solution would have been to have the entire campus firewalled, but people would have screamed about the firewall rules.
I suppose the really slick thing to do would be to VLAN everything and have it possible to opt to be on a NAT'd/firewalled subnet on a per-ethernet-port basis. That wasn't in the university budget though.
The presence of an open port implying that a service is part of a "public" internet can be proved wrong by a simple counter example.
Consider an admin at a university who has several machines distributed over the campus and where the campus does not have any firewalls due to the intractabile political problems involved with the networking department imposing firewall rules on researchers. If that admin cannot afford to buy a firewall for every single one of those boxes, and the OS provides no packetfiltering functionality (Tru64 Unix does not have this, and there's no freely available packetfilter utility for Tru64 like ipf), then the admin cannot firewall ports on the machines. And if the admin needs to run RPC services (e.g. nfsd) or other services which don't have access controls, and which the admin does not have source access to, then how is the admin supposed to close those ports?
I've been in that situation before, and I can state that those open ports were open only because I hadn't yet figured out how to close them. They were not "public" they were not "invitations" and I certainly didn't want you portscanning them.
Yes, but you do have the right to walk down the street and peer into windows. You have the right to walk up to their door and even try the lock. You can even carry a crowbar while doing it if you wish. The police don't have anything against you until you enter the premises and leave with something. If you just enter and leave, they still don't have anything on you unless there were no tresspassing signs up. There are 'breaking and entering violations', but no 'entering' violations that I know of.
Check out the laws on "tresspass", "prowling" and "possession of burglary tools." Go ahead and try walking up to someone's door with a crowbar while a cop is watching you and see what happens.
For the state of Washington, we have the following:
RCW 9A.52.060
Making or having burglar tools.
(1) Every person who shall make or mend or cause to be made or mended, or have in his possession, any engine, machine, tool, false key,
pick lock, bit, nippers, or implement adapted, designed, or commonly used for the commission of burglary under circumstances evincing
an intent to use or employ, or allow the same to be used or employed in the commission of a burglary, or knowing that the same is
intended to be so used, shall be guilty of making or having burglar tools.
(2) Making or having burglar tools is a gross misdemeanor.
Also, the law against tresspass is the following:
RCW 9A.52.070
Criminal trespass in the first degree.
(1) A person is guilty of criminal trespass in the first degree if he knowingly enters or remains unlawfully in a building.
The defenses against tresspassing do not include "not having a sign up":
RCW 9A.52.090
Criminal trespass -- Defenses.
In any prosecution under RCW 9A.52.070 and 9A.52.080, it is a defense that:
(1) A building involved in an offense under RCW 9A.52.070 was abandoned; or
(2) The premises were at the time open to members of the public and the actor complied with all lawful conditions imposed on access
to or remaining in the premises; or
(3) The actor reasonably believed that the owner of the premises, or other person empowered to license access thereto, would have
licensed him to enter or remain; or
(4) The actor was attempting to serve legal process which includes any document required or allowed to be served upon persons or
property, by any statute, rule, ordinance, regulation, or court order, excluding delivery by the mails of the United States. This defense
applies only if the actor did not enter into a private residence or other building not open to the public and the entry onto the premises
was reasonable and necessary for service of the legal process.
I've been seeing this discussion for the past four years or so. Every time the discussion is familiar with people claiming "its like walking down the street and looking in windows" with people rebutting "no, its like jiggling locks." Both analogies are totally useless with zero content if you can't actually back up your analogy with reasons why the case is analogous. You convince nobody with these arguments.
I tend to come in on the "jiggling locks" side of things. My rationale? When an exploit comes out on BUGTRAQ for a service, suddenly I see a leap of people scanning all my publically available IPs for that service. I tend to think that those people are looking for machines to break into. I haven't actually set down a honeypot to figure out the percentage of scans that actually turn into attacks, but until someone offers empirical data on it I assume its rather high and that these are the precursors to malicious attacks.
So, what I would claim is that the intent of the majority of the people portscanning out there determines what it is analogous to. Most people walking down the street admiring the architecture of your building are not trying to break into it. Most people checking the locks on your door *are* trying to break into it. Most people I think that portscan large blocks of addresses for a port that just got exploited yesterday on BUGTRAQ are also probably trying to break into your machine. So, I'd offer a standard which is intent. If you disagree with it, that's fine, but don't just wave analogies in my face -- instead try to offer your own standard.
Try to run an NFS server on a Tru64 unix client without having port 2049 open to the world. Most of the RPC services do not have built-in access control lists, nfsd is one particularly obvious example. And Tru64 unix (last I checked, its been about a year) had no way to packet filter this port. The OS had no packetfiltering and publically available free utilties like ipf haven't been ported to Tru64.
Compound that problem with working at a University where they've got policy (albeit usually unenforced) that you'll get fired if you try to firewall or NAT your network. The net result is that there's no way to close some ports on machines that I have no intention whatsoever of letting you look at. Your analogy fails miserably. An open port is not an open door, or an invitation. You should instead assume that if you haven't been explicitly invited or given permission that you are to stay off.
Why are you trying to write a C++ app using threads on linux? I can think of several reasons why you've picked the wrong three things to try to use together.
First of all, if you're going to do threads on linux, you're going to wind up debugging the race conditions in the standard library calls if you use C++. The GNU libstdc++ is not yet fully MT-safe. So, if your requirement is C++ and threads, you pretty much need to pick another platform other than linux.
Second, there's threads on linux. Linus spent a lot of effort to make sure that fork()+exec() work well under linux. There's three reasons to use multithreaded code: faster creation, faster context switches, and easier/faster message passing through shared memory in threads vs. e.g. SysV IPC. Under linux you don't get any gains for the context switches. Context switches for processes are only about 10% slower than context switches for threads under linux. You also don't win a whole lot in process creation which is faster under linux than thread creation is under solaris (plus pthread_create() is broken and slow under linux). You should consider looking at your programming model and seeing if good old fork() will work for you. If you don't believe me,
check out this and the entire thread here. Also read this whole thread.
Then there's the fact that you've run into problems with the tools that you've got on linux not be adequate to handle threads. Not only is gdb broken, but strace isn't going to help you with threads either. And in disagreement to those who claim that printf() is good enough for everyone (e.g. Linus), I think that its good to have many different debugging tools in your toolbox. Strace and reading corefiles in gdb usually are my first line of getting a handle on what the problem is, then I usually read the code and use printf()s. So this is another strike against threads under linux.
I can't speak on the virtues of C++ vs. Java. I'm merely a lowly sysadmin / system programmer who predominantely uses C. I do know though that lots of very good programmers make mistakes because they know how to program but don't understand the architecture of the systems that they're writing code for. They believe things like "threads are fast" without either hitting the linux-kernel mailing list or the linux sources to find out how threads and processes are actually implimented under linux.
So, if you're going to stick with threads then stay the hell away from Linux and use some other OS like Solaris. If you can avoid using threads, though, Linux may be a perfectly sufficient platform for you to use. Once you've made that choice, then you need to decide if you're going to use Java or C++ and I'm out of my league there.
And when you're considering if you should throw out threads, remember:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth
That suggests to me you shouldn't use pthreads unless you need to.
Seems to me more like de Broglie was staring at the right equations at the right time and got a moment of insight that wasn't terribly spectacular. I wouldn't be too surprised if he wasn't the lone discoverer, and that his work had been independently arrived at.
Schroedinger OTOH, engaged in a pretty nasty philosophical debate over the fundamentals of quantum mechanics with Bohr and went and attempted to back up his position by looking for a reformulation of quantum mechanics as a differential equation. Philosophically he turned out to be incorrect, but the work and effort that he put forth advanced quantum mechanics both mathematically and philosophically. The math he did was much nastier than de Broglie's, and the philosophical debate he was engaged in was a lot more advanced than what I see in de Broglie's suggestion that matter was a wave and a particle.
I guess I'm just more impressed by hard work than by insight.
Slashdot Mirror
The basic theory from physics is that as CO2 levels rise, the atmosphere stays transparent to the visual radiation from the sun, while it becomes more opaque to the appx 300K black body radiation from the earth itself. You can understand this basic principle very simply from very well known physical facts. We know what the absorbtion spectra is of the major components of the atmosphere (N2, O2, CO2) and theoretically since CO2 is a more complex molecule than N2 or O2 it has many more vibrational and oscillatory modes in the infrared where it aborbs more radiation. More CO2 in the atmosphere means more opacity of the atmosphere to infrared radiation, which means a hotter Earth.
I will grant that this is theoretical, but its really the only good information that we have to go on. You can argue about little ice ages and natural climate cycles and plants consuming more CO2, but there is one simple fact that we are very sure of, which is that if we release enough CO2 into the atmosphere we'll wind up looking like venus (800K in the shade). In the absence of any really convincing proof that we're not doing any harm to the environment, I'm personally going to assume that we have to take the cautious approach and try to reduce greenhouse gases. The costs if we're wrong and global warming really isn't a problem are that we might slow down the economy a bit. The costs if we continue on our present course and global warming turns out to be a real problem could be devastating. I think its very obvious on which side we should bet our future.
Yup, you're certainly not a lawyer. You don't have a clue.
What's amusing is that the OSS license most closely resembling the IPF license is the BSD license which states:
"Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [..etc...]"
In the context of the BSD license it seems clear that his deliberately leaving out the clause pertaining to modification of source code was meant to prohibit that right.
He changed it, adding restrictions that were not stated, and that therefore did not exist originally in the license, and that therefore do not apply to the distributions before those restrictions were added (this is perfectly valid as it applies to the software distributed with the new releases, of course).
Unfortunately, under copyright law all rights which are not specified revert to the holder of the copyright. He doens't have to give an itemized list of all the ways using his software is prohibited. All he is required to do is to grant your privaleges. Anything else is prohibited. So the fact that the restriction was not originally stated does not change anything. Since it was originally allowed it was prohibited. It always existed there in a legal sense.
Go ahead and talk to a laywer if you don't believe me. This is Copyright Law 101.
*sigh*
The fact here is that nothing is "being assumed to apply retroactively." Under copyright law generally "all other rights are reserved." I'm quite sure that you've seen that phrase used over and over and over. It does, in fact, impart a specific legal meaning. And even if a copyright license does not expressly state that phrase, it is implied.
Now, nowhere in the license did Darren Reed ever grant the right for others to modify his software. That means that you did not have that right and never had that right. There is nothing "retroactive" about it.
To further illustrate, lets look at the BSD license:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [...etc...]
The BSD license looks oddly similar to Darren Reed's IPF license except that it explicitly grants you the right to redistribute the source and binary code with modification. Since it explicitly gives you that right, you have that right and it is not reserved. On the other hand, had that phrase been left out of the BSD license then you would not have been granted that right. Since Darren Reed left that off of IPFs license, you do not have that right. There is no "but it looks like a BSD license, he's trying to fool me!" defense in copyright law.
All that Darren Reed has done with this action is that he's obviously gotten fed up with people confusing his license with the BSD license and decided to clarify it so that he doesn't have to deal with the headaches. He could have left the clarification off and you still wouldn't have the right to modify his software. The clarification does not legally change his license at all.
And how is it that you "know" this. My own opinion on the matter is that Linux is playing catch up and will still be playing catch up after HP-UX and other major unix vendors have moved on.
Also, as to FreeBSD, I've found the -stable branch to be much more stable than the supposedly "stable" branch of Linux. I've had filesystem corruption problems on running filesystems (and totally swapping hardware did not help) in 2.2 kernels as late as 2.2.14. I'm still not going to trust 2.4 in production systems until around 2.4.10. The Linux kernel coding community just doesn't seem to adhere to particularly strong standards of "stability."
I also hate the binary distribution method. There are problems that I run into with the ports tree in FreeBSD from time-to-time, but they don't compare with the glibc-du-jour headache that I get with linux (very similar to the Windoze DLL versioning problems that contribute to the instability of that O/S). Recompiling RPMs is always an "option" but since less attention is paid to people recompiling RPMs this option seems to have much more trouble than the FBSD ports tree when you have a differently configured system than the person who built the RPM.
IDE RAID is silly. For one thing, you need to turn off the write buffering for the IDE drive or you can corrupt data if your power fails. Do the right thing and use SCSI.
stream numbers seem to correlate tightly with my application performance. That's why the P4 and RDRAM is better for you. Sequential memory bandwidth is the one thing that the P4 is really good at. OTOH, if you had a more cache intensive application that gained benefit from the K7's larger L1 cache, the P4 would suck pretty hard. In reality, for most applications the P4's cache is puny, you've got a specialized application where the its ability to stream from memory benefits you.
But the really important fact here, is that people usually don't like to completely limit their information sources. Who hasn't taken some guilty pleasure in dialing the radio into some talk show (be it Limbaugh or NPR) that you vehemently disagree with and yelling your responses back at the host, letting them get lost in the traffic noise? And who hasn't read the alternative viewpoints on slashdot that seem to regularly get moderated up by having four idiots think it deserves a +1, insightful just for disagreeing with the majority? And lots of people go looking for forums to start arguments with people who disagree with them vehemently. I know that in my early 20s I spent a *lot* of time on Usenet getting into arguments with people whose viewpoints I did not share. I think the only problem with the internet right now is that its hard to find forums that have substantial content -- there's too many trolls, too many Natalie Portmans, too many first posts...
So I think the premise is just crap. They're inventing a problem and an issue in order to try to retain homogenization in how people get their information and how people think.
very cool. hopefully they can get optical confirmation of extrasolar planets in addition to many other things...
The point of SMT is that if one thread gets a cache stall because it has to hit main memory, then another execution thread has its instructions loaded into the CPU. SMT is actually one way to help reduce the CPUMEMORY botttleneck.
So, you're just wrong. Trying reading something about what you're commenting on first.
Pay particular note to the fact that you can take an existing superscalar chip and add SMT for only about a 10% chip real estate premium, while it should be able to double throughput. That's a lot better than trying to double throughput by adding another CPU to a machine or by adding two cores to a CPU.
Also note that it isn't recommended to run processes with different address spaces simultaneously on the processor because that would thrash the TLBs. Its only suggested that you let multithreaded apps (oracle, perhaps future versions of apache) load more than one thread into the processor at the same time.
Wow, that gave me a good laugh. From my experience, that isn't what the college grads are doing, that's what the veterans are doing. Life in the "real world" outside of the "ivory tower" seems to install those attitudes, rather than diminish them from everything I've seen.
I mean in college you've only got grades to compete against each other for. Outside of college everyone is competing for money.
2) the world runs off of money. since nobody seems to be interested in doing the work for free, someone will have to be hired and paid to maintain this mailng list.
3) it is common practice to keep vulnerabilities "secret" for a time in order to give the vendor a headstart in fixing the problem (e.g. RFPolicy). this list facilitates that, and presumably will shorten the time between discovery of a security bug in bind and release to the public.
4) write your own OpenBind if you don't like ISC / Paul Vixie. quit yer bitchin.
meanwhile, this argument is kind of stupid. there are no security holes "in perl" any more than there are security holes "in C." but both languages allow you to write bad code that has security holes. a properly educated programmer can avoid the pitfalls in both languages.
Check your facts and read the Constitution again. There is no constitutional guaranteed right of privacy. It has been argued that there is an implicit right of privacy, and federal judges have tried to manufacture a right of privacy, but the US constitution does not have a right to privacy anywhere in it. Some states have a right to privacy in their constitution (Alaska for example) but federally there is no right to privacy.
I've started reading Jon Katz's rants up until the point when he makes his first factual error. Nice to see that I didn't even get through the first sentence this time.
Properly configured, Oracle should scream on these processors...
Nobody in the real world knew what the net was back in the early nineties. Usenet freaked out everytime an even slightly critical article came out about the net in the print media.
I suppose the really slick thing to do would be to VLAN everything and have it possible to opt to be on a NAT'd/firewalled subnet on a per-ethernet-port basis. That wasn't in the university budget though.
Consider an admin at a university who has several machines distributed over the campus and where the campus does not have any firewalls due to the intractabile political problems involved with the networking department imposing firewall rules on researchers. If that admin cannot afford to buy a firewall for every single one of those boxes, and the OS provides no packetfiltering functionality (Tru64 Unix does not have this, and there's no freely available packetfilter utility for Tru64 like ipf), then the admin cannot firewall ports on the machines. And if the admin needs to run RPC services (e.g. nfsd) or other services which don't have access controls, and which the admin does not have source access to, then how is the admin supposed to close those ports?
I've been in that situation before, and I can state that those open ports were open only because I hadn't yet figured out how to close them. They were not "public" they were not "invitations" and I certainly didn't want you portscanning them.
Check out the laws on "tresspass", "prowling" and "possession of burglary tools." Go ahead and try walking up to someone's door with a crowbar while a cop is watching you and see what happens.
For the state of Washington, we have the following:
RCW 9A.52.060 Making or having burglar tools.
(1) Every person who shall make or mend or cause to be made or mended, or have in his possession, any engine, machine, tool, false key, pick lock, bit, nippers, or implement adapted, designed, or commonly used for the commission of burglary under circumstances evincing an intent to use or employ, or allow the same to be used or employed in the commission of a burglary, or knowing that the same is intended to be so used, shall be guilty of making or having burglar tools.
(2) Making or having burglar tools is a gross misdemeanor.
Also, the law against tresspass is the following:
RCW 9A.52.070 Criminal trespass in the first degree.
(1) A person is guilty of criminal trespass in the first degree if he knowingly enters or remains unlawfully in a building.
The defenses against tresspassing do not include "not having a sign up":
RCW 9A.52.090 Criminal trespass -- Defenses.
In any prosecution under RCW 9A.52.070 and 9A.52.080, it is a defense that:
(1) A building involved in an offense under RCW 9A.52.070 was abandoned; or
(2) The premises were at the time open to members of the public and the actor complied with all lawful conditions imposed on access to or remaining in the premises; or
(3) The actor reasonably believed that the owner of the premises, or other person empowered to license access thereto, would have licensed him to enter or remain; or
(4) The actor was attempting to serve legal process which includes any document required or allowed to be served upon persons or property, by any statute, rule, ordinance, regulation, or court order, excluding delivery by the mails of the United States. This defense applies only if the actor did not enter into a private residence or other building not open to the public and the entry onto the premises was reasonable and necessary for service of the legal process.
I tend to come in on the "jiggling locks" side of things. My rationale? When an exploit comes out on BUGTRAQ for a service, suddenly I see a leap of people scanning all my publically available IPs for that service. I tend to think that those people are looking for machines to break into. I haven't actually set down a honeypot to figure out the percentage of scans that actually turn into attacks, but until someone offers empirical data on it I assume its rather high and that these are the precursors to malicious attacks.
So, what I would claim is that the intent of the majority of the people portscanning out there determines what it is analogous to. Most people walking down the street admiring the architecture of your building are not trying to break into it. Most people checking the locks on your door *are* trying to break into it. Most people I think that portscan large blocks of addresses for a port that just got exploited yesterday on BUGTRAQ are also probably trying to break into your machine. So, I'd offer a standard which is intent. If you disagree with it, that's fine, but don't just wave analogies in my face -- instead try to offer your own standard.
Compound that problem with working at a University where they've got policy (albeit usually unenforced) that you'll get fired if you try to firewall or NAT your network. The net result is that there's no way to close some ports on machines that I have no intention whatsoever of letting you look at. Your analogy fails miserably. An open port is not an open door, or an invitation. You should instead assume that if you haven't been explicitly invited or given permission that you are to stay off.
First of all, if you're going to do threads on linux, you're going to wind up debugging the race conditions in the standard library calls if you use C++. The GNU libstdc++ is not yet fully MT-safe. So, if your requirement is C++ and threads, you pretty much need to pick another platform other than linux.
Second, there's threads on linux. Linus spent a lot of effort to make sure that fork()+exec() work well under linux. There's three reasons to use multithreaded code: faster creation, faster context switches, and easier/faster message passing through shared memory in threads vs. e.g. SysV IPC. Under linux you don't get any gains for the context switches. Context switches for processes are only about 10% slower than context switches for threads under linux. You also don't win a whole lot in process creation which is faster under linux than thread creation is under solaris (plus pthread_create() is broken and slow under linux). You should consider looking at your programming model and seeing if good old fork() will work for you. If you don't believe me, check out this and the entire thread here. Also read this whole thread.
Then there's the fact that you've run into problems with the tools that you've got on linux not be adequate to handle threads. Not only is gdb broken, but strace isn't going to help you with threads either. And in disagreement to those who claim that printf() is good enough for everyone (e.g. Linus), I think that its good to have many different debugging tools in your toolbox. Strace and reading corefiles in gdb usually are my first line of getting a handle on what the problem is, then I usually read the code and use printf()s. So this is another strike against threads under linux.
I can't speak on the virtues of C++ vs. Java. I'm merely a lowly sysadmin / system programmer who predominantely uses C. I do know though that lots of very good programmers make mistakes because they know how to program but don't understand the architecture of the systems that they're writing code for. They believe things like "threads are fast" without either hitting the linux-kernel mailing list or the linux sources to find out how threads and processes are actually implimented under linux.
So, if you're going to stick with threads then stay the hell away from Linux and use some other OS like Solaris. If you can avoid using threads, though, Linux may be a perfectly sufficient platform for you to use. Once you've made that choice, then you need to decide if you're going to use Java or C++ and I'm out of my league there.
And when you're considering if you should throw out threads, remember:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth
That suggests to me you shouldn't use pthreads unless you need to.
Schroedinger OTOH, engaged in a pretty nasty philosophical debate over the fundamentals of quantum mechanics with Bohr and went and attempted to back up his position by looking for a reformulation of quantum mechanics as a differential equation. Philosophically he turned out to be incorrect, but the work and effort that he put forth advanced quantum mechanics both mathematically and philosophically. The math he did was much nastier than de Broglie's, and the philosophical debate he was engaged in was a lot more advanced than what I see in de Broglie's suggestion that matter was a wave and a particle.
I guess I'm just more impressed by hard work than by insight.