The law is NOT above human rights. Where the law contradicts human rights, the law shall not prevail and shall be moot, pointless, and totally irrelevant.
Now whether a law prohibiting something on the internet contradicts human rights is another issue. And it is difficult to work out because, who decides? The same stupid power-mongering politicians who made the bad law in the first place? I don't think so.
In the real world, the luxuries we think programming needs to have just don't exist.
we train ourselves to perform the steps required to accomplish specific tasks
We who? Programmers? In the real world, business needs more programmers because there are more tasks. And those tasks are results driven, leaving it up to the programmer to translate result requirements into programming models. It is this step that needs to be implemented. Of course that can mean the end of programmers as we know it today.
Whats really needed... is time
Joe Normal will never program as we know it. But I do believe the eventual end result is that Joe Normal will be able to get a computer to get things done that would today require a programmer, and require time.
One of the problems that seems to be missed by the academic research community is that the more abstract something is made, the fewer are the number of people who can work with it. While certain things as the C language and assembly language are not something the average person can take on, abstractions which work in mathematical constructs are no better.
One thing that will be needed more and more in time is the ability to make more people capable of accomplishing the tasks we today call programming. To solve this we need to focus on just what those tasks really are, and how people think about them. Most people think about the results they want; few can think about the steps needed to achieve those results. What will work better for the age of information is tools that work better with the concepts that average people (as opposed to academics) really think about, and use that to produce what they want.
I suspect it will end up being something more along the line of providing example results, and having the computer then try to mimic them. The cycle would be repeated with corrections and adjustments until the results are as expected, or close enough to be satisfactory. These tools still have to be programmed a more conventional way, though I suppose perhaps Eidola one approach to accomplishing this.
I used to be employed by the Taco Bell Corporation. That is a Division of TriCon, which is a Division of PepsiCo. I hate Taco Bell.
They Suck. They Suck. They Suck. They Suck.
Uhm, Yeah
mountain dew.... it's dew-riffic!
And just who do you think makes that mountain dew ?
I was installing both FreeBSD and OpenBSD with exactly the same filesystem organization (e.g. which mount points are separate filesystems) and partition sizes as I normally use in Linux, for comparative purposes. I installed OpenBSD first and had not a lick of trouble. The option I had once I encountered the trouble with disklabel was to go back and change the layout (I combined/var/log back into/var) on the Linux and OpenBSD systems and re-install them. But it just seemed silly to do that if there was a simple workaround in FreeBSD. I was wanting to see if the time it might take for me to get FreeBSD working the way I had planned would be less or greater than the time to go back and redo that Linux and OpenBSD.
Oddly, as it turns out, there was a way. Either no one knew it, or it got lost in all the noise (a lot of people were transposing the slice and partition concepts, which is easy enough to do since what BSD calls a slice is called a partition in DOS terms). You ask why anyone would want more than 7 partitions in a single slice? and this gets to the nature of the solution, that FreeBSD supports more than one disklabel, each located in different slices. That could have been the solution, but no one presented the whole concept (there were a bunch of things said that made no sense at all, so maybe someone referred to this with an assumption I already knew how FreeBSD worked).
Thanks for the invite. Next time I'll stop by there first. Hell I might even do so without a question just to say hi.
I hope that when I ask a question, and someone knows that the answer does happen to be in a certain document, and realizes that these things can be missed, they would simply say where to find the answer.
There are lots of things about BSD I don't remember, or never learned, when I used it many years ago (because I wasn't really doing all that much with it at the time). When reading documentation there are two ways to go about it. One is to read it sequentially like a book. This takes longer the bigger the documentation is (The FreeBSD Handbook looks like about 6 to 12 hours worth) and of course lots of gritty details get forgotten. Another is to try to match your own interpretation or wording of a concept with the index or table of contents. Sometimes that works and sometimes it fails. And then, even when you get to the right part of the document, the details simply go unnoticed because the wording is too BSD-ish (not unexpected in a BSD document, right).
I'm very much a help-myself kind of person. Rarely would I ever need to ask someone for help. But what is useful is good, well organized, technical info. Usually the answer I look for is very succinct. Too often what I get isn't (even in the Linux community).
FreeBSD may be better than Linux for what it tries to be (which is a lot).
After a failed install of FreeBSD 3.1, I now have FreeBSD 4.2 running, though with a slight bit of trouble. However, 3.1 was a disaster, not because of the software problems that prevented it from being installed, but because of the attitude problems I encountered asking questions about it to resolve the problems. It is because of that I cannot choose to go with FreeBSD for project where it does seem to be technically superior.
As in the commercial business software sector, the free open software sector needs support, too. And FreeBSD is more lacking in this area than Linux is (though both certainly are), at least from the perspective of someone like myself who is already more familiar with Linux. Support for free open software comes online in places like IRC (analogous to an 800 code toll free number for fast responses to simple questions), USENET, and various mailing lists. However, I found all of these had lots of people with attitude. As expected, IRC was the worst.
Case in point. FreeBSD 3.1 didn't install on my system and stopped at an error message saying it could not find the CDROM (but it booted from it, and Linux, OpenBSD and Windows used that CDROM just fine). Lots of people said my hardware was broken (it was not). Lots more people said FreeBSD didn't support ATAPI CDROM on the IDE secondary master and followed that up with reasons why not, such as it was in violation of the standards (I went and looked, and no it is not). Ultimately it turns out the FreeBSD kernel works fine with such a CDROM; it was the installer program that failed. By the time I did find out, I was so disgusted by the people, I decided to not finish doing the install.
I came back with the release of 4.2. I ran into a simple problem and I immediately knew a way around the problem. But I wanted to avoid that workaround if I could. The problem was I had planned for 8 partitions, but disklabel only let me do 7 (partition "c" not counted). I asked on IRC if this was indeed a real limit or if there was a way to work around it. I had lots of wrong replies, including one person who said that was a limitation of SCSI (odd, since I'm using IDE). The most common was that my hardware was broken. Lots of people replied "I installed fine with one partition" even though I never asked "How many partitions did you install with?". Eventually, about an hour after I first asked, and 3 channel visits later, one person (thank you Metrol) finally provided me with documentation that showed there was indeed such a limit. So I went and changed my strategy to accomodate the limit (including a re-install of OpenBSD the same way since I was comparing these). But it left me with a renewed disgust for the FreeBSD community.
My postman doesn't make me sit there and open all my mail. I don't get deluged with 20-30 pieces of junk every day on paper. What the postman brings isn't going to expand exponentially because the sender pays to have it sent, whereas spam is paid for by ripping people off. My bandwidth is used up when POP3 downloads the junk before I get to see it. Bogus subjects mean sometimes people click on it to read it anyway so just clicking delete still means time wasted.
And yes there is a way to stop telemarketing and I've done it already. And there is a way to stop SPAM and congress doesn't even need to get involved. You just hate it because we cut off so many of your relays.
Closed bug reports only work with closed source. It's just a matter of time before Vixie closes BIND, or at least the leet version of it that members get to use.
Combining open source with closed information is what will fail. The only way closing the bug reports works at all is if the source is also closed. Otherwise l33t cR4q3rz who can read source can find bugs and distribute exploits (w/o NDAs), and admins who can't (read source) won't be able to fix things, all the while the members get to sit on their own lazy asses because they got them covered.
Many ISPs do verify first. Stolen ones are generally good for a month or so. And their scams net them a few more credit card numbers of dumb people each time they spam.
They want to. But there's no control over the junk coming in unless you use things like RBL and ORBS. Yet you have another vocal group of whiners that try to destroy all that and further promote spamming while giving lip service to idealistic TCP/IP.
Over the years I've collected a few string functions I've written. I'm starting to write some more, and I'll be releasing the library in the next few months. OK? Tell me what kinds of functions you'd like to see in C.
Languages don't make buffer overflows, programmers do.
Some people, including myself in the past few years, don't code in buffer overflows. I have never coded a message constructor with sprintf() like that. I haven't used gets() that I can recall. And I cannot remember when I ever did do any input without checking buffer size. I've been coding in C since '82 as well.
C and C++ are as strong and secure as the programmer who writes in them. Do the developers of Perl and Python put C/C++ coded buffer overflows in their code? I'm quite sure they do not.
Interesting. Perhaps it is easier to administer. But I hope it isn't as hard to do a startup as qmail was with daemontools. I hope it doesn't have as many processes running as qmail did. And I hope it uses no more than a single userid. As for configuration, it looks like it's command oriented while I prefer file oriented (e.g. my own scripts generate all the files from data stored elsewhere anyway). But this operates in a total replacement mode since they can't really determine incremental changes reliably. I should be giving it a try in the next couple of weeks.
If all the NDAs stipulated a finite time period of not more than 7 days, allowing anyone to release the information at that point, then I would believe you. 7 days is plenty for a vendor to get their act together. In fact 1 business day is enough, really. But I'll allow for 7 given that there are always stupid managers getting in the way of real work.
Instead, this is a means to allow Paul Vixie to cover things up while he doesn't make much effort to fix it. Someone who continues to release known bad programming methods isn't likely to be very adept at rapidly fixing exploits anyway. And this secretive approach only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught.
Why do you get to decide what kind of interface I have to work with? Most of the user interfaces out there suck.
However, I don't agree with Raskin, either. And OS *can* let users change their interface and still give a good API abstraction to applications to work with most user interfaces. Too many (e.g. Windows) don't do the right thing. Mac isn't very great for that, either.
There are TWO reasons why BIND gets exploited. Number one is that a fix to an exploit is not made available. Number two is that administrators don't upgrade to install fixes to exploits. What Paul Vixie wants to do is make sure both reasons work to ensure thousands of exploitable DNS servers around the world.
People like Paul Vixie should know better than to use functions like sprintf() to construct messages. Why are these problems happening over and over? And what other problems will the code have that isn't necessarily a security issue, but can cause problems? I find BIND does a lot of bizarre and strange things at times for no apparent (or logged) good reason. I am more and more untrusting of Paul's coding practices, and even his system design.
DJB's code may be secure, but it's a pain in the arse to administer. And that in itself is a security risk waiting to blow.
As most of us know, "Security isn't a thing; it is a process" [Schneier]. Administration is a very critical link in security... as critical as the code, if not more so. When administrative procedures and tools are clear and easy to use, fewer mistakes happen. Turn that around and you get more mistakes that can lead to security exposures, even for very experienced and security conscious administrators.
I switched from Sendmail to Qmail over a years ago. While I didn't regret it, I did experience difficulties in administering it. While I got some help, I also got a lot of "read the source" responses. Those responses were cop-outs. Even though I have 19 years C coding experience, I found DJB's code hard to read, and his organization non-obvious. And there were no comments to explain it. The source code was essentially useless as a resource for administering Qmail.
I looked into changing again, and studied Exim and Postfix. I decided to go with Postfix for some reasons not really related to any problems I found in Exim. I certainly do not regret this change. It is much easier to administer than Qmail. And unlike the Qmail community, I haven't yet run into anyone in the Postfix community that cops an attitude when there is a disagreement.
I am aware of DJB's security concerns about Postfix. But I consider the tradeoff to shed the security problems of administration difficulties to be worth making the move over to Postfix.
This is why I'll be reluctant to immediately move to DJBDNS, though I can certainly say I am tempted to give it a try.
I used to work in a place that stored about 20 terabytes of certain documents it worked with, which varied in size from 1K to 5G each. Median size was about 40M. All the meta data, like what customer it applied to, dates of processing, and so forth, were stored in a database. But the actual document file never was. The network path to the document was in the database, but the documents were stored on hundreds of Novell (ick) file servers. The database was still the major bottleneck of the whole operation. All these wonderful database facilities like SQL don't mean squat when the main functionality was to get the document, process it, and store it back, which is what happened most of the time. Of course it was nice to have the SQL when you needed to manually check on things or do some odd searches. But I would never store bulk data in a database; only the pointer to it would go in there. Databases are faster at complex searching, but not at bulk delivery of data.
Slashdot Mirror
The law is NOT above human rights. Where the law contradicts human rights, the law shall not prevail and shall be moot, pointless, and totally irrelevant.
Now whether a law prohibiting something on the internet contradicts human rights is another issue. And it is difficult to work out because, who decides? The same stupid power-mongering politicians who made the bad law in the first place? I don't think so.
In the real world, the luxuries we think programming needs to have just don't exist.
We who? Programmers? In the real world, business needs more programmers because there are more tasks. And those tasks are results driven, leaving it up to the programmer to translate result requirements into programming models. It is this step that needs to be implemented. Of course that can mean the end of programmers as we know it today.
Joe Normal will never program as we know it. But I do believe the eventual end result is that Joe Normal will be able to get a computer to get things done that would today require a programmer, and require time.
One of the problems that seems to be missed by the academic research community is that the more abstract something is made, the fewer are the number of people who can work with it. While certain things as the C language and assembly language are not something the average person can take on, abstractions which work in mathematical constructs are no better.
One thing that will be needed more and more in time is the ability to make more people capable of accomplishing the tasks we today call programming. To solve this we need to focus on just what those tasks really are, and how people think about them. Most people think about the results they want; few can think about the steps needed to achieve those results. What will work better for the age of information is tools that work better with the concepts that average people (as opposed to academics) really think about, and use that to produce what they want.
I suspect it will end up being something more along the line of providing example results, and having the computer then try to mimic them. The cycle would be repeated with corrections and adjustments until the results are as expected, or close enough to be satisfactory. These tools still have to be programmed a more conventional way, though I suppose perhaps Eidola one approach to accomplishing this.
And just who do you think makes that mountain dew ?
I was installing both FreeBSD and OpenBSD with exactly the same filesystem organization (e.g. which mount points are separate filesystems) and partition sizes as I normally use in Linux, for comparative purposes. I installed OpenBSD first and had not a lick of trouble. The option I had once I encountered the trouble with disklabel was to go back and change the layout (I combined /var/log back into /var) on the Linux and OpenBSD systems and re-install them. But it just seemed silly to do that if there was a simple workaround in FreeBSD. I was wanting to see if the time it might take for me to get FreeBSD working the way I had planned would be less or greater than the time to go back and redo that Linux and OpenBSD.
Oddly, as it turns out, there was a way. Either no one knew it, or it got lost in all the noise (a lot of people were transposing the slice and partition concepts, which is easy enough to do since what BSD calls a slice is called a partition in DOS terms). You ask why anyone would want more than 7 partitions in a single slice? and this gets to the nature of the solution, that FreeBSD supports more than one disklabel, each located in different slices. That could have been the solution, but no one presented the whole concept (there were a bunch of things said that made no sense at all, so maybe someone referred to this with an assumption I already knew how FreeBSD worked).
Thanks for the invite. Next time I'll stop by there first. Hell I might even do so without a question just to say hi.
I hope that when I ask a question, and someone knows that the answer does happen to be in a certain document, and realizes that these things can be missed, they would simply say where to find the answer.
There are lots of things about BSD I don't remember, or never learned, when I used it many years ago (because I wasn't really doing all that much with it at the time). When reading documentation there are two ways to go about it. One is to read it sequentially like a book. This takes longer the bigger the documentation is (The FreeBSD Handbook looks like about 6 to 12 hours worth) and of course lots of gritty details get forgotten. Another is to try to match your own interpretation or wording of a concept with the index or table of contents. Sometimes that works and sometimes it fails. And then, even when you get to the right part of the document, the details simply go unnoticed because the wording is too BSD-ish (not unexpected in a BSD document, right).
I'm very much a help-myself kind of person. Rarely would I ever need to ask someone for help. But what is useful is good, well organized, technical info. Usually the answer I look for is very succinct. Too often what I get isn't (even in the Linux community).
FreeBSD may be better than Linux for what it tries to be (which is a lot).
After a failed install of FreeBSD 3.1, I now have FreeBSD 4.2 running, though with a slight bit of trouble. However, 3.1 was a disaster, not because of the software problems that prevented it from being installed, but because of the attitude problems I encountered asking questions about it to resolve the problems. It is because of that I cannot choose to go with FreeBSD for project where it does seem to be technically superior.
As in the commercial business software sector, the free open software sector needs support, too. And FreeBSD is more lacking in this area than Linux is (though both certainly are), at least from the perspective of someone like myself who is already more familiar with Linux. Support for free open software comes online in places like IRC (analogous to an 800 code toll free number for fast responses to simple questions), USENET, and various mailing lists. However, I found all of these had lots of people with attitude. As expected, IRC was the worst.
Case in point. FreeBSD 3.1 didn't install on my system and stopped at an error message saying it could not find the CDROM (but it booted from it, and Linux, OpenBSD and Windows used that CDROM just fine). Lots of people said my hardware was broken (it was not). Lots more people said FreeBSD didn't support ATAPI CDROM on the IDE secondary master and followed that up with reasons why not, such as it was in violation of the standards (I went and looked, and no it is not). Ultimately it turns out the FreeBSD kernel works fine with such a CDROM; it was the installer program that failed. By the time I did find out, I was so disgusted by the people, I decided to not finish doing the install.
I came back with the release of 4.2. I ran into a simple problem and I immediately knew a way around the problem. But I wanted to avoid that workaround if I could. The problem was I had planned for 8 partitions, but disklabel only let me do 7 (partition "c" not counted). I asked on IRC if this was indeed a real limit or if there was a way to work around it. I had lots of wrong replies, including one person who said that was a limitation of SCSI (odd, since I'm using IDE). The most common was that my hardware was broken. Lots of people replied "I installed fine with one partition" even though I never asked "How many partitions did you install with?". Eventually, about an hour after I first asked, and 3 channel visits later, one person (thank you Metrol) finally provided me with documentation that showed there was indeed such a limit. So I went and changed my strategy to accomodate the limit (including a re-install of OpenBSD the same way since I was comparing these). But it left me with a renewed disgust for the FreeBSD community.
Read the article. The asteroid would pass by earth twice.
Get a clue.
My postman doesn't make me sit there and open all my mail. I don't get deluged with 20-30 pieces of junk every day on paper. What the postman brings isn't going to expand exponentially because the sender pays to have it sent, whereas spam is paid for by ripping people off. My bandwidth is used up when POP3 downloads the junk before I get to see it. Bogus subjects mean sometimes people click on it to read it anyway so just clicking delete still means time wasted.
And yes there is a way to stop telemarketing and I've done it already. And there is a way to stop SPAM and congress doesn't even need to get involved. You just hate it because we cut off so many of your relays.
Closed bug reports only work with closed source. It's just a matter of time before Vixie closes BIND, or at least the leet version of it that members get to use.
Combining open source with closed information is what will fail. The only way closing the bug reports works at all is if the source is also closed. Otherwise l33t cR4q3rz who can read source can find bugs and distribute exploits (w/o NDAs), and admins who can't (read source) won't be able to fix things, all the while the members get to sit on their own lazy asses because they got them covered.
Zebbers makes it so clear and basic why open source is the right way to go and incompetent administrators should be fired.
Many ISPs do verify first. Stolen ones are generally good for a month or so. And their scams net them a few more credit card numbers of dumb people each time they spam.
So tell us ... what company has a stupid boss? What company should we avoid?
They want to. But there's no control over the junk coming in unless you use things like RBL and ORBS. Yet you have another vocal group of whiners that try to destroy all that and further promote spamming while giving lip service to idealistic TCP/IP.
Over the years I've collected a few string functions I've written. I'm starting to write some more, and I'll be releasing the library in the next few months. OK? Tell me what kinds of functions you'd like to see in C.
Languages don't make buffer overflows, programmers do.
Some people, including myself in the past few years, don't code in buffer overflows. I have never coded a message constructor with sprintf() like that. I haven't used gets() that I can recall. And I cannot remember when I ever did do any input without checking buffer size. I've been coding in C since '82 as well.
C and C++ are as strong and secure as the programmer who writes in them. Do the developers of Perl and Python put C/C++ coded buffer overflows in their code? I'm quite sure they do not.
Interesting. Perhaps it is easier to administer. But I hope it isn't as hard to do a startup as qmail was with daemontools. I hope it doesn't have as many processes running as qmail did. And I hope it uses no more than a single userid. As for configuration, it looks like it's command oriented while I prefer file oriented (e.g. my own scripts generate all the files from data stored elsewhere anyway). But this operates in a total replacement mode since they can't really determine incremental changes reliably. I should be giving it a try in the next couple of weeks.
If all the NDAs stipulated a finite time period of not more than 7 days, allowing anyone to release the information at that point, then I would believe you. 7 days is plenty for a vendor to get their act together. In fact 1 business day is enough, really. But I'll allow for 7 given that there are always stupid managers getting in the way of real work.
Instead, this is a means to allow Paul Vixie to cover things up while he doesn't make much effort to fix it. Someone who continues to release known bad programming methods isn't likely to be very adept at rapidly fixing exploits anyway. And this secretive approach only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught.
Why do you get to decide what kind of interface I have to work with? Most of the user interfaces out there suck.
However, I don't agree with Raskin, either. And OS *can* let users change their interface and still give a good API abstraction to applications to work with most user interfaces. Too many (e.g. Windows) don't do the right thing. Mac isn't very great for that, either.
There are TWO reasons why BIND gets exploited. Number one is that a fix to an exploit is not made available. Number two is that administrators don't upgrade to install fixes to exploits. What Paul Vixie wants to do is make sure both reasons work to ensure thousands of exploitable DNS servers around the world.
People like Paul Vixie should know better than to use functions like sprintf() to construct messages. Why are these problems happening over and over? And what other problems will the code have that isn't necessarily a security issue, but can cause problems? I find BIND does a lot of bizarre and strange things at times for no apparent (or logged) good reason. I am more and more untrusting of Paul's coding practices, and even his system design.
DJB's code may be secure, but it's a pain in the arse to administer. And that in itself is a security risk waiting to blow.
As most of us know, "Security isn't a thing; it is a process" [Schneier]. Administration is a very critical link in security... as critical as the code, if not more so. When administrative procedures and tools are clear and easy to use, fewer mistakes happen. Turn that around and you get more mistakes that can lead to security exposures, even for very experienced and security conscious administrators.
I switched from Sendmail to Qmail over a years ago. While I didn't regret it, I did experience difficulties in administering it. While I got some help, I also got a lot of "read the source" responses. Those responses were cop-outs. Even though I have 19 years C coding experience, I found DJB's code hard to read, and his organization non-obvious. And there were no comments to explain it. The source code was essentially useless as a resource for administering Qmail.
I looked into changing again, and studied Exim and Postfix. I decided to go with Postfix for some reasons not really related to any problems I found in Exim. I certainly do not regret this change. It is much easier to administer than Qmail. And unlike the Qmail community, I haven't yet run into anyone in the Postfix community that cops an attitude when there is a disagreement.
I am aware of DJB's security concerns about Postfix. But I consider the tradeoff to shed the security problems of administration difficulties to be worth making the move over to Postfix.
This is why I'll be reluctant to immediately move to DJBDNS, though I can certainly say I am tempted to give it a try.
Why are they concentrating so much in a single box like that anyway? Why not a few separate smaller boxes?
I used to work in a place that stored about 20 terabytes of certain documents it worked with, which varied in size from 1K to 5G each. Median size was about 40M. All the meta data, like what customer it applied to, dates of processing, and so forth, were stored in a database. But the actual document file never was. The network path to the document was in the database, but the documents were stored on hundreds of Novell (ick) file servers. The database was still the major bottleneck of the whole operation. All these wonderful database facilities like SQL don't mean squat when the main functionality was to get the document, process it, and store it back, which is what happened most of the time. Of course it was nice to have the SQL when you needed to manually check on things or do some odd searches. But I would never store bulk data in a database; only the pointer to it would go in there. Databases are faster at complex searching, but not at bulk delivery of data.