MySQL uses Coverity and Klockwork on their certified versions on several different platforms. The certified versions are based on the major releases of community versions, and are typically just more conservative in that they only make changes for critical and security bugs.
There's speculation that the community edition tested was actually an old report without a retest even back then, as the certified version based on that community version had zero defects reported and the bug count on the community edition was the same per TLOC as the previous report before those bugs were fixed in both versions.
Most Ethernet cards aren't "mostly soft". The network stack is, well, a stack. The physical layer and link layer are usually handled by the card. The stuff above that might be handled in firmware or a driver, but I'd rather not have IPv4 shove onto my Ethernet card as the only option. Some cards have gone soft to cut costs, but mid to high end cards are all hard. High-end server cards often have IP acceleration built in, but leave other options open.
There are numerous refutations to your "never suggested that publishing their design or secrets would lead to better security". Many experts have said precisely that.
An IT Security article on full disclosure states that as early as the middle of the 19th century locksmith Alfred C. Hobbes thought full disclosure was important to clear up the rash of lock picking people were experiencing. It goes on to discuss exactly why full disclosure works so well.
Bruce Schneier -- yes, THAT Bruce Schneier -- has an article on his blog that starts "Full disclosure -- the practice of making the details of security vulnerabilities public -- is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure."
Is that enough or do I need to go to the second page of this Google search?
BTW, DJB thinks that both full disclosure and isolation of trusted components are absolutely vital. He's the guy who won the right for Americans to export cryptography technology in court against the Department of Justice. He also found a timing attack against OpenSSL's AES cipher and his Unix Security Holes class of 16 students turned up 91 previously unknown holes in one semester.
As for "Security by design", that helps. However, with many programs being written in languages which allow null pointers, stack overflow, buffer overflow, and array overflow the design can be as secure as you want and the program can still be crashed. In some cases arbitrary code can still be executed. Address randomization, NX bits, run-time bounds checking, and automatic memory management can go a long way. Sanitation of inputs, static analysis, time padding, and more still have to be considered in some cases.
The tests Coverity is running are an example of static analysis. If there's a C routine that can be coerced into smashing the stack or overflowing a buffer in the heap, that can often be automatically caught and reported. Memory leaks often can be, too. They're probably also able to do at least rudimentary checks for sanitizing input values.
There are industry estimates that say average code in production contains 2 bugs per thousand lines of code. Some say that number is much higher. How many lines do you think are in Vista?
Yes, OSS has bugs. Everything from compilers to content management systems, surely. So do proprietary programs.
The more qualified eyes you get on a bug, the better chance you have of finding and fixing it. You can do that by having a big staff that pores over code again and again. You can do it by having lots of outside help, like in the case of popular OSS projects. One thing that helps is to have a fresh set of eyes look over something, which is much easier in OSS that in closed-source applications.
BusinessWeek had an article from a guy at Coverity back in 2006 about this. In that article, Ben Chelf said that 4 of the top 15 programs on the quality scale measured by defects per thousand lines of code were OSS. He said that on average, the major-project OSS software they tested was indeed higher quality software than average. He said, though, that the absolute highest quality code was the cream-of-the-crop proprietary, closed source code from places that make things like fly-by-wire systems. Well, yeah. I'd want my airliner's fly-by-wire system completely bug-free, too.
Commercial software tends to harbor anywhere from 1 to 7 bugs per 1000 lines of code according to the National Cybersecurity Partnership's Working Group on the Software Lifecycle. Voluntary testing by Coverity requested (and probably paid for) by MySQL AB revealed that project to have all of 97 flaws, one of which could be a serious security issue. All 97 were to be fixed for the next release.
A similar study (same link) found 985 bugs in over 5,700,000 lines in the Linux kernel, or fewer than one bug per 10,000 lines of code. TFA has data on a newer version of the kernel -- 0.127 bugs per TLOC.
In Apache, 22 bugs total, 0.14 per TLOC, and three fixed so far.
PostgreSQL had 0.041 per TLOC, and have so far fixed 53 of the 90 bugs.
The glibc team fixed 83 of 83 bugs found.
OpenVPN had found one security-related bug in over 69,000 lines of code. As of later yesterday, it's officially security bug free according to the same testing people.
So with Linux (0.127), glibc (0.000), Apache (0.140), PostgresSQL (0.041), Perl (0.024), PHP (0.000), and Python (0.000) powering a web server (numbers according to Coverity), you have 0.0474 defects per thousand lines of code across the server. I'd say that's pretty good.
I haven't done much reading, writing, or speaking in French for about 13 years, but I can pick out a couple. To the far left in front is apparently acetone. The last one on the right in front is either "acide chloridrique" or "acide chlorhydrique", which would be either chloric acid or hydrochloric acid.
The one labeled "eau..." is water of some sort ("eau" being "water"), but I'm having trouble picking out just what sort. The label wraps around and looks like the adjective starts with "denin", but maybe it's "demin". I can't think of anything nor find anything that starts with "denin". Perhaps it actually starts "demin" and is "eau déminéralisée", or demineralized water. That makes sense.
Other types of water, for the curious... Permuted water is "eau permutée". Distilled waster is "eau distilleée". The first instinct as an English-speaking American with limited French would be to say "eau dénaturée" for denatured water, and Babelfish thinks that's right, too. Deionized water would be "eau désionisée". So I'm pretty much out of ideas for types of water to translate.:-)
BTW, the section title "C'est l'heure de bain" means "It's time for a bath" or "It's bath time". (More directly, "It's the hour of the bath", but that of course sounds really awkward.)
Re:We need this type of thing done in the classroo
on
Hand-Made Vacuum Tubes
·
· Score: 1
I'm pretty sure it was a joke. That's the obsessive hobby of many a slashdotter.
I did it so I could award $100 to the first person who asked me why I wrote so much. However, since you're an anonymous troll, your winnings can't be verified. Sorry.
I think he said that he personally has no problem with what Tivo does. I don't think he has a problem with a license not allowing what Tivo does, as long as he's free to not move to that license. So yeah, it could be that one of his reasons for not wanting to move to the GPLv3 is that he supports what Tivo's doing.
Personally, I think having different licenses for different camps with different views is great. I just don't think the GPLv3 is what many developers licensing code under GPLv2 consider to be an improved GPLv2. I think it strikes a lot of people as trying to go too far or go in a different direction. I'm not opposed to the GPLv3 for people who want to use it. I'll probably contribute code to projects that use it. I probably won't use it for any of my own projects (not that I'll change any lives in that decision, because none of my projects ever get spread around much). If people asked Linus about it in those terms rather than being so confrontational about things, he might say the same.
I tend to think the separation between the transport and the authentication is a good thing. I had been using PAM and a firewall, but if I ever need such security again I'll be looking into the pam_abl module another poster mentioned.
Now they're registering attacks on their competitors!
Visit AboutUs.org for more information about GODADDYCOMMITSFRAUD.COM AboutUs: GODADDYCOMMITSFRAUD.COM
Registrant: This Domain is available at NetworkSolutions.com 13681 Sunrise Valley Drive, Suite 300 HERNDON, VA 20171 US
Domain Name: GODADDYCOMMITSFRAUD.COM
This Domain is Available - Register it Now! 600,000 domain names are registered daily! Don't delay; there's no guarantee that a domain name you see today will still be here tomorrow! Register it Now at www.NetworkSolutions.com.
Administrative Contact, Technical Contact: Network Solutions, LLC domainsupport@networksolutions.com 13681 Sunrise Valley Drive, Suite 300 HERNDON, VA 20171 US 1-888-642-9675 fax: 571-434-4620
Record expires on 08-Jan-2009. Record created on 08-Jan-2008. Database last updated on 8-Jan-2008 17:58:30 EST.
The.tv domain name is a country-code top-level domain name (ccTLD). It's for the nation of Tuvalu. The government of Tuvalu contracted with Network Solutions to manage the WHOIS and registration for it. Last I read about it, the.tv domain name was the leading export in monetary value of the whole country.
You can register a.tv domain through a large number of other registrars. Register.com and for example allow you to register through them.
If you think the government of Tuvalu should be maintaining their own national registry, I implore you to take up a collection and found one for them. They're not going to give up the revenue to suit you, and it's their right to choose who they want to pay to administer it.
Considering that most people check a few then register the one they like best out of those available it's detrimental to business to make those people wait four days, isn't it? The frontrunners would be more likely to script up a batch every day of the results from four days ago than the individuals would be to come back and register something NSI took off the available list.
It's also poor practice for NSI to keep me from searching on NSI then deciding to register with GoDaddy, Register.com, Dotster, or SRSPlus. That's especially true since I have an SRSPlus domain reseller account but hate their domain availability checking interface, and SRSPlus is owned by NSI. Perhaps I should resell for someone else instead, and move all my existing domains. I might on principal.
Any time you see the word "should", it means the writer thinks that's the way things ought to happen. It doesn't mean the writer thinks that's the way things are currently happening, or the way they are going to happen. Perhaps it's you who just doesn't understand.
Your equation works well if X and Y are well chosen. However, how, logically, does the imposition of "no trusted kernel signing" further the freedom of "everyone gets to see the source", unless as I already mentioned you don't trust it's the actual source? How, logically, does "can't use it with a DRM system although the source and the DRM source are open and free" defend the freedom of "everyone gets to see the source"?
The FSF isn't the "Anti-DRM League". It isn't the "Open Source Code and Limited Applicability of Our Software Organization". It's the "Free Software Foundation". It should be promoting the freedom of the software. That's because honesty is typically considered a good thing.
What right to free use of the software isn't covered by the GPLv2? I keep pointing out the fallacies of your argument, and you keep quoting portions of my posts out of context and skirting the issue. The specific freedoms the FSF should be protecting are those it has been claiming to champion for so many years. Again, that's because honesty and integrity should mean something.
I am not naive. I may be wicked, depending on whom you ask. That has nothing to do with the fact that people are supposed to fight for what they say they're supporting, and not for something else entirely. In fact, most people would consider the opposite wicked.
The GPLv2 was the definitive document on Free Software for all practical purposes until GPLv3 came along. The FSF's manifesto documents aren't binding, and those aren't what most people outside the FSF used to consider how to license their code. If it was Free according to the GPL, it was Free Software. Linux, therefore, was Free Software. Now that some people are trying to say that GPLv3 is "Free" and GPLv2 is "not Free", they're saying Linus hates free software. It's a terribly specious argument. The GPLv2 hasn't changed. The people using it who don't want to go to the GPLv3 haven't changed. They still support GPLv2.
Until you admit that other people have other valid opinions, you're going to go nowhere in discussions like this one.
Actually, the parent post and my comment in response were actually as much spoiler as what came after, and you still have no idea from all of it together about the main plot of the film. It's a pretty good one for geeks, so I'd recommend it. I own a DVD (yes, a legit factory-stamped one) of it and pull it out about every 4 months.
It is clear you're an accusatory and condescending ass. That's what's clear. Because someone disagrees with you is no reason to say they don't understand an issue. If everyone agreed, there wouldn't be an issue to discuss and no licenses pointing out the differences would be necessary. Come down off your high horse if you want to continue the subthread, please.
Why is a developer of something with open source code any more privileged than the end user? That's the whole point of the source code being available.
Furthermore, why is the manufacturer of a particular piece of hardware more privileged than the end user? The end user has every right not to buy that brand of hardware. The only real disadvantage the end user has isn't that the hardware in non-free. It's isn't even that they can't run their update kernel on the proprietary, sealed hardware without modifying the hardware. It's that without being able to decrypt the OS and then uncompile it, or to be able to run it in a sandbox, that they can't be sure the compiled kernel is really the same as what the manufacturer supplies as source. If Linus pushed the matter of making them prove it's the same, he could probably witness the signing of it and vouch for them. Otherwise, the very act of distributing a signed binary is counter to the requirement to provide the real source. However, if you have that little trust in the vendor, why would you buy their hardware, as it could be doing any nefarious thing too?
When someone calls themselves the "Free Software Foundation", they should be limiting the free use of the software as little as possible to further its greater freedom. The GPLv2, for all its perceived flaws, does that pretty well. To say something is free software, but that it can only be used in this or that way by people who agree with the whole political platform of the foundation is frankly blatant hypocrisy. What good is it to the end user to have the source code if they're not allowed to run the software? How is that keeping the privileged developers and members of the FSF from limiting the freedoms of end users?
Why is it a problem that Linus doesn't agree with the FSF altogether? Is complete agreement with the FSF prerequisite to abhor slimy, lying, monopolistic, closed-source Unix vendors? Is it important to carry an FSF card to think that cooperating with other developers around the world can produce something better than what's being pushed by the innovative marketing department at Microsoft? Linus chose the GPLv2 because what RMS codified in it made a lot of sense to him and to many other people.
It might help you to remember that RMS and the FSF are the ones who have changed position. The people who are sticking to the GPLv2 are doing exactly what the FSF asked of them up until a few months ago. Now, the FSF wants to ask them to change. Why is it that Linus or anyone else is being called anti-FSF when it's the FSF that has changed direction?
The FSF used to always say that if you liked the GPLv2 even enough to consider it, that it was better to use it and stand united as a Free Software community than to splinter off new and slightly incompatible licenses. That's true, and Linus saw the wisdom in that. Now, the GPLv3 is a license other than the GPLv2 and it's causing a bunch of strife and incompatibility in the community. Many people in and adorers of the FSF think that because they wrote both licenses that everyone should just switch. However, they encouraged the use of GPLv2 by a much wider audience than their core group, and now they're trying to say there's some dogma attached to the licenses. The licenses are legal documents for men, though, and not handed down from on high and dictated to software developers by angels.
The FSF should be glad so many people are using the GPLv2 rather than BSD, MPL, or any of a hundred thousand closed-source EULAs. By bickering with people who support the major beliefs of the FSF but not the dogma and specifics, the FSF is alienating all the OSI crowd who never bought into a centralized repository of "free" software at MIT in the first place. These are the people they should be glad are on the same side, even if they're not in the same tent.
I thought for sure when your sentence started "BTW - habaneros aren't the hottest..." that it'd be another mention of jolokia, which is also hotter than the Red Savina habanero (and which is derived from the habanero family itself).
The Dorset Naga is definitely noticeably hotter than the Red Savina with that kind of Scoville rating. However, it looks like the record Jolokia is hotter still at slightly over 1 million Scoville units.
I'd never heard of the specific Dorset version of the pepper. I'll have to see if I can get my hands on some.
For readers curious, the Scoville scale is based on how many parts of plain sauce can be mixed with the rated item without masking its hot, spicy taste. It was originally left to a panel of taste testers, but now it's measured as a proportion of the capsaicin in the item rated.
A warning for the foolhardy, too... Extracts are the fastest way to extra pungency, but pure capsaicin needs to be handled with real care. It's available on the open market, but it can cause damage to the skin or eyes and can trigger asthma attacks or even kill a person.
I used to run a network with an ssh-only server. All it had facing the world as an actual service was OpenSSH's sshd on a fixed nonstandard port. It also had two fixed and four randomly hopping honeypot ports that added any/24 network that hit them to a 24-hour firewall DROP rule.
Once someone logged into that server using their own key or pass phrase, the only command they could run was ssh. All the other servers in the network only allowed ssh in from that ssh box, and by policy their keys and pass phrases had to be different on the ssh server than on the internal boxes. Each failed attempt at logging in caused a 5-second wait, and after three a 12-hour wait.
Is it as secure as having the real port hop around and synchronizing that with the clients via a shared secret? Well, I guess that depends on just how secret the shared secret is. We never had any problems, though, and the only thing our people had to take with them were the name of the server, their private key or passphrase, and the proper port to use. They usually didn't have much problem remembering three of those, and the you have the same issue with private keys no matter what (that being that they're only as secure as the system on which they are stored).
There's probably some security advantage to the solution presented in TFA, but I'm just not sure it's worth the extra coordination hassle compared to people's home-grown solutions. It seems like every fifth post in the comments is about alternative ways to safeguard ssh ports. Surely not knowing which someone is using provides a bigger hurdle than getting past any single one of them. When you're practicing security by obscurity, which is what this really boils down to, then being more obscure is probably a good thing.
The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.
I concur. A good way not to stress a public NTP server is to set up a private one. You also get closer synchronization over a LAN than over the public Internet. It also reduces your vulnerability profile if only one server makes the connection to the outside, and the rest only connect to it for time. Having a second for fail-over might be wise if it's really important, but if all you're running on a server is NTP then you're probably down to just hardware failure to worry about.
Any server you have that's not fully maxed on load and that can handle the quite small additional security risk of serving NTP to the local network only would be fine, or you could use an old Pentium 100 or such that does nothing but serve NTP.
The local NTP server grabs its update every day (or every 12, 8, 6, or 4 hours) from the public server. There's really no need to hit the public time server too often because you're mostly concerned with synchronization within your network anyway. You can then sync your local machines all to your private NTP server as often as you like, even down to once a minute if you're really that concerned. Using ntpd should work better since it adjust the system clock according to past skews and gets better over time. Using ntpdate would be passable if you run it often enough that your skew isn't significant to your application, but ntpd is still better if you can stand running the daemon on each server.
My preference is to use an old machine to do nothing but get time from the net and provide it to the local network. I always locked mine down in every other way but allowing ssh in, and it only allowed ssh from within the local network. No ssh back out from it, no compilers, and more could be done if you're really paranoid.
There's also PTP for some applications that require better resolution than NTP. I'm not aware of many people actually using it on regular servers, though. Being synchronized within a couple hundred microseconds is usually more than adequate.
I like to think of Linus as a BSD-spirited guy who likes the source code openness of the GPL. He wants people to use the code for whatever, so long as they share their improvements. Many in the FSF camp want to limit not just what you can do with the source, but where and how you can run the binaries. I think there's a good argument that limiting some freedoms can protect others, but i also think there's an argument that the FSF limiting the free use of software is a bad precedent.
The problem here is that TiVo is serving two masters. They want to sell you the box, but it interacts with the content of the big, nasty, litigious mainstream media outlets. They don't want to sell you something you can easily use to violate copyrights, or at least they don't want to be known for that in courtrooms.
I'm not so sure it's sour grapes. I think Linus really likes the GPLv2 more than GPLv3. I think he's glad he can't track down all the authors of all the patches for permission to change it, because it takes some of the heat from GPLv3 zealots off of him.
I'll ask you the same question I ask everyone unhappy with "Perl's object system". Which object systems for Perl have you tried?
There is rudimentary object support (enough for many tasks when you're not in need of a full-fledged object system) based on blessed hashes with no enforced encapsulation. That's the one most people consider since it's been around a while and most of the older docs talk about it.
There are also a number of other object systems written as modules that are well supported by the community. Object::InsideOut is pretty popular. So is Moose. You can always just search CPAN for the word 'object' if you want to look at any others.
So they're using 5 control lines and have 6 unused chip addresses? I think the 13 * 64 is far more likely.
However, the company knows the economics of their own solution better than any of us, so they might have had the motivation to do something really odd.
I don't trust them either, but I'm often curious and nobody's going to fire me for opening them on this system. It sometimes entertains me to see what the trolls are linking and if I can help keep someone from losing a job by clicking absentmindedly, I think it's all worth it.
Slashdot Mirror
They did in 2006 and found about 0.224 defects per TLOC.
MySQL uses Coverity and Klockwork on their certified versions on several different platforms. The certified versions are based on the major releases of community versions, and are typically just more conservative in that they only make changes for critical and security bugs.
There's speculation that the community edition tested was actually an old report without a retest even back then, as the certified version based on that community version had zero defects reported and the bug count on the community edition was the same per TLOC as the previous report before those bugs were fixed in both versions.
Most Ethernet cards aren't "mostly soft". The network stack is, well, a stack. The physical layer and link layer are usually handled by the card. The stuff above that might be handled in firmware or a driver, but I'd rather not have IPv4 shove onto my Ethernet card as the only option. Some cards have gone soft to cut costs, but mid to high end cards are all hard. High-end server cards often have IP acceleration built in, but leave other options open.
There are numerous refutations to your "never suggested that publishing their design or secrets would lead to better security". Many experts have said precisely that.
An IT Security article on full disclosure states that as early as the middle of the 19th century locksmith Alfred C. Hobbes thought full disclosure was important to clear up the rash of lock picking people were experiencing. It goes on to discuss exactly why full disclosure works so well.
David Wagner says in an article on security: "Today, many security companies are strongly resisting this, and I think they will need to learn to accept and embrace public scrutiny as a natural and necessary part of security systems." -- David Wagner and Ian Goldberg are the ones who cracked the security of the SSL layer in Netscape 4.
IEEE article abstract stating that full source code access can have "real benefits for security", although that's not automatic and it has to be done correctly.
Bruce Schneier -- yes, THAT Bruce Schneier -- has an article on his blog that starts "Full disclosure -- the practice of making the details of security vulnerabilities public -- is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure."
Is that enough or do I need to go to the second page of this Google search?
BTW, DJB thinks that both full disclosure and isolation of trusted components are absolutely vital. He's the guy who won the right for Americans to export cryptography technology in court against the Department of Justice. He also found a timing attack against OpenSSL's AES cipher and his Unix Security Holes class of 16 students turned up 91 previously unknown holes in one semester.
As for "Security by design", that helps. However, with many programs being written in languages which allow null pointers, stack overflow, buffer overflow, and array overflow the design can be as secure as you want and the program can still be crashed. In some cases arbitrary code can still be executed. Address randomization, NX bits, run-time bounds checking, and automatic memory management can go a long way. Sanitation of inputs, static analysis, time padding, and more still have to be considered in some cases.
The tests Coverity is running are an example of static analysis. If there's a C routine that can be coerced into smashing the stack or overflowing a buffer in the heap, that can often be automatically caught and reported. Memory leaks often can be, too. They're probably also able to do at least rudimentary checks for sanitizing input values.
There are industry estimates that say average code in production contains 2 bugs per thousand lines of code. Some say that number is much higher. How many lines do you think are in Vista?
Yes, OSS has bugs. Everything from compilers to content management systems, surely. So do proprietary programs.
The more qualified eyes you get on a bug, the better chance you have of finding and fixing it. You can do that by having a big staff that pores over code again and again. You can do it by having lots of outside help, like in the case of popular OSS projects. One thing that helps is to have a fresh set of eyes look over something, which is much easier in OSS that in closed-source applications.
BusinessWeek had an article from a guy at Coverity back in 2006 about this. In that article, Ben Chelf said that 4 of the top 15 programs on the quality scale measured by defects per thousand lines of code were OSS. He said that on average, the major-project OSS software they tested was indeed higher quality software than average. He said, though, that the absolute highest quality code was the cream-of-the-crop proprietary, closed source code from places that make things like fly-by-wire systems. Well, yeah. I'd want my airliner's fly-by-wire system completely bug-free, too.
Commercial software tends to harbor anywhere from 1 to 7 bugs per 1000 lines of code according to the National Cybersecurity Partnership's Working Group on the Software Lifecycle. Voluntary testing by Coverity requested (and probably paid for) by MySQL AB revealed that project to have all of 97 flaws, one of which could be a serious security issue. All 97 were to be fixed for the next release.
A similar study (same link) found 985 bugs in over 5,700,000 lines in the Linux kernel, or fewer than one bug per 10,000 lines of code. TFA has data on a newer version of the kernel -- 0.127 bugs per TLOC.
In Apache, 22 bugs total, 0.14 per TLOC, and three fixed so far.
PostgreSQL had 0.041 per TLOC, and have so far fixed 53 of the 90 bugs.
The glibc team fixed 83 of 83 bugs found.
OpenVPN had found one security-related bug in over 69,000 lines of code. As of later yesterday, it's officially security bug free according to the same testing people.
The list of officially security-bug free software includes Amanda, NTP, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, and TCL.
So with Linux (0.127), glibc (0.000), Apache (0.140), PostgresSQL (0.041), Perl (0.024), PHP (0.000), and Python (0.000) powering a web server (numbers according to Coverity), you have 0.0474 defects per thousand lines of code across the server. I'd say that's pretty good.
I haven't done much reading, writing, or speaking in French for about 13 years, but I can pick out a couple. To the far left in front is apparently acetone. The last one on the right in front is either "acide chloridrique" or "acide chlorhydrique", which would be either chloric acid or hydrochloric acid.
..." is water of some sort ("eau" being "water"), but I'm having trouble picking out just what sort. The label wraps around and looks like the adjective starts with "denin", but maybe it's "demin". I can't think of anything nor find anything that starts with "denin". Perhaps it actually starts "demin" and is "eau déminéralisée", or demineralized water. That makes sense.
:-)
The one labeled "eau
Other types of water, for the curious... Permuted water is "eau permutée". Distilled waster is "eau distilleée". The first instinct as an English-speaking American with limited French would be to say "eau dénaturée" for denatured water, and Babelfish thinks that's right, too. Deionized water would be "eau désionisée". So I'm pretty much out of ideas for types of water to translate.
BTW, the section title "C'est l'heure de bain" means "It's time for a bath" or "It's bath time". (More directly, "It's the hour of the bath", but that of course sounds really awkward.)
I'm pretty sure it was a joke. That's the obsessive hobby of many a slashdotter.
I did it so I could award $100 to the first person who asked me why I wrote so much. However, since you're an anonymous troll, your winnings can't be verified. Sorry.
I think he said that he personally has no problem with what Tivo does. I don't think he has a problem with a license not allowing what Tivo does, as long as he's free to not move to that license. So yeah, it could be that one of his reasons for not wanting to move to the GPLv3 is that he supports what Tivo's doing.
Personally, I think having different licenses for different camps with different views is great. I just don't think the GPLv3 is what many developers licensing code under GPLv2 consider to be an improved GPLv2. I think it strikes a lot of people as trying to go too far or go in a different direction. I'm not opposed to the GPLv3 for people who want to use it. I'll probably contribute code to projects that use it. I probably won't use it for any of my own projects (not that I'll change any lives in that decision, because none of my projects ever get spread around much). If people asked Linus about it in those terms rather than being so confrontational about things, he might say the same.
I tend to think the separation between the transport and the authentication is a good thing. I had been using PAM and a firewall, but if I ever need such security again I'll be looking into the pam_abl module another poster mentioned.
Now they're registering attacks on their competitors!
Visit AboutUs.org for more information about GODADDYCOMMITSFRAUD.COM
AboutUs: GODADDYCOMMITSFRAUD.COM
Registrant:
This Domain is available at NetworkSolutions.com
13681 Sunrise Valley Drive, Suite 300
HERNDON, VA 20171
US
Domain Name: GODADDYCOMMITSFRAUD.COM
This Domain is Available - Register it Now!
600,000 domain names are registered daily! Don't delay; there's no guarantee
that a domain name you see today will still be here tomorrow!
Register it Now at www.NetworkSolutions.com.
Administrative Contact, Technical Contact:
Network Solutions, LLC domainsupport@networksolutions.com
13681 Sunrise Valley Drive, Suite 300
HERNDON, VA 20171
US
1-888-642-9675 fax: 571-434-4620
Record expires on 08-Jan-2009.
Record created on 08-Jan-2008.
Database last updated on 8-Jan-2008 17:58:30 EST.
Domain servers in listed order:
ns1.reserveddomainname.com 205.178.190.55
ns2.reserveddomainname.com 205.178.189.55
The .tv domain name is a country-code top-level domain name (ccTLD). It's for the nation of Tuvalu. The government of Tuvalu contracted with Network Solutions to manage the WHOIS and registration for it. Last I read about it, the .tv domain name was the leading export in monetary value of the whole country.
.tv domain through a large number of other registrars. Register.com and for example allow you to register through them.
You can register a
If you think the government of Tuvalu should be maintaining their own national registry, I implore you to take up a collection and found one for them. They're not going to give up the revenue to suit you, and it's their right to choose who they want to pay to administer it.
Considering that most people check a few then register the one they like best out of those available it's detrimental to business to make those people wait four days, isn't it? The frontrunners would be more likely to script up a batch every day of the results from four days ago than the individuals would be to come back and register something NSI took off the available list.
It's also poor practice for NSI to keep me from searching on NSI then deciding to register with GoDaddy, Register.com, Dotster, or SRSPlus. That's especially true since I have an SRSPlus domain reseller account but hate their domain availability checking interface, and SRSPlus is owned by NSI. Perhaps I should resell for someone else instead, and move all my existing domains. I might on principal.
Any time you see the word "should", it means the writer thinks that's the way things ought to happen. It doesn't mean the writer thinks that's the way things are currently happening, or the way they are going to happen. Perhaps it's you who just doesn't
understand.
Your equation works well if X and Y are well chosen. However, how, logically, does the imposition of "no trusted kernel signing" further the freedom of "everyone gets to see the source", unless as I already mentioned you don't trust it's the actual source?
How, logically, does "can't use it with a DRM system although the source and the DRM source are open and free" defend the freedom of "everyone gets to see the source"?
The FSF isn't the "Anti-DRM League". It isn't the "Open Source Code and Limited Applicability of Our Software Organization". It's the "Free Software Foundation". It should be promoting the freedom of the software. That's because honesty is typically considered a good thing.
What right to free use of the software isn't covered by the GPLv2? I keep pointing out the fallacies of your argument, and you keep quoting portions of my posts out of context and skirting the issue. The specific freedoms the FSF should be protecting are those it has been claiming to champion for so many years. Again, that's because honesty and integrity should mean something.
I am not naive. I may be wicked, depending on whom you ask. That has nothing to do with the fact that people are supposed to fight for what they say they're supporting, and not for something else entirely. In fact, most people would consider the opposite wicked.
The GPLv2 was the definitive document on Free Software for all practical purposes until GPLv3 came along. The FSF's manifesto documents aren't binding, and those aren't what most people outside the FSF used to consider how to license their code. If it was Free according to the GPL, it was Free Software. Linux, therefore, was Free Software. Now that some people are trying to say that GPLv3 is "Free" and GPLv2 is "not Free", they're saying Linus hates free software. It's a terribly specious argument. The GPLv2 hasn't changed. The people using it who don't want to go to the GPLv3 haven't changed. They still support GPLv2.
Until you admit that other people have other valid opinions, you're going to go nowhere in discussions like this one.
offtopic:
Actually, the parent post and my comment in response were actually as much spoiler as what came after, and you still have no idea from all of it together about the main plot of the film. It's a pretty good one for geeks, so I'd recommend it. I own a DVD (yes, a legit factory-stamped one) of it and pull it out about every 4 months.
It is clear you're an accusatory and condescending ass. That's what's clear. Because someone disagrees with you is no reason to say they don't understand an issue. If everyone agreed, there wouldn't be an issue to discuss and no licenses pointing out the differences would be necessary. Come down off your high horse if you want to continue the subthread, please.
Why is a developer of something with open source code any more privileged than the end user? That's the whole point of the source code being available.
Furthermore, why is the manufacturer of a particular piece of hardware more privileged than the end user? The end user has every right not to buy that brand of hardware. The only real disadvantage the end user has isn't that the hardware in non-free. It's isn't even that they can't run their update kernel on the proprietary, sealed hardware without modifying the hardware. It's that without being able to decrypt the OS and then uncompile it, or to be able to run it in a sandbox, that they can't be sure the compiled kernel is really the same as what the manufacturer supplies as source. If Linus pushed the matter of making them prove it's the same, he could probably witness the signing of it and vouch for them. Otherwise, the very act of distributing a signed binary is counter to the requirement to provide the real source. However, if you have that little trust in the vendor, why would you buy their hardware, as it could be doing any nefarious thing too?
When someone calls themselves the "Free Software Foundation", they should be limiting the free use of the software as little as possible to further its greater freedom. The GPLv2, for all its perceived flaws, does that pretty well. To say something is free software, but that it can only be used in this or that way by people who agree with the whole political platform of the foundation is frankly blatant hypocrisy. What good is it to the end user to have the source code if they're not allowed to run the software? How is that keeping the privileged developers and members of the FSF from limiting the freedoms of end users?
Why is it a problem that Linus doesn't agree with the FSF altogether? Is complete agreement with the FSF prerequisite to abhor slimy, lying, monopolistic, closed-source Unix vendors? Is it important to carry an FSF card to think that cooperating with other developers around the world can produce something better than what's being pushed by the innovative marketing department at Microsoft? Linus chose the GPLv2 because what RMS codified in it made a lot of sense to him and to many other people.
It might help you to remember that RMS and the FSF are the ones who have changed position. The people who are sticking to the GPLv2 are doing exactly what the FSF asked of them up until a few months ago. Now, the FSF wants to ask them to change. Why is it that Linus or anyone else is being called anti-FSF when it's the FSF that has changed direction?
The FSF used to always say that if you liked the GPLv2 even enough to consider it, that it was better to use it and stand united as a Free Software community than to splinter off new and slightly incompatible licenses. That's true, and Linus saw the wisdom in that. Now, the GPLv3 is a license other than the GPLv2 and it's causing a bunch of strife and incompatibility in the community. Many people in and adorers of the FSF think that because they wrote both licenses that everyone should just switch. However, they encouraged the use of GPLv2 by a much wider audience than their core group, and now they're trying to say there's some dogma attached to the licenses. The licenses are legal documents for men, though, and not handed down from on high and dictated to software developers by angels.
The FSF should be glad so many people are using the GPLv2 rather than BSD, MPL, or any of a hundred thousand closed-source EULAs. By bickering with people who support the major beliefs of the FSF but not the dogma and specifics, the FSF is alienating all the OSI crowd who never bought into a centralized repository of "free" software at MIT in the first place. These are the people they should be glad are on the same side, even if they're not in the same tent.
I thought for sure when your sentence started "BTW - habaneros aren't the hottest..." that it'd be another mention of jolokia, which is also hotter than the Red Savina habanero (and which is derived from the habanero family itself).
The Dorset Naga is definitely noticeably hotter than the Red Savina with that kind of Scoville rating. However, it looks like the record Jolokia is hotter still at slightly over 1 million Scoville units.
Wikipedia says they're probably comparable and that the Dorset pepper is derived from the Bhut Jolokia.
I'd never heard of the specific Dorset version of the pepper. I'll have to see if I can get my hands on some.
For readers curious, the Scoville scale is based on how many parts of plain sauce can be mixed with the rated item without masking its hot, spicy taste. It was originally left to a panel of taste testers, but now it's measured as a proportion of the capsaicin in the item rated.
A warning for the foolhardy, too... Extracts are the fastest way to extra pungency, but pure capsaicin needs to be handled with real care. It's available on the open market, but it can cause damage to the skin or eyes and can trigger asthma attacks or even kill a person.
I used to run a network with an ssh-only server. All it had facing the world as an actual service was OpenSSH's sshd on a fixed nonstandard port. It also had two fixed and four randomly hopping honeypot ports that added any /24 network that hit them to a 24-hour firewall DROP rule.
Once someone logged into that server using their own key or pass phrase, the only command they could run was ssh. All the other servers in the network only allowed ssh in from that ssh box, and by policy their keys and pass phrases had to be different on the ssh server than on the internal boxes. Each failed attempt at logging in caused a 5-second wait, and after three a 12-hour wait.
Is it as secure as having the real port hop around and synchronizing that with the clients via a shared secret? Well, I guess that depends on just how secret the shared secret is. We never had any problems, though, and the only thing our people had to take with them were the name of the server, their private key or passphrase, and the proper port to use. They usually didn't have much problem remembering three of those, and the you have the same issue with private keys no matter what (that being that they're only as secure as the system on which they are stored).
There's probably some security advantage to the solution presented in TFA, but I'm just not sure it's worth the extra coordination hassle compared to people's home-grown solutions. It seems like every fifth post in the comments is about alternative ways to safeguard ssh ports. Surely not knowing which someone is using provides a bigger hurdle than getting past any single one of them. When you're practicing security by obscurity, which is what this really boils down to, then being more obscure is probably a good thing.
The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.
I concur. A good way not to stress a public NTP server is to set up a private one. You also get closer synchronization over a LAN than over the public Internet. It also reduces your vulnerability profile if only one server makes the connection to the outside, and the rest only connect to it for time. Having a second for fail-over might be wise if it's really important, but if all you're running on a server is NTP then you're probably down to just hardware failure to worry about.
Any server you have that's not fully maxed on load and that can handle the quite small additional security risk of serving NTP to the local network only would be fine, or you could use an old Pentium 100 or such that does nothing but serve NTP.
The local NTP server grabs its update every day (or every 12, 8, 6, or 4 hours) from the public server. There's really no need to hit the public time server too often because you're mostly concerned with synchronization within your network anyway. You can then sync your local machines all to your private NTP server as often as you like, even down to once a minute if you're really that concerned. Using ntpd should work better since it adjust the system clock according to past skews and gets better over time. Using ntpdate would be passable if you run it often enough that your skew isn't significant to your application, but ntpd is still better if you can stand running the daemon on each server.
My preference is to use an old machine to do nothing but get time from the net and provide it to the local network. I always locked mine down in every other way but allowing ssh in, and it only allowed ssh from within the local network. No ssh back out from it, no compilers, and more could be done if you're really paranoid.
There's also PTP for some applications that require better resolution than NTP. I'm not aware of many people actually using it on regular servers, though. Being synchronized within a couple hundred microseconds is usually more than adequate.
I like to think of Linus as a BSD-spirited guy who likes the source code openness of the GPL. He wants people to use the code for whatever, so long as they share their improvements. Many in the FSF camp want to limit not just what you can do with the source, but where and how you can run the binaries. I think there's a good argument that limiting some freedoms can protect others, but i also think there's an argument that the FSF limiting the free use of software is a bad precedent.
The problem here is that TiVo is serving two masters. They want to sell you the box, but it interacts with the content of the big, nasty, litigious mainstream media outlets. They don't want to sell you something you can easily use to violate copyrights, or at least they don't want to be known for that in courtrooms.
I'm not so sure it's sour grapes. I think Linus really likes the GPLv2 more than GPLv3. I think he's glad he can't track down all the authors of all the patches for permission to change it, because it takes some of the heat from GPLv3 zealots off of him.
I'll ask you the same question I ask everyone unhappy with "Perl's object system". Which object systems for Perl have you tried?
There is rudimentary object support (enough for many tasks when you're not in need of a full-fledged object system) based on blessed hashes with no enforced encapsulation. That's the one most people consider since it's been around a while and most of the older docs talk about it.
There are also a number of other object systems written as modules that are well supported by the community. Object::InsideOut is pretty popular. So is Moose. You can always just search CPAN for the word 'object' if you want to look at any others.
Maybe it's 10 * 64 GB and 6 * 8 GB, which uses exactly 4 chip select lines. The 1.6 could then be 10 * 128 and 6 * 64.
There might be unused address space, but I'd go for a solution that has as simple of a custom PCB as possible.
So they're using 5 control lines and have 6 unused chip addresses? I think the 13 * 64 is far more likely.
However, the company knows the economics of their own solution better than any of us, so they might have had the motivation to do something really odd.
I don't trust them either, but I'm often curious and nobody's going to fire me for opening them on this system. It sometimes entertains me to see what the trolls are linking and if I can help keep someone from losing a job by clicking absentmindedly, I think it's all worth it.