sh(1) is Bourne shell. We call it "Bourne" shell because it was originally written by Steve Bourne. As it was originally named simply "sh", when distinguishing between sh(1) and the other shell (csh(1)) was necessary, one referred to sh(1) as being "Bourne Shell". Things got complicated with Korn Shell, then Bourne Again Shell, etc, etc.
FreeBSD's sh(1) is compatible with the original Bourne shell, but has many features of korn shell. It is not a ksh because it doesn't have the features that make ksh _incompatible_ with sh(1).
Alas, with POSIX standard to guide one by, these days, maybe we are not actually 100% compatible with the original bourne shell, but...
Err, no. You go through the annoying fetch/"I accept" process once, "make package" on one machine, put the resulting files in a ftp or web server, and then pkg_add from each machine.
Then again, your experiences are rather singular, or rather a matter of taste. But if it was not for you then, for the reasons you mentioned, it is not for you now.
Err, no, not "wait for a few months". They have to make available a progress report each seven days, detailing what progress was made since the last report, what they'll be doing next, and other information.
If communication breaks down (you say "You are not taking it seriously", they say "Yes, we are", you say "No, you're not", etc), the process stops, you disclose the vulnerability, and that's it.
Only if they are seen to be making real progress in addressing the vulnerability you'll stay with the process.
BTW, it mentions the user in some parts of the document, like the part about giving the user enough time to update their software (for which the vendor must provide automated tools, btw) before you tell all the idiot script kiddies in the world how to fuck him up.
Yes. Except if vendor does not think it is a vulnerability, if vendor fails to obey the deadlines, if communication between you and vendor breaks down, if the flaw becomes actively exploited or if the flaw gets otherwise published, in which case you can release full details immediately.
Then again, you only read what you wanted to read, didn't you?
Good. What are you complaining about? Didn't you see the part that says you are free to disclosure whatever you found if the company does not think it is a security flaw?
Where the HELL did you find any anti-disclosure in there? First of all, that document details a _process_, in which vendor and finder (of flaw) act together to overcome a security flaw.
It details how can a finder contact the vendor, give firm deadlines on response time from the vendor, how the interaction between finder and vendor goes, assures the finder that something Is Being Done, and protects the user from disclosure of a flaw for which there are no fix.
It answer things like "What if vendor and finder cannot agree on whether a flaw is a security flaw?" and "What if vendor thinks it has fixed the flaw but finder disagree?"
What it *DOESN'T* do is prevent disclosure.
If communication breaks down -- if finder and vendor simply cannot agree, the process simply stops. If the process has stopped, the finder can go right ahead and do anything they want.
Once the process is finished, the finder can go right ahead and disclosure anything they want.
The finder should only avoid disclosing the flaw when the process is working: he is satisfied with the feedback from the vendor, no fix is yet available, and no exploit or disclosure of the flaw is available on the internet.
Since the only result of a disclosure in such a situation is help crackers against defenseless users, no reasonable person can object to that.
So either whoever chose that title hasn't read the document, or he is more fond of wracking destruction and financial damage to the helpless. In the first case, he is an idiot, in the second, he is an asshole.
Heh. I happen not to have such books around, but I have always been interested in such subjects. Now that you mention it, I'll probably go and actually buy books on the subject.:-)
Here, when we tested a new electronic voting machine that registered all votes in paper (and allowed you to see your vote "paper trail" through a small window), people found it MUCH worse than the system used in the previous election (and much of the rest of the country in that election).
Me, I think it was because the ads teaching people how to vote in the old machines were displayed nation-wide, *including* the places where the new system was used.
First, if an e-mail is not delivered, the recipient receives a notice of the fact, as long as he is properly identified as the source of the e-mail.
Second, I have had a number IP addresses in our range blocked by a whole host of different DNSBL, for many different reasons. The *ONLY* blacklists I never got removed from were those which block ranges for a whole region (like South America or Brazil).
Moreover, the process might take two or three days (though it's seldom more than 24 hours), but it's always VERY clear.
That article reads more as a pro-spam article in disguise.
RFC1042 says "When necessary, the data field should be padded (with octets of zero)to meet the IEEE 802 minimum frame size requirements."
RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
Well, check out Sharon Lee and Steve Miller. Start with Partners in Necessity, an omnibus version of the first three books that is easier to find than it's components.
Or you can try (suprise!) David Weber and John Ringo (either alone or in collaboration).
David Weber, in particular, managed something that really impressed me. He became my favorite science fiction author (a title Asimov, Clarke, Jerry Pournelle and Larry Niven fought over for a long time). Though he only has one book in my all-times-best list (Path of the Fury), the only thing he ever wrote that I don't care much for is the Dahak series. And there is *NO* book out there that I have *EVER* heard that beats Honor Harrington in space combat.
Agreed. And though Honor is very good, I think Path of the Fury and, maybe, Apocalypse Troll beat any book on the Honor Harrington series by itself (the fact that HH _is_ a series adds something to each book, though).
As for fantasy, the Bahzel books are easily among the best fantasy out there.
cd/usr/src make update && make buildworld && make kernel && mergemaster && reboot cd/usr/src make installworld portupgrade -a
That updates *everything*, from docs to/bin/ls, on a FreeBSD machine. It assumes you have a/etc/make.conf appropriately configured (as in, uncomment the example lines), that you have cvsup and source installed and that you have internet connection.
It takes a rather large number of steps because there are a few places where you must make SURE everything still works, or you may end up with an unusable systems.
Let's dissect it a bit.
/usr/src is the place where FreeBSD, the base system (as opposed to all the third party programs out there), is located.
"make update" in this directory will call cvsup, a program that will check out a mirror of your choice on the Internet and download the diffs (instead of the whole files) for the whole FreeBSD source tree, FreeBSD documents and the ports tree. It need not download *all* of this, it's configurable.
"make buildworld" compiles everything in the base system but the kernel and kernel modules. It does all the right things too, like first compiling a C compiler before compiling the C compiler.:-)
"make buildkernel" compiles kernel and kernel modules. It uses the stuff compiled in the step before, so you get a kernel compiled with the latest tools even before you install them.
"mergemaster" deals with/etc in a controlled fashion. It compare your files with the ones in the source, and those which were updated (infered from the CVS Ids) have their diffs displayed to you, and you have the option of installing the new, keeping the old, or merging the two of them selectively (as in, you control what and how).
Though FreeBSD takes some pains to make this process painless, like having default configuration files and user configuration files, there's always exceptions (like the groups and password files).
"make installkernel" installs the new kernel and modules. It keeps a copy of the old one.
"reboot" reboots.:-) FreeBSD does not have to deal with LILO pains. If the new kernel is broken, all you have to do is interrupt the count-down and type "boot kernel.OLD" (or whatever other kernel name you may have chosen).
If the new kernel works, you may install the new "world" without fear (some of the programs might be using features only present in the new kernel, which would have caused you problems if you installed world first). "make installworld" does that.
Finally, "portupgrade -a" upgrades every port you have installed, dependencies first, and installing any new dependencies as necessary. Port's magic is rather complex, and there are whole articles on the internet about it. But it just works, so you don't have to concern yourself about it.
Note that all of this is compiled according to the options you put in/etc/make.conf.
Slashdot Mirror
Meanwhile, The Register reports that in one place in Asia where WiFi *is* widely spread, they gave up on it and went 3G.
"then there is nothing to prevent them from doing the same the FreeBSD"
Yes, there is. The settlement between AT&T and Berkeley. The question has already been settled.
sh(1) is Bourne shell. We call it "Bourne" shell because it was originally written by Steve Bourne. As it was originally named simply "sh", when distinguishing between sh(1) and the other shell (csh(1)) was necessary, one referred to sh(1) as being "Bourne Shell". Things got complicated with Korn Shell, then Bourne Again Shell, etc, etc.
FreeBSD's sh(1) is compatible with the original Bourne shell, but has many features of korn shell. It is not a ksh because it doesn't have the features that make ksh _incompatible_ with sh(1).
Alas, with POSIX standard to guide one by, these days, maybe we are not actually 100% compatible with the original bourne shell, but...
If you doubt me, just google it.
Err, no. You go through the annoying fetch/"I accept" process once, "make package" on one machine, put the resulting files in a ftp or web server, and then pkg_add from each machine.
No, no, no, no!!! You got it all wrong! It's *FreeBSD* who is dieing!
Sheesh, can't people get even trolls right these days?
Nope.
Then again, your experiences are rather singular, or rather a matter of taste. But if it was not for you then, for the reasons you mentioned, it is not for you now.
Which would be so bad with the deal that settled AT&T suit against BSD... :-)
Err, no, not "wait for a few months". They have to make available a progress report each seven days, detailing what progress was made since the last report, what they'll be doing next, and other information.
If communication breaks down (you say "You are not taking it seriously", they say "Yes, we are", you say "No, you're not", etc), the process stops, you disclose the vulnerability, and that's it.
Only if they are seen to be making real progress in addressing the vulnerability you'll stay with the process.
BTW, it mentions the user in some parts of the document, like the part about giving the user enough time to update their software (for which the vendor must provide automated tools, btw) before you tell all the idiot script kiddies in the world how to fuck him up.
Yes. Except if vendor does not think it is a vulnerability, if vendor fails to obey the deadlines, if communication between you and vendor breaks down, if the flaw becomes actively exploited or if the flaw gets otherwise published, in which case you can release full details immediately.
Then again, you only read what you wanted to read, didn't you?
Good. What are you complaining about? Didn't you see the part that says you are free to disclosure whatever you found if the company does not think it is a security flaw?
Go and read the F*ING document, you idiots!
Where the HELL did you find any anti-disclosure in there? First of all, that document details a _process_, in which vendor and finder (of flaw) act together to overcome a security flaw.
It details how can a finder contact the vendor, give firm deadlines on response time from the vendor, how the interaction between finder and vendor goes, assures the finder that something Is Being Done, and protects the user from disclosure of a flaw for which there are no fix.
It answer things like "What if vendor and finder cannot agree on whether a flaw is a security flaw?" and "What if vendor thinks it has fixed the flaw but finder disagree?"
What it *DOESN'T* do is prevent disclosure.
If communication breaks down -- if finder and vendor simply cannot agree, the process simply stops. If the process has stopped, the finder can go right ahead and do anything they want.
Once the process is finished, the finder can go right ahead and disclosure anything they want.
The finder should only avoid disclosing the flaw when the process is working: he is satisfied with the feedback from the vendor, no fix is yet available, and no exploit or disclosure of the flaw is available on the internet.
Since the only result of a disclosure in such a situation is help crackers against defenseless users, no reasonable person can object to that.
So either whoever chose that title hasn't read the document, or he is more fond of wracking destruction and financial damage to the helpless. In the first case, he is an idiot, in the second, he is an asshole.
So what? The code *is* copyrighted. It's just that GPL does not apply, because *they* didn't say it was released under GPL.
Heh. I happen not to have such books around, but I have always been interested in such subjects. Now that you mention it, I'll probably go and actually buy books on the subject. :-)
Except that EDOOFUS means "I (the guy who committed this code to the kernel) made a mistake -- you should never have received this error."
Here, when we tested a new electronic voting machine that registered all votes in paper (and allowed you to see your vote "paper trail" through a small window), people found it MUCH worse than the system used in the previous election (and much of the rest of the country in that election).
Me, I think it was because the ads teaching people how to vote in the old machines were displayed nation-wide, *including* the places where the new system was used.
That article is complete bullshit.
First, if an e-mail is not delivered, the recipient receives a notice of the fact, as long as he is properly identified as the source of the e-mail.
Second, I have had a number IP addresses in our range blocked by a whole host of different DNSBL, for many different reasons. The *ONLY* blacklists I never got removed from were those which block ranges for a whole region (like South America or Brazil).
Moreover, the process might take two or three days (though it's seldom more than 24 hours), but it's always VERY clear.
That article reads more as a pro-spam article in disguise.
Either that, or they are insane.
So, how many times are you going to repeat this story today?
Outrage! Let me start this thread so we brazilians can properly complain. :-)
RFC1042 says "When necessary, the data field should be padded (with octets of zero)to meet the IEEE 802 minimum frame size requirements."
RFC 2119 says "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
Well, check out Sharon Lee and Steve Miller. Start with Partners in Necessity, an omnibus version of the first three books that is easier to find than it's components.
Or you can try (suprise!) David Weber and John Ringo (either alone or in collaboration).
David Weber, in particular, managed something that really impressed me. He became my favorite science fiction author (a title Asimov, Clarke, Jerry Pournelle and Larry Niven fought over for a long time). Though he only has one book in my all-times-best list (Path of the Fury), the only thing he ever wrote that I don't care much for is the Dahak series. And there is *NO* book out there that I have *EVER* heard that beats Honor Harrington in space combat.
Agreed. And though Honor is very good, I think Path of the Fury and, maybe, Apocalypse Troll beat any book on the Honor Harrington series by itself (the fact that HH _is_ a series adds something to each book, though).
As for fantasy, the Bahzel books are easily among the best fantasy out there.
cd /usr/src /usr/src
/bin/ls, on a FreeBSD machine. It assumes you have a /etc/make.conf appropriately configured (as in, uncomment the example lines), that you have cvsup and source installed and that you have internet connection.
:-)
/etc in a controlled fashion. It compare your files with the ones in the source, and those which were updated (infered from the CVS Ids) have their diffs displayed to you, and you have the option of installing the new, keeping the old, or merging the two of them selectively (as in, you control what and how).
:-) FreeBSD does not have to deal with LILO pains. If the new kernel is broken, all you have to do is interrupt the count-down and type "boot kernel.OLD" (or whatever other kernel name you may have chosen).
/etc/make.conf.
make update && make buildworld && make kernel && mergemaster && reboot
cd
make installworld
portupgrade -a
That updates *everything*, from docs to
It takes a rather large number of steps because there are a few places where you must make SURE everything still works, or you may end up with an unusable systems.
Let's dissect it a bit.
/usr/src is the place where FreeBSD, the base system (as opposed to all the third party programs out there), is located.
"make update" in this directory will call cvsup, a program that will check out a mirror of your choice on the Internet and download the diffs (instead of the whole files) for the whole FreeBSD source tree, FreeBSD documents and the ports tree. It need not download *all* of this, it's configurable.
"make buildworld" compiles everything in the base system but the kernel and kernel modules. It does all the right things too, like first compiling a C compiler before compiling the C compiler.
"make buildkernel" compiles kernel and kernel modules. It uses the stuff compiled in the step before, so you get a kernel compiled with the latest tools even before you install them.
"mergemaster" deals with
Though FreeBSD takes some pains to make this process painless, like having default configuration files and user configuration files, there's always exceptions (like the groups and password files).
"make installkernel" installs the new kernel and modules. It keeps a copy of the old one.
"reboot" reboots.
If the new kernel works, you may install the new "world" without fear (some of the programs might be using features only present in the new kernel, which would have caused you problems if you installed world first). "make installworld" does that.
Finally, "portupgrade -a" upgrades every port you have installed, dependencies first, and installing any new dependencies as necessary. Port's magic is rather complex, and there are whole articles on the internet about it. But it just works, so you don't have to concern yourself about it.
Note that all of this is compiled according to the options you put in
HTH. HAND.
Talk about reinventing the wheel, eh? :-)
Not sure if it would be worth your time trying FreeBSD. But if you do, PLEASE get rid of LILO! :-)