int
sendfile(int fd, int s, off_t offset, size_t nbytes,
struct sf_hdtr *hdtr, off_t *sbytes, int flags);
DESCRIPTION
Sendfile() sends a regular file specified by descriptor fd out a stream
socket specified by descriptor s.
[...]
IMPLEMENTATION NOTES
The FreeBSD implementation of sendfile() is "zero-copy", meaning that it
has been optimized so that copying of the file data is avoided.
Actually the Eddington experimental results weren't sufficiently accurate to prove GR was correct. He got the right result but his experimental error was too large for it to be conclusive
IDE write buffering also sucks. From the FreeBSD tuning(7) man page:
FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious
data consistency issues introduced by hard drive vendors. Basically the
problem is that IDE drives lie about when a write completes. With IDE
write caching turned on, IDE hard drives will not only write data to disk
out of order, they will sometimes delay some of the blocks indefinitely
when under heavy disk loads. A crash or power failure can result in
serious filesystem corruption. So our default was changed to be safe.
Unfortunately, the result was such a huge loss in performance that we
caved in and changed the default back to on after the release.
[...]
There is a new experimental feature for IDE hard drives called
hw.ata.tags (you also set this in the bootloader) which allows write
caching to be safely turned on. This brings SCSI tagging features to IDE
drives. As of this writing only IBM DPTA and DTLA drives support the
feature. Warning! These drives apparently have quality control problems
and I do not recommend purchasing them at this time.
So, SCSI is better both for performance and for data integrity.
But does anybody have a better method of solving the multiple account problem?
Sure, look at your e-mail address and basically copy that architecture. E-mail overloads the DNS system by specifying a MX record that takes you to a mail exchanger. The entire system is very distributed, unlike the centralized nature of passport and hailstorm. So, to create an alternative, just add some DNS records for authentication and user information records for a given domain. Of course for this to work the DNS system would need to be secured via DNSSEC or something similar.
That way, just like I run my own DNS server and my own e-mail server on a box sitting under my desk, I could similarly run authentication and authorization services from a box under my desk. When I logged into a site it would acccept my e-mail address as my username and validate my password against my authorization service sitting under my desk at home. Then the site could be allowed to store cookies and other information it needs on my box at home for personalization of that site (or this could be denied by those who were paranoid about usage tracking). Then when I wanted to buy something it could securely retrieve my credit card information from the authorication server sitting under my desk and use that.
This way I get to control access to all my information, I get to run security on all my information and I'm not affected by any sort of failures (security, availability, etc) in any centralized service (other than the root nameservers, which i don't want to claim isn't important, but its less of a problem than centralized control of everything like passport and hailstorm). For people who don't know how to setup their own mail and DNS servers they could choose ISPs that they trusted, or if they trusted their IS department at work they could use servers at work. Ideally you'd see the current crop of DSL router/hub/firewall/DHCP boxes grow to also offer plug-and-play authentication and authorization for more novice users at home.
This solves both the multiple-account problem and it also solves the multiple access point problem (having uniform accounts and such across your laptop, desktop, PDA, home, work, etc...). It doesn't, however, give one company centralized control over all of the information and the ability to tax every transaction running across the service (as may happen with passport).
I sincerely hope that something like this will come out of the Liberty Alliance. Unfortunately, I don't see much of a business model involved in it. The only hope for this is either in truely altruistic Open Source, or in a consortium of companies that want to avoid the Microsoft Passport Tax.
IMHO, during the debate over destroying/not publishing government data you need to ask several questions before restricting information:
1. Would a terrorist really want or need this information?
2. Does not publishing this information make the terrorist's job substantially more difficult? In particular, how easily might he do his own research or find the same info in other sources?
3. Will beneficial programs (including security) be able to continue with little disruption after this information is removed?
4. Will people continue to improve security and minimize weaknesses in the absence of these publications?
There's also another question:
5. Is there some concievable purpose towards which an intelligent citizen could use the information for reasons such as citizen oversight of government or for research about technology, engineering or social issues which is not terrorism?
If you can answer 'yes' to that question, then I think you need to keep the information in the public domain and allow free access to it. And since there is no one really suitable to judge in an unbiased fashion weither or not there is a concievable utility to the information being in the public domain, we should err on the side of answering 'yes' to that question.
Really its not just about "beneficial programs" continuing. That's an amazingly beaurocratic viewpoint of how information gets used. I probably use a majority of the information I consume apart from any beaurocracy, institution or corporation. Yet your only test of the utility of the information in question apart from terrorism seems to implicitly assume that this kind of information is worthless. I'd rather not live in your kind of country, thanks.
People, this is about not being quite so liberal with the plans for our US infrastructure. Note the article says that the information was "yanked", and not destroyed.
You obviously didn't bother to read the actual source. The information was destroyed. Specifically, the CDROMs the information was on were broken and all but one shard (to prove it was destroyed) were thrown away.
We're talking about very specific and detailed information that a very small part of the population can even claim to have the most remote of interest in.
And who is to decide who among the citizenry has legitimate interest in a topic and gets access to that information? Who is to decide which topics are off limits to anyone because they are declared to have no legitimate uses among the citizenry?
I happen to have done a lot of research on the synthesis of illegal pharmaceuticals. One of the entirely legitimate purposes of becoming educated on the synthesis of these chemicals is to understand what chemicals people are consuming on the black market and what the health effects of those chemicals might be.
Should someone 'clear' me to be able to research the synthesis of these compounds? How can anyone tell the difference between myself and someone who is interested in the synthesis purely for the purposes of actually synthesizing them illegally?
Similarly, how can you tell the difference between someone who is interested in design flaws in nuclear reactors because they don't want one to meltdown in their backyard and someone who is interested in exploiting those design flaws to create a large number of deaths?
Am I to be excluded from this information because my primary interests in life revolve around computers and not around pharmacy or nuclear engineering? Must I have a master's degree before I can enter the inner sanctum of knowlege about a subject?
We shouldn't be focusing on controlling access to information. We should be focusing on ways to create fewer terrorists and ways to give them fewer opportunities even though they have information.
A) By making each piece of sensitive information harder to get to, you make it exponentially more time consuming to query FROM vast realms of it. e.g., if the terrorists wanted to know the exact engineering specifications used for all the nuclear plants around the country to look for a particularly weak design.
A) By making each piece of sensitive information harder to get to, you make it exponentially more time consuming to query FROM vast realms of it. e.g., if concerned citizens wanted to know about design flaws in the nuclear plants around the country which they live in.
B) By making information harder to come by, we can up the ante by forcing the terrorists as a GROUP, to become more sophisticated/educated. e.g., the size of the effort rules out the few top level people, but the scope/difficult rules out the average ignorant terrorist.
B) By making information harder to come by, we can up the ante by forcing concerned citizens as a GROUP, to become more sophisticated/educated. e.g., the size of the effort rules out the few top level people, but the scope/difficulty rules out the average ignorant citizen.
C) By making information harder to come by, we can make the act of looking for that information much riskier. For instance, rather than merely having to go online or to any public library (anonymously), they must go to a few enumerated locations and risk being spotted and/or creating a trail after the fact.
C) By making information harder to come by, we can make the act of looking for that information much riskier. For instance, rather than merely having to go online or to any public library (anonymously), they [concerned citizens] must go to a few enumerated locations and risk being spotted and/or creating a trail after the fact.
D) By clamping the flow of information, we can force the terrorists to work with far many more unknowns.
D) By clamping the flow of information, we can force concerned citizens to work with far many more unknowns.
As the original article points out there are two different ways that you can deal with the problem of information. You can either secure the problem areas so that even people who have information are powerless to use that information to harm others -- or else you can start trying to control the free flow of information.
Clamping down on the free flow of information is nothing more than "security through obscurity" and will probably be equally as effective. And its major influence will probably not be keeping information out of the hands of terrorist, but keeping information out of the hands of concerned citizens and allow the government to operate with no grass roots oversight.
you can get to the same performance (plus increased storage and safety with Raid 1 or 5) for the same price than a single seagate drive.
The thing is that if your disk array power fails and takes out some data in the IDE drive's write cache then you can be kinda fucked. Even with a journalling filesystem, the filesystem expects that when it writes something that it will hit the disk and not get caught in a write cache and dropped there by a write scheduling algorithm that it doesn't know the details of. And the cheap RAID that you're getting will not save you from this kind of failure -- if this happens it will instead present you with the opportunity to try to do data recovery on a corrupted RAID set.
I hope you're going to do really good backups and use a good UPS.
I think the kernel has more than its share of problems in this regard. There has been a longstanding tradition of exchanges between Andrea Archangeli and Rik van Riel over the kernel VM architecture. This goes beyond the recent issues with the replacement of the 2.4.10 VM with Andrea's VM architecture back to the 2.3.x series and the 2.2.x series. My take on it is that Alan has favored Rik's VM even when Andrea is producing kernels which are much more stable. When you ask him about why he doesn't accept the patches he mutters something about "stability" or that he doesn't believe Andrea's patches fix the problem in the right way but wont give details. There clearly seems to be personal bias going on there. The fact that Alan didn't accept the Andrea+Linus VM changes in 2.4.10 into his kernel tree initially doesn't surprise me at all.
Now, to give them credit they managed to work it all out. In other projects this could have led to forking and bad blood and people who simply won't talk to each other at conferences and such. However, I don't like having to deal with personalities when I'm considering what OS to deploy in an Enterprise situation. Sun and Microsoft both don't have any of this shit (at least not that we can see, and frankly that's good enough for me). In the BSD community the FreeBSD/NetBSD/OpenBSD forks are long past and the dust has pretty much settled.
I like operating systems and applications that don't have political or personal agendas. That is probably why I'm happiest with something like Apache running on top of FreeBSD. If you look at GNOME running on top of Linux it seems like you're almost required to learn about Miguel, RMS, Linus, Alan, Rik and Andrea and all their personal and political issues.
looks to me like its BSDs jail(), but with a messier syscall interface. i'm not sure the extra flexibility is really worth it. interesting to see if linus accepts it or not since he (rightly) tends to not like people cluttering up his syscalls.
In all seriousness, *is* there anything in FreeBSD that's of particular technical interest?
Softupdates? KSE? SMPng? KQueues? They're all worthy of discussion, and not only that but Linus has discusses kqueues on linux-kernel in the past, and while putting down the BSD interface as being over complex, he hasn't managed to get any similar into Linux last I checked. I'd really like to hear what Linus has to say about KSEs vs. clone() as well. And SMPng is doing some very interesting things with giving interrupts a context so that you can use adaptive mutex locks in them to increase scalability -- I'd appreciate hearing Linus' opinion on those as well.
I have a bad feeling, though, that Linus would take his usual tack of being casually dismissive of what other OSes do, while not really adding anything useful to the larger ongoing discusssion. And I'm sorry if people feel that statement is flamebait, but I've read linux-kernel and seen Linus behave this way. He needs to mature a bit and give credit to other people's work, even though he might disagree with it.
kernels are essentially a solved problem, and future interesting stuff will be going on above the kernel level, not in it.
That's incredibly naive. There's a lot of interesting stuff still to do in kernel development. If you think that kernels are "finished" maybe that is because you're spending your time in the Linux world too much?
The 90% chance of poor weather was just for this launch only. It did not reflect the weather conditions for future launches.
I went to high school in Kodiak. Now I live in Seattle and enjoy the sunny and warm weather and don't understand why my friends bitch about it being rainy and grey all the time.
I doubt they're going to be using this launch facility much in the fall and winter.
(Summertimes in Kodiak can be beautiful though -- if you want to visit go there in June -- nice weather and while the Sun will go down the sky will never get totally dark)
Really, do you have a point, or do you just want to pick nits? Security works because it makes things difficult. Are you arguing against this very simple point?
Yes, I'm arguing against this point. The only thing that is stopping ssh from being as convenient as rsh but more secure is lack of integration. And the lack of integration is due to (until recently) lack of freely available code, patent restrictions and government regulations.
The abridgment of our rights is in no way a "win" for terrorists. Yes, it is a loss for us, but I have trouble with the idea that a bunch of l33t h4x0rs not being able to sit around chatting about their latest music swaps in total anonymity...
The privacy issue is not the only issue in this debate. While I tend to agree with the privacy issue, I think there is an equally important and much more compelling (to congresscritters) reason to allow for strong crypto. The reason is that corporate information security infrastructure will likely become compromised if you put into place Key Escrow laws. So, its also the fact that admins can no longer use RSA+AES to secure their VPNs or to encrypt their LAN communications, and can no longer use SSH -- without those programs being modified to use algorithms that have backdoors and deliberate weaknesses.
As long as those backdoors remain strictly in control of the GoodGuys and are never misused then the system might function. But nobody knows how to create an information security infrastructure of the magnitude that will be necessary if key escrow is mandated by law that is also secure against misuse.
I've been a unix system admin for about 5 years (with 5 years of unix user experience and tech support behind that). And my last job was at a Linux shop and I can honestly say that Linux is not ready for prime time.
I don't like taking down my NFS server and finding that the running disks have become corrupted due to some bug in NFS/VFS/ext2. I don't like it when the VM subsystem gets fucked up in the supposedly stable kernel because nobody on linux-kernel knows how to write a VM (2.4.0's kernel? stolen from FreeBSD). Then there's the glibc-version-du-jour problem (similar to the windows DLL problem) and the RPM-version-du-jour problem, both solved by the FreeBSD ports system.
Linux is a fucking annoying OS to try to maintain. And don't even start talking to me about trying to make it work on the desktop. We had religious Linux bigots that tried to make web developers use Linux and lets just say that they got pushed out of that particular decision making process and the users got Macs and Windoze.
I've been there and actually tried all of this, this is not theoretical. Linux sucks.
This is the process that is used in the Virus community today, and it's been working well.
But security holes are not viruses. You don't have to try to get a virus writer to cough up a patch. You also then don't have any equivalent to antivirus software which can get automatic updates of virus signature files.
You need full disclosure to get the OS vendors to write the patches. It is then beneficial to have easy to run exploits so that admins can convince themselves of the need to patch their systems.
One of the points Russ made was that eEye could have discussed this issue on the mailing list before issuing a press release. In addition to feedback having been given by Microsoft, there would have been peer review.
I really don't think that bringing up peer review is helping your argument any. I find that many times on BUGTRAQ someone releases an exploit which is later patched by an OS vendor and due to the availability and "peer review" of the vulnerability it is found that a modified version of the exploit still works. This work is often done by someone other than the original author, and would be made substantially more difficult if the exploit was not availble to be tinkered with.
Russ also raised a point about eEye's motivation. Why do they insist on not only full disclosure, but also releasing exploit code?
Exploit code is valuable to the readers of BUGTRAQ. I've found vulnerabilities and written exploit code before using resources from BUGTRAQ. Its very useful to have working exploits if you're doing your own research into exploit writing or into securing systems against exploits (Immunix, who created StackGuard, for example, try to chase down as many working exploits as they can find).
Should we lock this information out to only established security and OS vendors? Then we go back to the bad old dark days of the internet where nobody knew anything about security.
eEye is in business to sell a product which supposedly protects you against these types of attacks before they happen.
Even if this is true, they wouldn't have a business model if OS vendors would properly audit their code. I don't think that eEye could make a whole lot of money off of OpenBSD in this way.
Most sensible physicists are holding out for non-philosophical explanations of "Quantum Mystery." That would be theories like the Girardi-Rimini-Weber theory or a non-linear Schrodiner Equation.
"Quantum Philosophies" have regularly been overturned. A theory which was in vogue awhile back among the quantum philosophy crowd was that antiparticles were particles travelling backwards in time. This lead to the suggestion (by Feynman?) that all matter could just be one particle bouncing backwards and forwards through time. Of course, this theory was disproven by CP violating processes in K and B mesons (c.f. recent slashdot article) so that philosophical theory goes down the shitter.
Notions that QM proves that there are many worlds, or that physicists create the particles that they observer are fundamentally *not* *physics*. They aren't science either.
Ideally you could set up a SMTP server, but that isn't always feasible in the real world
I've got my own domain setup in my house. I've got 512/512 DSL going to a K6 (original) 233MHz machine that has two el cheapo intel eepro100 NICs in it. Total cost from a place like Re-PC for this system would be around $60. Throw FreeBSD and sendmail/exim/postfix on it and you've got your SMTP machine. And realistic this system is drastically OVER-powered. I'm going to saturate my DSL line long before I saturate my K6.
If you don't know how to do that, contract out some hacker (of the good kind that won't backdoor your machine) for $100-$300 or so.
The P4 streams memory faster than the K7, but most applications don't only need raw sequential throughput. The problems with the P4:
1. the long pipeline means if you stall or miss a branch prediction you lose a lot more cycles
2. the L2/L1/trace caches are too small and programs will wind up going to main memory
3. RDRAM is great for streaming sequential bits, but it has high latency for random access. The P4 needs a much larger L2 cache to sit in front of the RDRAM to reduce the random access to main memory.
So that 3.2Gbs figure is not the whole story.
The P4 Xeons have the potential to be great chips if they get some more cache on them. They're going to get a die shrink and more L3 which will help greatly. They could also use larger L2/L1/trace caches to reduce cache thrashing during context switches. The vanilla P4 will probably always have too little cache and will suck hard, though.
It looks like Intel made a decision to go after the high end of the market in a few years time and in the mean time to produce crippled chips that just have really high MHz ratings. And I'd guess that they're going to be fucking the consumer market over pretty hard for awhile to come.
What I'd really like to see: the interleaved DDR SDRAM from the nForce chipset in a multiprocesser server chipset like the 760MP. Ideally something like 4x DDR interleaving with a quad CPU chipset.... *droool*
Slashdot Mirror
A basic bit of research by running 'man sendfile' on a FreeBSD system would have told you this:
SENDFILE(2) FreeBSD System Calls Manual SENDFILE(2)
NAME
sendfile - send a file to a socket
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include sys/types.h
#include sys/socket.h
#include sys/uio.h
int
sendfile(int fd, int s, off_t offset, size_t nbytes,
struct sf_hdtr *hdtr, off_t *sbytes, int flags);
DESCRIPTION
Sendfile() sends a regular file specified by descriptor fd out a stream
socket specified by descriptor s.
[...]
IMPLEMENTATION NOTES
The FreeBSD implementation of sendfile() is "zero-copy", meaning that it
has been optimized so that copying of the file data is avoided.
Actually the Eddington experimental results weren't sufficiently accurate to prove GR was correct. He got the right result but his experimental error was too large for it to be conclusive
FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. Basically the problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives will not only write data to disk out of order, they will sometimes delay some of the blocks indefinitely when under heavy disk loads. A crash or power failure can result in serious filesystem corruption. So our default was changed to be safe. Unfortunately, the result was such a huge loss in performance that we caved in and changed the default back to on after the release.
[...]
There is a new experimental feature for IDE hard drives called hw.ata.tags (you also set this in the bootloader) which allows write caching to be safely turned on. This brings SCSI tagging features to IDE drives. As of this writing only IBM DPTA and DTLA drives support the feature. Warning! These drives apparently have quality control problems and I do not recommend purchasing them at this time.
So, SCSI is better both for performance and for data integrity.
Sure, look at your e-mail address and basically copy that architecture. E-mail overloads the DNS system by specifying a MX record that takes you to a mail exchanger. The entire system is very distributed, unlike the centralized nature of passport and hailstorm. So, to create an alternative, just add some DNS records for authentication and user information records for a given domain. Of course for this to work the DNS system would need to be secured via DNSSEC or something similar.
That way, just like I run my own DNS server and my own e-mail server on a box sitting under my desk, I could similarly run authentication and authorization services from a box under my desk. When I logged into a site it would acccept my e-mail address as my username and validate my password against my authorization service sitting under my desk at home. Then the site could be allowed to store cookies and other information it needs on my box at home for personalization of that site (or this could be denied by those who were paranoid about usage tracking). Then when I wanted to buy something it could securely retrieve my credit card information from the authorication server sitting under my desk and use that.
This way I get to control access to all my information, I get to run security on all my information and I'm not affected by any sort of failures (security, availability, etc) in any centralized service (other than the root nameservers, which i don't want to claim isn't important, but its less of a problem than centralized control of everything like passport and hailstorm). For people who don't know how to setup their own mail and DNS servers they could choose ISPs that they trusted, or if they trusted their IS department at work they could use servers at work. Ideally you'd see the current crop of DSL router/hub/firewall/DHCP boxes grow to also offer plug-and-play authentication and authorization for more novice users at home.
This solves both the multiple-account problem and it also solves the multiple access point problem (having uniform accounts and such across your laptop, desktop, PDA, home, work, etc...). It doesn't, however, give one company centralized control over all of the information and the ability to tax every transaction running across the service (as may happen with passport).
I sincerely hope that something like this will come out of the Liberty Alliance. Unfortunately, I don't see much of a business model involved in it. The only hope for this is either in truely altruistic Open Source, or in a consortium of companies that want to avoid the Microsoft Passport Tax.
If you read the article, they've got three DNA samples from different specimens.
1. Would a terrorist really want or need this information?
2. Does not publishing this information make the terrorist's job substantially more difficult? In particular, how easily might he do his own research or find the same info in other sources?
3. Will beneficial programs (including security) be able to continue with little disruption after this information is removed?
4. Will people continue to improve security and minimize weaknesses in the absence of these publications?
There's also another question:
5. Is there some concievable purpose towards which an intelligent citizen could use the information for reasons such as citizen oversight of government or for research about technology, engineering or social issues which is not terrorism?
If you can answer 'yes' to that question, then I think you need to keep the information in the public domain and allow free access to it. And since there is no one really suitable to judge in an unbiased fashion weither or not there is a concievable utility to the information being in the public domain, we should err on the side of answering 'yes' to that question.
Really its not just about "beneficial programs" continuing. That's an amazingly beaurocratic viewpoint of how information gets used. I probably use a majority of the information I consume apart from any beaurocracy, institution or corporation. Yet your only test of the utility of the information in question apart from terrorism seems to implicitly assume that this kind of information is worthless. I'd rather not live in your kind of country, thanks.
You obviously didn't bother to read the actual source. The information was destroyed. Specifically, the CDROMs the information was on were broken and all but one shard (to prove it was destroyed) were thrown away.
And who is to decide who among the citizenry has legitimate interest in a topic and gets access to that information? Who is to decide which topics are off limits to anyone because they are declared to have no legitimate uses among the citizenry?
I happen to have done a lot of research on the synthesis of illegal pharmaceuticals. One of the entirely legitimate purposes of becoming educated on the synthesis of these chemicals is to understand what chemicals people are consuming on the black market and what the health effects of those chemicals might be.
Should someone 'clear' me to be able to research the synthesis of these compounds? How can anyone tell the difference between myself and someone who is interested in the synthesis purely for the purposes of actually synthesizing them illegally?
Similarly, how can you tell the difference between someone who is interested in design flaws in nuclear reactors because they don't want one to meltdown in their backyard and someone who is interested in exploiting those design flaws to create a large number of deaths?
Am I to be excluded from this information because my primary interests in life revolve around computers and not around pharmacy or nuclear engineering? Must I have a master's degree before I can enter the inner sanctum of knowlege about a subject?
We shouldn't be focusing on controlling access to information. We should be focusing on ways to create fewer terrorists and ways to give them fewer opportunities even though they have information.
A) By making each piece of sensitive information harder to get to, you make it exponentially more time consuming to query FROM vast realms of it. e.g., if concerned citizens wanted to know about design flaws in the nuclear plants around the country which they live in.
B) By making information harder to come by, we can up the ante by forcing the terrorists as a GROUP, to become more sophisticated/educated. e.g., the size of the effort rules out the few top level people, but the scope/difficult rules out the average ignorant terrorist.
B) By making information harder to come by, we can up the ante by forcing concerned citizens as a GROUP, to become more sophisticated/educated. e.g., the size of the effort rules out the few top level people, but the scope/difficulty rules out the average ignorant citizen.
C) By making information harder to come by, we can make the act of looking for that information much riskier. For instance, rather than merely having to go online or to any public library (anonymously), they must go to a few enumerated locations and risk being spotted and/or creating a trail after the fact.
C) By making information harder to come by, we can make the act of looking for that information much riskier. For instance, rather than merely having to go online or to any public library (anonymously), they [concerned citizens] must go to a few enumerated locations and risk being spotted and/or creating a trail after the fact.
D) By clamping the flow of information, we can force the terrorists to work with far many more unknowns.
D) By clamping the flow of information, we can force concerned citizens to work with far many more unknowns.
As the original article points out there are two different ways that you can deal with the problem of information. You can either secure the problem areas so that even people who have information are powerless to use that information to harm others -- or else you can start trying to control the free flow of information.
Clamping down on the free flow of information is nothing more than "security through obscurity" and will probably be equally as effective. And its major influence will probably not be keeping information out of the hands of terrorist, but keeping information out of the hands of concerned citizens and allow the government to operate with no grass roots oversight.
I like the idea, but OpenNIC needs better reliability.
The thing is that if your disk array power fails and takes out some data in the IDE drive's write cache then you can be kinda fucked. Even with a journalling filesystem, the filesystem expects that when it writes something that it will hit the disk and not get caught in a write cache and dropped there by a write scheduling algorithm that it doesn't know the details of. And the cheap RAID that you're getting will not save you from this kind of failure -- if this happens it will instead present you with the opportunity to try to do data recovery on a corrupted RAID set.
I hope you're going to do really good backups and use a good UPS.
I think the kernel has more than its share of problems in this regard. There has been a longstanding tradition of exchanges between Andrea Archangeli and Rik van Riel over the kernel VM architecture. This goes beyond the recent issues with the replacement of the 2.4.10 VM with Andrea's VM architecture back to the 2.3.x series and the 2.2.x series. My take on it is that Alan has favored Rik's VM even when Andrea is producing kernels which are much more stable. When you ask him about why he doesn't accept the patches he mutters something about "stability" or that he doesn't believe Andrea's patches fix the problem in the right way but wont give details. There clearly seems to be personal bias going on there. The fact that Alan didn't accept the Andrea+Linus VM changes in 2.4.10 into his kernel tree initially doesn't surprise me at all.
Now, to give them credit they managed to work it all out. In other projects this could have led to forking and bad blood and people who simply won't talk to each other at conferences and such. However, I don't like having to deal with personalities when I'm considering what OS to deploy in an Enterprise situation. Sun and Microsoft both don't have any of this shit (at least not that we can see, and frankly that's good enough for me). In the BSD community the FreeBSD/NetBSD/OpenBSD forks are long past and the dust has pretty much settled.
I like operating systems and applications that don't have political or personal agendas. That is probably why I'm happiest with something like Apache running on top of FreeBSD. If you look at GNOME running on top of Linux it seems like you're almost required to learn about Miguel, RMS, Linus, Alan, Rik and Andrea and all their personal and political issues.
looks to me like its BSDs jail(), but with a messier syscall interface. i'm not sure the extra flexibility is really worth it. interesting to see if linus accepts it or not since he (rightly) tends to not like people cluttering up his syscalls.
Softupdates? KSE? SMPng? KQueues? They're all worthy of discussion, and not only that but Linus has discusses kqueues on linux-kernel in the past, and while putting down the BSD interface as being over complex, he hasn't managed to get any similar into Linux last I checked. I'd really like to hear what Linus has to say about KSEs vs. clone() as well. And SMPng is doing some very interesting things with giving interrupts a context so that you can use adaptive mutex locks in them to increase scalability -- I'd appreciate hearing Linus' opinion on those as well.
I have a bad feeling, though, that Linus would take his usual tack of being casually dismissive of what other OSes do, while not really adding anything useful to the larger ongoing discusssion. And I'm sorry if people feel that statement is flamebait, but I've read linux-kernel and seen Linus behave this way. He needs to mature a bit and give credit to other people's work, even though he might disagree with it.
kernels are essentially a solved problem, and future interesting stuff will be going on above the kernel level, not in it.
That's incredibly naive. There's a lot of interesting stuff still to do in kernel development. If you think that kernels are "finished" maybe that is because you're spending your time in the Linux world too much?
I went to high school in Kodiak. Now I live in Seattle and enjoy the sunny and warm weather and don't understand why my friends bitch about it being rainy and grey all the time.
I doubt they're going to be using this launch facility much in the fall and winter.
(Summertimes in Kodiak can be beautiful though -- if you want to visit go there in June -- nice weather and while the Sun will go down the sky will never get totally dark)
Yes, I'm arguing against this point. The only thing that is stopping ssh from being as convenient as rsh but more secure is lack of integration. And the lack of integration is due to (until recently) lack of freely available code, patent restrictions and government regulations.
not if you're running a recent version of *BSD
b) your server must support it,
it does if you're running a recent version of *BSD
c) you have to learn about keys to use it well.
but you can get a massive increase in security even if you don't bother to learn about keys.
Even this is incorrect. SSH is just as convenient as rsh, but it is vastly more secure.
The privacy issue is not the only issue in this debate. While I tend to agree with the privacy issue, I think there is an equally important and much more compelling (to congresscritters) reason to allow for strong crypto. The reason is that corporate information security infrastructure will likely become compromised if you put into place Key Escrow laws. So, its also the fact that admins can no longer use RSA+AES to secure their VPNs or to encrypt their LAN communications, and can no longer use SSH -- without those programs being modified to use algorithms that have backdoors and deliberate weaknesses.
As long as those backdoors remain strictly in control of the GoodGuys and are never misused then the system might function. But nobody knows how to create an information security infrastructure of the magnitude that will be necessary if key escrow is mandated by law that is also secure against misuse.
I don't like taking down my NFS server and finding that the running disks have become corrupted due to some bug in NFS/VFS/ext2. I don't like it when the VM subsystem gets fucked up in the supposedly stable kernel because nobody on linux-kernel knows how to write a VM (2.4.0's kernel? stolen from FreeBSD). Then there's the glibc-version-du-jour problem (similar to the windows DLL problem) and the RPM-version-du-jour problem, both solved by the FreeBSD ports system.
Linux is a fucking annoying OS to try to maintain. And don't even start talking to me about trying to make it work on the desktop. We had religious Linux bigots that tried to make web developers use Linux and lets just say that they got pushed out of that particular decision making process and the users got Macs and Windoze.
I've been there and actually tried all of this, this is not theoretical. Linux sucks.
But security holes are not viruses. You don't have to try to get a virus writer to cough up a patch. You also then don't have any equivalent to antivirus software which can get automatic updates of virus signature files.
You need full disclosure to get the OS vendors to write the patches. It is then beneficial to have easy to run exploits so that admins can convince themselves of the need to patch their systems.
One of the points Russ made was that eEye could have discussed this issue on the mailing list before issuing a press release. In addition to feedback having been given by Microsoft, there would have been peer review.
I really don't think that bringing up peer review is helping your argument any. I find that many times on BUGTRAQ someone releases an exploit which is later patched by an OS vendor and due to the availability and "peer review" of the vulnerability it is found that a modified version of the exploit still works. This work is often done by someone other than the original author, and would be made substantially more difficult if the exploit was not availble to be tinkered with.
Russ also raised a point about eEye's motivation. Why do they insist on not only full disclosure, but also releasing exploit code?
Exploit code is valuable to the readers of BUGTRAQ. I've found vulnerabilities and written exploit code before using resources from BUGTRAQ. Its very useful to have working exploits if you're doing your own research into exploit writing or into securing systems against exploits (Immunix, who created StackGuard, for example, try to chase down as many working exploits as they can find).
Should we lock this information out to only established security and OS vendors? Then we go back to the bad old dark days of the internet where nobody knew anything about security.
eEye is in business to sell a product which supposedly protects you against these types of attacks before they happen.
Even if this is true, they wouldn't have a business model if OS vendors would properly audit their code. I don't think that eEye could make a whole lot of money off of OpenBSD in this way.
Set the machine up behind NAT. Or, install it and turn off all of the services (use lsof -i to check) and then download the patches.
"Quantum Philosophies" have regularly been overturned. A theory which was in vogue awhile back among the quantum philosophy crowd was that antiparticles were particles travelling backwards in time. This lead to the suggestion (by Feynman?) that all matter could just be one particle bouncing backwards and forwards through time. Of course, this theory was disproven by CP violating processes in K and B mesons (c.f. recent slashdot article) so that philosophical theory goes down the shitter.
Notions that QM proves that there are many worlds, or that physicists create the particles that they observer are fundamentally *not* *physics*. They aren't science either.
I've got my own domain setup in my house. I've got 512/512 DSL going to a K6 (original) 233MHz machine that has two el cheapo intel eepro100 NICs in it. Total cost from a place like Re-PC for this system would be around $60. Throw FreeBSD and sendmail/exim/postfix on it and you've got your SMTP machine. And realistic this system is drastically OVER-powered. I'm going to saturate my DSL line long before I saturate my K6.
If you don't know how to do that, contract out some hacker (of the good kind that won't backdoor your machine) for $100-$300 or so.
1. the long pipeline means if you stall or miss a branch prediction you lose a lot more cycles
2. the L2/L1/trace caches are too small and programs will wind up going to main memory
3. RDRAM is great for streaming sequential bits, but it has high latency for random access. The P4 needs a much larger L2 cache to sit in front of the RDRAM to reduce the random access to main memory.
So that 3.2Gbs figure is not the whole story.
The P4 Xeons have the potential to be great chips if they get some more cache on them. They're going to get a die shrink and more L3 which will help greatly. They could also use larger L2/L1/trace caches to reduce cache thrashing during context switches. The vanilla P4 will probably always have too little cache and will suck hard, though.
It looks like Intel made a decision to go after the high end of the market in a few years time and in the mean time to produce crippled chips that just have really high MHz ratings. And I'd guess that they're going to be fucking the consumer market over pretty hard for awhile to come.
What I'd really like to see: the interleaved DDR SDRAM from the nForce chipset in a multiprocesser server chipset like the 760MP. Ideally something like 4x DDR interleaving with a quad CPU chipset.... *droool*