Even in Europe, the song itself is not in the public domain because Athur Crudup, its composer, died only as late as 1974. In most European countries, works of performing artists are only protected for 50 years, but for the actual lyrics and music, the clock starts running after the author's death (and runs for 50 or 70 years).
That means that the European rules mainly cause classical music to enter the public domain at this point.
Re:If Math is or is not a sport...
on
Is Math A Sport?
·
· Score: 1
I would like to see a mathematical proof written to support the claim.
I'd guess that's the difference between math and mathematics.
Er, require strong passwords? Hm, yeah, that'd work, and I guess it is "little" to do:)
If they rely heavily on switches (or routing protocols are available on end user interfaces), stronger passwords won't really help because you can get them using man-in-the-middle attacks.
I'm more concerned that the students were forced to keep back their findings. This doesn't quite match the standards of the university. The important part of the message (for the real miscreants to come) is not how it was done, but that it can be done.
If they had implemented a whitelist of known-good URL schemes back then, it would have been a proactive security measure. Fixing things after they have been announced on some mailing list (or reported privately) is, of course, only reactive.
The problem with this analysis is that Interix is older than MacOS X. Interix was a shipping product when Apple still was experimenting with Rhapsody previews.
Hell, with the critical-update-du-jour lately, it's probably hard for Windows users to imagine a computer that's been running since the previous week without being rebooted.
Microsoft's DCE and DCOM implementations have been ported to OpenVMS, line by line, including those lines which contain the critical buffer overflow bugs. Maybe that's why these systems fit into Windows environments so nicely. 8-)
It's still ridiculous that the judge doesn't have enough brains to toss the case right out. The numeric address space belongs to NAC, a domain name (if registered) belongs to the plaintiff.
Wrong. The address space doesn't belong to NAC. Since the mid-90s, address space assignments are covered by certain rules, and no ownership is transferred by the RIRs.
Furthermore, as a commercial ISP customer, you have a reasonable expectation that the ISP won't suddenly take away your addresses. Renumbering is painful can often take weeks or months, depending on the organizational structure and the hosts that are involved.
Unlike the whole "keep your cell-phone number" jiberjoo, this is unneeded and will do nothing but break the internet, will it not?
No, it won't. If the affected prefix not too long, it will just work (thousands of companies do this for the purpose of multihoming). Otherwise, the prefix will be just filtered away by other ISPs not subject to the court order.
Has anybody a link for the other side of the story? So far, only the ISP has published his version.
There probably is some kind of contract dispute (or dispute over the way the contract was terminated). The court probably wants to ensure that the customer that used the IP addresses does not lose them while this dispute is being resolved. If the addresses are taken away immediately, this will result in irreparable harm to the customer.
In fact, the ISP is not ordered to provide service to the customer, it's only prevent from inject certain routes into its IGP, or announce them over BGP. This can be an astonishingly clueful decision bythe court ifthe affected prefixes are large enough and can be routed indepedently of the short prefix that is allocated to NAC.
It's not really the ISP's job to fix their computer [the customer's].
They make money by providing connectivity. Almost in the same way, you could argue that companies are not responsible for pollution.
It's a little like calling the phone company because your answering machine is broken.
Your answering machine isn't fooling with SS#7 and telephone switches. Compromised home systems are known to wreak havoc in many ways, some of them very nasty.
The base reason is that US wants the ability to turn off civilain GPS when they want to. If Europe puts up a system that US doesn't have control over than turning off GPS becomes useless and they lose )what they believe to be) a tactical advantage.
I wouldn't be too surprised if signal degradation as reuqested by US officials were part of the current agreement.
The Mozilla bugs are sometimes worrisome, but they do seem to get fixed.
Not if you use official packages from your GNU/Linux distributor. Both SuSE and Debian still ship vulnerable versions, and IIRC Red Hat hasn't fixed all holes, either.
It does compile out of the box on modern systems. I use it for 5 different domains that I administer. The latest time I set it up, it was on a Gentoo Linux box, I just had to emerge the package and was good to go.
In this case, you don't use the official version of tinydns, but a modified one which contains random patches. Others have patched GNU libc to increase interoperability with broken applications such as tinydns, too.
It is maintained, but the author doesn't see a pressing need for any changes to its functionality. It's simple, secure, and does everything an authoritative dns server should do correctly.
The official version does not support IPv6, for example.
I don't know what third-party documentation you're referring to, but most people just read how to configure it from the djbdns official site at http://cr.yp.to, which suggests no bad configurations.
The way serial numbers for zones are automatically generated by tinydns is not universially accepted.
Yes, I know that DNSSEC has its drawbacks, but so far, DJB has only argued against it, without providing a real alternative (or even fully describing it).
Others offer (well, sort-of) working DNSSEC implementations, which might be a reason to use these implementations instead of tinydns. Of course, the overall need for DNSSEC implementations is pretty low on the current Internet, even though everyone wants a secure DNS (kind of a chicken-and-egg problem).
Despite only having 2% of the installs, TinyDNS serves 15% of all domains on the internet. Obviousy it is very capable, and has few to no exploits available for it. Why don't more people use TinyDNS if it's so capable?
tinydns is unmaintained software. It does not compile out of the boxon modern systems. You don't have a license, so you can only do with it what your local copyright law permits (which may or may not be enough). The zone file format of tinydns is non-standard. The answers it generates are often excessively verbose (e.g. redundant NS records). Third-party documentation suggests a configuration that violates recommendations of TLD operators and most ISPs, which means that you have to redo parts of it once you receive your first delegation.
And so on. Go ahead and use BIND alternatives for authoritative name servers, but try to avoid tinydns.
Slashdot Mirror
Even in Europe, the song itself is not in the public domain because Athur Crudup, its composer, died only as late as 1974. In most European countries, works of performing artists are only protected for 50 years, but for the actual lyrics and music, the clock starts running after the author's death (and runs for 50 or 70 years).
That means that the European rules mainly cause classical music to enter the public domain at this point.
I would like to see a mathematical proof written to support the claim.
I'd guess that's the difference between math and mathematics.
Er, require strong passwords? Hm, yeah, that'd work, and I guess it is "little" to do :)
If they rely heavily on switches (or routing protocols are available on end user interfaces), stronger passwords won't really help because you can get them using man-in-the-middle attacks.
I'm more concerned that the students were forced to keep back their findings. This doesn't quite match the standards of the university. The important part of the message (for the real miscreants to come) is not how it was done, but that it can be done.
I'm quite happy to see that the Mozilla team is pro-active in fixing the bugs that could allow MalWare to install unchecked.
7
The Mozilla team isn't proactive on security issues. The dangers of Windows URL schemes have been known to the Mozilla team since mid-2002:
http://bugzilla.mozilla.org/show_bug.cgi?id=16376
If they had implemented a whitelist of known-good URL schemes back then, it would have been a proactive security measure. Fixing things after they have been announced on some mailing list (or reported privately) is, of course, only reactive.
The problem with this analysis is that Interix is older than MacOS X. Interix was a shipping product when Apple still was experimenting with Rhapsody previews.
I'd be very, VERY surprised if Sun allows Dtrace into the open source world, at least not for a while.
Oddly enough, there doesn't seem to be a patent for DTrace.
No, linux does not already do this.
Show me a tool that can link high disk I/O load to the processes that cause it, on a vanilla Linux kernel.
Hell, with the critical-update-du-jour lately, it's probably hard for Windows users to imagine a computer that's been running since the previous week without being rebooted.
Microsoft's DCE and DCOM implementations have been ported to OpenVMS, line by line, including those lines which contain the critical buffer overflow bugs. Maybe that's why these systems fit into Windows environments so nicely. 8-)
Broadband usually has lousy SLAs (97% availability and things like that). For remote maintainance of decent systems, ISDN is a much better choice.
Maybe the guy was hosting spammers in his address space and that's why NAC pulled him?
In this case, it's a bit strange to publish the failure to NANOG.
It's still ridiculous that the judge doesn't have enough brains to toss the case right out. The numeric address space belongs to NAC, a domain name (if registered) belongs to the plaintiff.
Wrong. The address space doesn't belong to NAC. Since the mid-90s, address space assignments are covered by certain rules, and no ownership is transferred by the RIRs.
Furthermore, as a commercial ISP customer, you have a reasonable expectation that the ISP won't suddenly take away your addresses. Renumbering is painful can often take weeks or months, depending on the organizational structure and the hosts that are involved.
Unlike the whole "keep your cell-phone number" jiberjoo, this is unneeded and will do nothing but break the internet, will it not?
No, it won't. If the affected prefix not too long, it will just work (thousands of companies do this for the purpose of multihoming). Otherwise, the prefix will be just filtered away by other ISPs not subject to the court order.
Has anybody a link for the other side of the story? So far, only the ISP has published his version.
There probably is some kind of contract dispute (or dispute over the way the contract was terminated). The court probably wants to ensure that the customer that used the IP addresses does not lose them while this dispute is being resolved. If the addresses are taken away immediately, this will result in irreparable harm to the customer.
In fact, the ISP is not ordered to provide service to the customer, it's only prevent from inject certain routes into its IGP, or announce them over BGP. This can be an astonishingly clueful decision bythe court ifthe affected prefixes are large enough and can be routed indepedently of the short prefix that is allocated to NAC.
It's not really the ISP's job to fix their computer [the customer's].
They make money by providing connectivity. Almost in the same way, you could argue that companies are not responsible for pollution.
It's a little like calling the phone company because your answering machine is broken.
Your answering machine isn't fooling with SS#7 and telephone switches. Compromised home systems are known to wreak havoc in many ways, some of them very nasty.
That's the only thing that will work on the long run. Everything else just reaches those who are already somewhat aware of the problem.
Unfortunately, calling the customer and walking him through disinfection/reinstall costs too much money, so only very, very few ISPs do it at all.
The base reason is that US wants the ability to turn off civilain GPS when they want to. If Europe puts up a system that US doesn't have control over than turning off GPS becomes useless and they lose )what they believe to be) a tactical advantage.
I wouldn't be too surprised if signal degradation as reuqested by US officials were part of the current agreement.
The Mozilla bugs are sometimes worrisome, but they do seem to get fixed.
Not if you use official packages from your GNU/Linux distributor. Both SuSE and Debian still ship vulnerable versions, and IIRC Red Hat hasn't fixed all holes, either.
You can download a fix for this here [Mozilla].
First you should read this (which is known to be incomplete), and this, a rather strange policy.
Mozilla is a very nice browser, but it's not the kind of fortress most users think it is.
They still have too much too much money if they license StarOffice, instead of just installing OpenOffice for free.
It does compile out of the box on modern systems. I use it for 5 different domains that I administer. The latest time I set it up, it was on a Gentoo Linux box, I just had to emerge the package and was good to go.
In this case, you don't use the official version of tinydns, but a modified one which contains random patches. Others have patched GNU libc to increase interoperability with broken applications such as tinydns, too.
It is maintained, but the author doesn't see a pressing need for any changes to its functionality. It's simple, secure, and does everything an authoritative dns server should do correctly.
The official version does not support IPv6, for example.
I don't know what third-party documentation you're referring to, but most people just read how to configure it from the djbdns official site at http://cr.yp.to, which suggests no bad configurations.
The way serial numbers for zones are automatically generated by tinydns is not universially accepted.
Yes, I know that DNSSEC has its drawbacks, but so far, DJB has only argued against it, without providing a real alternative (or even fully describing it).
Others offer (well, sort-of) working DNSSEC implementations, which might be a reason to use these implementations instead of tinydns. Of course, the overall need for DNSSEC implementations is pretty low on the current Internet, even though everyone wants a secure DNS (kind of a chicken-and-egg problem).
RFC 1035 (STD 13) describes the format of zone files (which are called "master files" in this document).
Which modern systems are those exactly? I've never had any trouble getting it to compile...
... surely that's just because there's been nothing to change about it? Are there outstanding bugs?
Systems with a recent version of GNU libc.
When you say unmaintained
It's not bugs, it's lack of features: IPv6 support, CIDR support for dnscache configuration, maybe even DNSSEC even you want to give it a try.
Um .... tinydns doesn't need to be maintained, because people aren't finding security holes or bugs in it on a weekly basis.
tinydns doesn't even compile on modern GNU/Linux systems. Surely this is a bug in tinydns, isn't it?
Despite only having 2% of the installs, TinyDNS serves 15% of all domains on the internet. Obviousy it is very capable, and has few to no exploits available for it. Why don't more people use TinyDNS if it's so capable?
tinydns is unmaintained software. It does not compile out of the boxon modern systems. You don't have a license, so you can only do with it what your local copyright law permits (which may or may not be enough). The zone file format of tinydns is non-standard. The answers it generates are often excessively verbose (e.g. redundant NS records). Third-party documentation suggests a configuration that violates recommendations of TLD operators and most ISPs, which means that you have to redo parts of it once you receive your first delegation.
And so on. Go ahead and use BIND alternatives for authoritative name servers, but try to avoid tinydns.