Hey, this means we'll probably be FINALLY rid of those endlessly forwarded mails (often even including the stupid "you shall not distribute yadda yadda yadda..." disclaimers), at least in a corporate environment...
Until now, the lawyers could only demand silly disclaimers, but think of the peace and quiet in your inbox if the lawyers had the possibility to outright *prevent* forwarding or cut-n-pasting!
Yes, it is easy to restore. But when you do, make sure you restore the right pieces of it, or e.g. your LVM will get *very* confused if your disk configuration changed between the point of ODM corruption and the moment of you noticing that corruption and restoring. Suddenly you need to know which pieces of the ODM you want to restore, and which pieces you want to leave alone, and it's not so simple anymore.
And the fact that the ODM is easy to restore or not, doesn't determine whether it is a good idea.
Oh please. Consistency and stability? About AIX: remember the introduction of jfs2? It took a *long* time to become usable in a production environment. And have you ever seen the underlying scripts of NIM?
Yes, AIX is consistent and stable *if* you only use features introduced preferably >=2 years ago *and* don't do anything that could be seen as deviating from the average.
Once you're doing that, any half-decent "enterprise class" Linux distro is just as stable and consistent.
This is especially true since --correct me if I'm wrong-- these cards already work in Linux.
The cards won't run without the firmware, not in Linux, not in BSD, not anywhere. Intel forbids distributing the firmware without agreeing to a restrictive contract. Some Linux distributions happily agree to that contract, and restrict their users by doing this. OpenBSD does not want to restrict their users, so they don't agree to the Intel contract. They want Intel to give permission to freely distribute the firmware files.
When I was trying to register some nameservers for a reverse delegation, RIPE didn't allow me to put the nameservers in the in-addr.arpa domain. They claimed that would cause a loop. This means that they force every reverse delegation to be glueless, causing the amount of involved nameserver to be (much) greater than needed. (Granted, this was a few years ago, but I'll bet you don't find many registered nameservers in in-addr.arpa even today)
And (not RIPE related) why the hell is.org served by nameserver outside of.org itself? To make it even worse,.org is served by nameservers with names in.net,.org,.info and.co.uk. Who makes this stuff up? And.com is served by nameservers entirely in.net. No wonder a gazillion nameservers have influence over the resolution of any given name...
I *have* spent several days in a NICU. The question isn't "are these babies worth saving", but the question is: "There's X money available. How can we spend this money so that we can maximize the amount of people helped?". In that context, it's a very valid question to ask whether the cost of a device is worth the (medical) gain.
And what are the specifications of your network connection? Those *are* measured in base 10: 1 megabit/second = 1000 kilobit/second = 1000000 bit/second.
If there was any revisionist crap here, it was the defining of M, G, and so on to be used in base 2 (1024) in the first place. Those are standardized units!
But yes, public display of monitoring is effective and pretty honest propaganda, especially since the mobile phone tells you the call isn't "secure".
There's nothing honest or sincere about this; it's part of the GSM standard that phones display a warning if encryption is unavailable. It's certainly not the case that 'an unlocked padlock or exclamation point was sent to the phones': that's just the way GSM works.
At HAL2001 there was a talk from someone of CryptoRights. He said they desperately need
people for human right work in foreign countries.
If you're thinking about helping, and you have computer skills, visit cryptorights.org.
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
Please indicate where do you think that this breaks the RFCs.
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
Truncation only happens when the reply doesn't fit in 512 bytes. As the administrator of a DNS server, you're in control of the data you publish. If you want to do stupid and publish data that doesn't fit in 512 bytes, you have the possibility to do so. It's just FUD to say that djbdns doesn't support TCP; the nice thing is that if you don't need TCP service, you don't even have to install it.
The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.
This is entirely untrue, and show that you've never even used djbdns. If you make a mistake in your data, you'll get a nice notification of that fact and nothing will stop working, including slave DNS servers. When you correct your mistake, the new data is instantly used and replicated to your slaves. Unlike BIND, which won't load the zone when it has errors in it. This means that BIND will stop publishing data about that zone.
Without a patch from a third party, tinydns does not listen to more than one IP address.
Or you could just run multiple instances of tinydns. Which costs almost nothing, since multiple tinydns'es can use the same data.cdb file. And even several tinydns processes running consume much less resources than even 1 BIND.
Without a third party patch, tinydns does not support standard SRV records
Entirely untrue. tinydns supports all (even not-yet-defined!) types of records. Unlike BIND, which barfs when an unknown record type is fed to it via a zone transfer.
reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse
When a dispute about the bounty (which is for security holes, not bugs in general) occurs, it will be reported on his website. Since there isn't any dispute mentioned, you didn't even try to report one, did you?
Lots of people are running one or more programs of the djbdns suite, and are really happy with them. If you want to use another program, that's perfectly fine of course. It's not fine when you start talking non-sense about a product that you've never even used.
and at work here we have a 2K server up for 80+ days right now, and it's used a lot, it has 2 printers on it, a stack of hard disks and email as well, and we've had no problems
80 days uptime? So, that's 80 days since the installation of any patch. You'd be surprised how full of holes that machine now is.:-)
what if posts under your userID started showing up badmouthing the company you work for, and praising kiddie porn, and threatening to kill the president? You would have a rough time fixing that. GPG signatures would make it easy to prove you didn't do it.
False. Sorry to say it like this, but IMHO it's an important mistake. Signatures CANNOT prove you DIDN'T write something. It's very well possible that you DID make those 'evil' posts you mentioned, but signed them with a different key that nobody knows about.
SecureDNS (available in bind 9) allows you to sign your zone, so this kind of DNS cache poisoning can not happen.
1. This wasn't DNS cache poisoning. The nameservers just weren't reachable.
2. DNS cache poisoning is easily solved: just use good resolvers that don't automatically trust all answers. Try dnscache, and the mydomain.com incident wouldn't have affected you.
(Now, watch this get moderated down as a troll, even though it's totally factual.)
Yeah, real factual. And so objective.
I'm curious: where did you read that the drivers should be GPL'ed? It said they should be Open Sourced. Quite a difference!
And this brings me to a mini-rant: why do BSD-people (not all, ofcourse) try to kick Linux and/or the GPL so much? It seems like you're required to dislike Linux when you run *BSD. Linux and *BSD are totally different. Use what you like, but please don't whine about the others, is that so difficult?!
A company that goes public gets the original opening day "set" price and that's all. If the stock then goes up by some huge amount, the company gets nothing out of it. If the stock later goes down, the company take no loss.
It doesn't work that way. A lot of tech companies (that aren't making any profits - they suffer (large) losses) try to take over as many other companies as they can to gain marketshare to try and become profitable in the future. A lot of the takeovers are paid for with stock of the taking-over company. When the stocks of a company are rising, they can take over other companies relatively easy. When the stock price is falling, takeovers suddenly become much more difficult, so it becomes more difficult to 'create' marketshare, so it becomes more difficult to make money later, which won't be good for the stock price......
I don't know about WON, but battle.net is so badly overloaded now, that the lag is terrible for doing ANYTHING on the service.
Uhm, battle.net is only a meeting place to find people to play (with|against). Once you've found opponents and start a game, battle.net doesn't do anything but record the game result at the end. The actual game is played between the clients. (This is Starcraft-experience, BTW).
This to me sounds like they had the perfect right to use the network.
Yes, only not in their room. I'll repeat this; where do you think more bandwith (and thus money!) is burnt:
in a lab, where you leave after you're done and you generally can't keep stuff running after you left
in a room, where you power on your machine only to almost never power it off, and use the 'Net 24 hours/day, even when you are somewhere else (can you say 'large downloads' or 'Napster'?)
That is where the $24 is for. It's not just about having access or not, it's about having more access vs less access.
They chose to not pay the $24 but still wanted that extra access. Their fault. (But arresting goes a bit far, I definately agree with that).
These students did in fact have a right to use the university network. They used it every day, in their various labs and study facilities. Says right there in the news articles that were linked in the/. post. So they can use the network, just not where it would actually useful for them.
I really can't agree with 'but they HAD legal access, they just used a long cable' stuff. OK, they had access in a lab. That's entirely different from having access in your room. Which of the two will use more bandwith?
AI as portrayed in the Matrix will never happen simply because an awareness of self is something more than just 10 billion neurons (or transistors) firing in a coherent fashion.
"Simply because"?? That's the second time I see such an argument used here. (and I'm not reading this discussion very well.) What gives you the justification to say "simply because"?
It looks like everyone who uses arguments like "obviously", "simply because", "naturally", etc. etc. don't realise that the problem of (hard) (A)I really lies in those things people dismiss so easily!
Try to think of these things without using arguments like the one used above.
Deep Blue is able to beat chess masters because it has enough computing power to permutate all possible moves several generations into the future and pick the best one. Obviously, no chess master's brain can do that.
'Obviously'? Why do you dismiss that as a possibility that easily? It's unknown how human brains play chess, so I wouldn't rule out the 'brute force' method that quickly.
Slashdot Mirror
Indeed they do, and on page 2 of it they say:
Warning: When fire is involved, consider the entire vehicle energized and DO NOT TOUCH any part of the vehicle.
No, but a moose once bit my sister...
Hey, this means we'll probably be FINALLY rid of those endlessly forwarded mails (often even including the stupid "you shall not distribute yadda yadda yadda..." disclaimers), at least in a corporate environment...
Until now, the lawyers could only demand silly disclaimers, but think of the peace and quiet in your inbox if the lawyers had the possibility to outright *prevent* forwarding or cut-n-pasting!
Yes, it is easy to restore. But when you do, make sure you restore the right pieces of it, or e.g. your LVM will get *very* confused if your disk configuration changed between the point of ODM corruption and the moment of you noticing that corruption and restoring. Suddenly you need to know which pieces of the ODM you want to restore, and which pieces you want to leave alone, and it's not so simple anymore.
And the fact that the ODM is easy to restore or not, doesn't determine whether it is a good idea.
Oh please. Consistency and stability? About AIX: remember the introduction of jfs2? It took a *long* time to become usable in a production environment. And have you ever seen the underlying scripts of NIM?
Yes, AIX is consistent and stable *if* you only use features introduced preferably >=2 years ago *and* don't do anything that could be seen as deviating from the average.
Once you're doing that, any half-decent "enterprise class" Linux distro is just as stable and consistent.
You didn't even mention the ODM. For those who don't know what the AIX ODM is: think Windows Registry, but now on Unix. Yes. Really.
Once you know your way around the pitfalls, it's OK-ish to run, administer and use. But, given the cost of the OS and the hardware, why bother?
The cards won't run without the firmware, not in Linux, not in BSD, not anywhere. Intel forbids distributing the firmware without agreeing to
a restrictive contract. Some Linux distributions happily agree to that contract, and restrict their users by doing this. OpenBSD does not
want to restrict their users, so they don't agree to the Intel contract. They want Intel to give permission to freely distribute the firmware files.
When I was trying to register some nameservers for a reverse delegation, RIPE didn't allow me to put the nameservers in the in-addr.arpa domain. They claimed that would cause a loop. This means that they force every reverse delegation to be glueless, causing the amount of involved nameserver to be (much) greater than needed. (Granted, this was a few years ago, but I'll bet you don't find many registered nameservers in in-addr.arpa even today)
.org served by nameserver outside of .org itself? To make it even worse, .org is served by nameservers with names in .net, .org, .info and .co.uk. Who makes this stuff up? And .com is served by nameservers entirely in .net. No wonder a gazillion nameservers have influence over the resolution of any given name...
And (not RIPE related) why the hell is
I *have* spent several days in a NICU. The question isn't "are these babies worth saving", but the question is: "There's X money available. How can we spend this money so that we can maximize the amount of people helped?". In that context, it's a very valid question to ask whether the cost of a device is worth the (medical) gain.
And what are the specifications of your network connection? Those *are* measured in base 10: 1 megabit/second = 1000 kilobit/second = 1000000 bit/second.
If there was any revisionist crap here, it was the defining of M, G, and so on to be used in base 2 (1024) in the first place. Those are standardized units!
But yes, public display of monitoring is effective and pretty honest propaganda, especially since the mobile phone tells you the call isn't "secure".
There's nothing honest or sincere about this; it's part of the GSM standard that phones display a warning if encryption is unavailable. It's certainly not the case that 'an unlocked padlock or exclamation point was sent to the phones': that's just the way GSM works.
At HAL2001 there was a talk from someone of CryptoRights. He said they desperately need people for human right work in foreign countries. If you're thinking about helping, and you have computer skills, visit cryptorights.org.
By default, tinydns does not hand out referrals to questions it is asked about zones it does not control. I believe that this violates the spirt of the RFCs, if not the letter.
Please indicate where do you think that this breaks the RFCs.
By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt of the RFCs, as well as the letter (if a DNS query via UDP results in truncation, you're supposed to re-do the query using TCP instead).
Truncation only happens when the reply doesn't fit in 512 bytes. As the administrator of a DNS server, you're in control of the data you publish. If you want to do stupid and publish data that doesn't fit in 512 bytes, you have the possibility to do so. It's just FUD to say that djbdns doesn't support TCP; the nice thing is that if you don't need TCP service, you don't even have to install it.The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.
This is entirely untrue, and show that you've never even used djbdns. If you make a mistake in your data, you'll get a nice notification of that fact and nothing will stop working, including slave DNS servers. When you correct your mistake, the new data is instantly used and replicated to your slaves. Unlike BIND, which won't load the zone when it has errors in it. This means that BIND will stop publishing data about that zone.
Without a patch from a third party, tinydns does not listen to more than one IP address.
Or you could just run multiple instances of tinydns. Which costs almost nothing, since multiple tinydns'es can use the same data.cdb file. And even several tinydns processes running consume much less resources than even 1 BIND.
Without a third party patch, tinydns does not support standard SRV records
Entirely untrue. tinydns supports all (even not-yet-defined!) types of records. Unlike BIND, which barfs when an unknown record type is fed to it via a zone transfer.
reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse
When a dispute about the bounty (which is for security holes, not bugs in general) occurs, it will be reported on his website. Since there isn't any dispute mentioned, you didn't even try to report one, did you?
Lots of people are running one or more programs of the djbdns suite, and are really happy with them. If you want to use another program, that's perfectly fine of course. It's not fine when you start talking non-sense about a product that you've never even used.
and at work here we have a 2K server up for 80+ days right now, and it's used a lot, it has 2 printers on it, a stack of hard disks and email as well, and we've had no problems
80 days uptime? So, that's 80 days since the installation of any patch. You'd be surprised how full of holes that machine now is. :-)
what if posts under your userID started showing up badmouthing the company you work for, and praising kiddie porn, and threatening to kill the president? You would have a rough time fixing that. GPG signatures would make it easy to prove you didn't do it.
False. Sorry to say it like this, but IMHO it's an important mistake. Signatures CANNOT prove you DIDN'T write something. It's very well possible that you DID make those 'evil' posts you mentioned, but signed them with a different key that nobody knows about.
SecureDNS (available in bind 9) allows you to sign your zone, so this kind of DNS cache poisoning can not happen.
1. This wasn't DNS cache poisoning. The nameservers just weren't reachable.
2. DNS cache poisoning is easily solved: just use good resolvers that don't automatically trust all answers. Try dnscache, and the mydomain.com incident wouldn't have affected you.
(Now, watch this get moderated down as a troll, even though it's totally factual.)
Yeah, real factual. And so objective.
I'm curious: where did you read that the drivers should be GPL'ed? It said they should be Open Sourced. Quite a difference!
And this brings me to a mini-rant: why do BSD-people (not all, ofcourse) try to kick Linux and/or the GPL so much? It seems like you're required to dislike Linux when you run *BSD. Linux and *BSD are totally different. Use what you like, but please don't whine about the others, is that so difficult?!
A company that goes public gets the original opening day "set" price and that's all. If the stock then goes up by some huge amount, the company gets nothing out of it. If the stock later goes down, the company take no loss.
It doesn't work that way. A lot of tech companies (that aren't making any profits - they suffer (large) losses) try to take over as many other companies as they can to gain marketshare to try and become profitable in the future. A lot of the takeovers are paid for with stock of the taking-over company. When the stocks of a company are rising, they can take over other companies relatively easy. When the stock price is falling, takeovers suddenly become much more difficult, so it becomes more difficult to 'create' marketshare, so it becomes more difficult to make money later, which won't be good for the stock price ......
I don't know about WON, but battle.net is so badly overloaded now, that the lag is terrible for doing ANYTHING on the service.
Uhm, battle.net is only a meeting place to find people to play (with|against). Once you've found opponents and start a game, battle.net doesn't do anything but record the game result at the end. The actual game is played between the clients. (This is Starcraft-experience, BTW).
License the program under the GPL and assign the copyright to the Free Software Foundation
I have a question about this: how do you assign copyright to anybody? Does the party to whom you're assigning the copyright has to know? Or to agree?
Or is it enough to say that "Gnomovision is (c)2000 Free Software Foundation", without the FSF ever knowing about it?
This to me sounds like they had the perfect right to use the network.
Yes, only not in their room. I'll repeat this; where do you think more bandwith (and thus money!) is burnt:That is where the $24 is for. It's not just about having access or not, it's about having more access vs less access.
They chose to not pay the $24 but still wanted that extra access. Their fault. (But arresting goes a bit far, I definately agree with that).
These students did in fact have a right to use the university network. They used it every day, in their various labs and study facilities. Says right there in the news articles that were linked in the /. post. So they can use the network, just not where it would actually useful for them.
I really can't agree with 'but they HAD legal access, they just used a long cable' stuff. OK, they had access in a lab. That's entirely different from having access in your room. Which of the two will use more bandwith?Ok, let's get this over with:
:-) )
REAL programmers type dd if=/dev/ttyS0 of=bzImage
and WHISTLE into their MODEM!
(Now just one more comment about "you had rocks?", and we're done.
AI as portrayed in the Matrix will never happen simply because an awareness of self is something more than just 10 billion neurons (or transistors) firing in a coherent fashion.
"Simply because"??
That's the second time I see such an argument used here. (and I'm not reading this discussion very well.) What gives you the justification to say "simply because"?
It looks like everyone who uses arguments like "obviously", "simply because", "naturally", etc. etc. don't realise that the problem of (hard) (A)I really lies in those things people dismiss so easily!
Try to think of these things without using arguments like the one used above.
Deep Blue is able to beat chess masters because it has enough computing power to permutate all possible moves several generations into the future and pick the best one. Obviously, no chess master's brain can do that.
'Obviously'? Why do you dismiss that as a possibility that easily? It's unknown how human brains play chess, so I wouldn't rule out the 'brute force' method that quickly.