Very good point, I'd mod you up if I hadn't posted and actually had any points left:-)
So the question is, is a single person more likely to be corrupt or not act in the best interests of his job than a corporation? I think ICANN is a particularly bad example, but the idea of a board is that a single person can't do something stupid (but of course the beaurocracy and politics gets involved then).
I'm not sure if there's an answer to that one. A single person with some integrity would be perfect, but if he became corrupt then there'd be major problems. Of course it's easier to get a single person out than a corporation:)
I think they're basically saying that ICANN is going to be destructive to peoples' interests, and so should be absolved of any power as soon as possible; hence the non-permanent, strictly stewardship basis.
I think that in the short-term an organization without political or economic interests needs to be in charge.
Galeon is a small download but can be difficult to upgrade due to its Mozilla and GNOME dependencies.
Dependancy problems? I don't think that's an issue which should affect Galeon at all. Dependancies are supposed to be sorted out by the package management system; problems with dependancies is a failure of the package management system (or the distribution) and not that of any individual client program. (I note here that galeon is currently in Debian woody and installs without problems)
In fact, all that a large number of dependancies really means is that the programmers are re-using a lot of code, which is generally considered to be a Good Thing.
No you don't. Just like you sell books, you can sell photos. You're selling a copy of the book/photo. The buyer doesn't own the book or photo, just owns the copy. Copyright applies.
OTOH, you could sell the rights away if you want, but you probably don't.
Of course, you could license photos if you want, but that would involve signing a contract, and you may well be doing that (seeing as the publisher will want to reproduce the photo, he'll need extra rights from you in order to do that reproduction, as otherwise it would break copyright law). But just selling a photo doesn't imply that buyer owns the rights to it, since a photo is ultimately just a copy in itself. If you sold the negatives then you might be implying that you're selling the rights, what what you're implying is a separate issue.
IMHO an EULA should not be valid unless something was signed at the time of purchase. Otherwise it should count as any other sale, with you buying a copy of the software for use as restricted solely by copyright law.
Offering a refund if you don't subsequently agree to a change in terms should not be allowed; that means that you were sold the software under false pretences, and in any case is an attempt to change the terms after you have already completed the purchase.
You're right of course. But Sklyarov wasn't a director of the company (as I understand it) so was not responsible for the company's actions, and therefore should not have been arrested. If this had not happened then ElcomSoft's directors would never have entered the US. If this is right, then the US got hold of the directors by arresting an innocent man, which can't be right.
This (of course) only applies to Broadband routers.
Yeah, that's what I meant when I said
(unless you're using a dedicated router thingy, in which case use a linux/freebsd/openbsd/whatever NAT) and (unless they try to use the MAC to work out that you're using a dedicated router box, which I don't think is what the original poster was talking about)
Most cablemodem users that are using NAT are using broadband routers...
OK, I had thought that most would be using custom linux/whatever NAT boxes, figuring that those with enough expertise to know what router to get with NAT or know what NAT is would just do it themselves.
Yes, I do know what I'm talking about. Give me a trace of voltage against time on an ethernet cable, and some time, and I'll tell you what the data in the TCP packet said.
And I wouldn't disagree with you at all with what you just said. But what you said originally makes no sense.
The MAC address of your NAT box is known to your ISP, because your cable modem knows it, and the ISP (presumably) has control over that (and like you said, if it's a bridge then it just passes things through).
But that won't make any difference. Your NAT box contains a NIC just like any other (unless you're using a dedicated router thingy, in which case use a linux/freebsd/openbsd/whatever NAT).
What I'm saying is that the ISP can never tell anything about the MAC addresses used in your internal network, just the one of the thing the cable modem is connected to.
The point is that MAC addressing doesn't in any way help the ISP detect NAT (unless they try to use the MAC to work out that you're using a dedicated router box, which I don't think is what the original poster was talking about).
Unless you're running a normal linux box doing NAT, in which case the NIC would be no different from any other NIC that would go on a single host (and therefore the MAC address wouldn't be different in any way.
No. ARP requests are ethernet broadcasts, and broadcasts (nor any other non-IP traffic) won't be propogated by your usual NAT box. In any case, your NAT box stands between the cable modem and your internal network, so it can block/filter things as it chooses.
They might have been getting the cable modem to give them the MAC address of the device it was connected to (your computer). But if your computer is actually a NAT box with two interfaces, then the cable modem will only see the MAC of the interface on the NAT box it is connected to. The NAT box won't be passing anything else other than plain old IP packets between the two interfaces, and that's on a higher level than what MACs are used for. So the cable modem wouldn't actually see anything but the NAT box, nor be able to tell the difference.
You need to educate yourself on the basics of computer networks. If you connect to your cable modem using ethernet, then sure, your cable modem can see the MAC address of your NAT box. But your NAT box is connected to your internal network through another interface, and it won't be passing any MAC addresses around if your NAT box is only doing IP routing/NAT between the two interfaces (which would be the normal way of setting things up).
Well in that case, anyone sufficiently bothered would do all their support requests/visits to the ISP's website from the box that's doing the NAT. It could also be configured to block access to the ISP's website from internal computers in case of any accidents.
WTF are you on? Firstly, MAC addresses on an internal LAN never get to the ISP, they are used on ethernet, and have nothing to do with IP, except that IP often travels over ethernet.
Second, you want me to get a MAC address from an old NIC, and then get my NAT to use that IP? I can only use the IP my ISP has allocated to me, or else they will know!
And if you meant use that MAC, then how does getting an unused one help, seeing as I'm now using it?
And what has MAC spoofing got to do with anything? Like I said, MAC addresses never get to the ISP!
Get yourself a good networks book and learn what a network stack is. Oh yeah, I forgot, this is/.
Firstly, you initiate the TCP connection, you pick the port numbers. The destination port will be 80, as you want http service. The source port is up to you, but most operating systems start off lowish.
Secondly, 1024 to stop UNIX servers barfing at them (seeing as TCP/IP on Windows was an afterthought).
OK, point taken. But then you'll still to go to your ISP's page with Javascript enabled, which you aren't about to do if you want to keep your NAT. So it doesn't really help them:)
MAC addresses can not be seen by your ISP. Ethernet uses them for addressing, so IP is "tunnelled" over ethernet using them. Anything reading IP over ethernet strips the ethernet framing info before passing it to a higher network layer (like IP), except for filtering locally.
That won't help at all. That lets you see if your ISP is NATing you, not the other way around. The purpose of NAT is that it happens transparently to the outside, and that's what it does.
Another consideration: How does the NAT box know where to send incoming replies? Isn't there something added to the IP header to indicate the internal source IP of the packet? I would think there would have to be. Could they scan packets for these identifying signatures?
The NAT box keeps track of open connections using source/dest ip/port pairs, making sure that the same set isn't used twice (if it were, then it will transparantely switch the source port). Hence Network Address Translation. Nothing needs to be added. NAT on a 2.4 kernel tries to change as little as possible, so the source port won't even change unless multiple internal hosts are accessing the same services on the same destination.
It is still possible to detect things by looking at traffic patterns, though. If you're using a firewall this won't happen, because there is only one computer to generate things. Unless multiple people use the same computer at once. Obviously there's no way for them to be sure this way.
...since I believe the nat gateway uses the address to map packets back to the real destination host.
You believe wrong. MAC addresses have nothing to do with IP level routing, they are there to get IP (or anything else) to get over ethernet. The NAT gateway uses the unique source/dest ip/port to map packets back. The other side of the cable modem sees nothing except the transport to get it over the cable.
Weirdly enough I have an exam which is half on UML tomorrow morning. Scary.
I'd agree mainly with the failures of the book; learning UML wrt. soda machines doesn't really help me see what's going on seeing as I'm supposed to be seeing this from a software engineering viewpoint.
However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author.
And I'd agree with that completely; I'm completely unartistic and have difficulty in dealing with anything that's subjective because I find it hard not to be able to gauge my performance. The fact the author didn't point out where he was making these decisions didn't help, because I keep wondering if I'm understanding something wrong because he's decided to do something one particular way; I'm left wondering if the other way is acceptable or completely wrong.
I also felt like I was being dropped in at the deep end, being shown lots of different types of diagrams with no indication of how they go together until the case study (I presume, as I haven't got that far yet:-)
Oh well, it was the course-recommended text *sigh*
Slashdot Mirror
If the scheduler or virtual memory manager gets a major improvement, that would probably warrent a version 3.0, or so.
Which is why they changed the VM in the middle of the 2.4 series :)
Is a bit accurate, methinks. I think he surpassed us there :-)
Mon, 01 Apr 2002 00:00:00 -0700 (PDT)
Well, that's the whole point. IP-over-carrier-pigeon, remember?
Very good point, I'd mod you up if I hadn't posted and actually had any points left :-)
So the question is, is a single person more likely to be corrupt or not act in the best interests of his job than a corporation? I think ICANN is a particularly bad example, but the idea of a board is that a single person can't do something stupid (but of course the beaurocracy and politics gets involved then).
I'm not sure if there's an answer to that one. A single person with some integrity would be perfect, but if he became corrupt then there'd be major problems. Of course it's easier to get a single person out than a corporation :)
I think they're basically saying that ICANN is going to be destructive to peoples' interests, and so should be absolved of any power as soon as possible; hence the non-permanent, strictly stewardship basis.
I think that in the short-term an organization without political or economic interests needs to be in charge.
Galeon is a small download but can be difficult to upgrade due to its Mozilla and GNOME dependencies.
Dependancy problems? I don't think that's an issue which should affect Galeon at all. Dependancies are supposed to be sorted out by the package management system; problems with dependancies is a failure of the package management system (or the distribution) and not that of any individual client program. (I note here that galeon is currently in Debian woody and installs without problems)
In fact, all that a large number of dependancies really means is that the programmers are re-using a lot of code, which is generally considered to be a Good Thing.
No you don't. Just like you sell books, you can sell photos. You're selling a copy of the book/photo. The buyer doesn't own the book or photo, just owns the copy. Copyright applies.
OTOH, you could sell the rights away if you want, but you probably don't.
Of course, you could license photos if you want, but that would involve signing a contract, and you may well be doing that (seeing as the publisher will want to reproduce the photo, he'll need extra rights from you in order to do that reproduction, as otherwise it would break copyright law). But just selling a photo doesn't imply that buyer owns the rights to it, since a photo is ultimately just a copy in itself. If you sold the negatives then you might be implying that you're selling the rights, what what you're implying is a separate issue.
IMHO an EULA should not be valid unless something was signed at the time of purchase. Otherwise it should count as any other sale, with you buying a copy of the software for use as restricted solely by copyright law.
Offering a refund if you don't subsequently agree to a change in terms should not be allowed; that means that you were sold the software under false pretences, and in any case is an attempt to change the terms after you have already completed the purchase.
Given that it's a new format, they could embed a flash chip of some sort onto the tape too, which stored the directory information.
This wouldn't stop the fragmentation ("holes") appearing in the tape as people record over things though.
Of course, they probably haven't done that :)
You're right of course. But Sklyarov wasn't a director of the company (as I understand it) so was not responsible for the company's actions, and therefore should not have been arrested. If this had not happened then ElcomSoft's directors would never have entered the US. If this is right, then the US got hold of the directors by arresting an innocent man, which can't be right.
This (of course) only applies to Broadband routers.
Yeah, that's what I meant when I said (unless you're using a dedicated router thingy, in which case use a linux/freebsd/openbsd/whatever NAT) and (unless they try to use the MAC to work out that you're using a dedicated router box, which I don't think is what the original poster was talking about)
Most cablemodem users that are using NAT are using broadband routers...
OK, I had thought that most would be using custom linux/whatever NAT boxes, figuring that those with enough expertise to know what router to get with NAT or know what NAT is would just do it themselves.
Yes, I do know what I'm talking about. Give me a trace of voltage against time on an ethernet cable, and some time, and I'll tell you what the data in the TCP packet said.
And I wouldn't disagree with you at all with what you just said. But what you said originally makes no sense.
The MAC address of your NAT box is known to your ISP, because your cable modem knows it, and the ISP (presumably) has control over that (and like you said, if it's a bridge then it just passes things through).
But that won't make any difference. Your NAT box contains a NIC just like any other (unless you're using a dedicated router thingy, in which case use a linux/freebsd/openbsd/whatever NAT).
What I'm saying is that the ISP can never tell anything about the MAC addresses used in your internal network, just the one of the thing the cable modem is connected to.
The point is that MAC addressing doesn't in any way help the ISP detect NAT (unless they try to use the MAC to work out that you're using a dedicated router box, which I don't think is what the original poster was talking about).
Unless you're running a normal linux box doing NAT, in which case the NIC would be no different from any other NIC that would go on a single host (and therefore the MAC address wouldn't be different in any way.
No. ARP requests are ethernet broadcasts, and broadcasts (nor any other non-IP traffic) won't be propogated by your usual NAT box. In any case, your NAT box stands between the cable modem and your internal network, so it can block/filter things as it chooses.
They might have been getting the cable modem to give them the MAC address of the device it was connected to (your computer). But if your computer is actually a NAT box with two interfaces, then the cable modem will only see the MAC of the interface on the NAT box it is connected to. The NAT box won't be passing anything else other than plain old IP packets between the two interfaces, and that's on a higher level than what MACs are used for. So the cable modem wouldn't actually see anything but the NAT box, nor be able to tell the difference.
You need to educate yourself on the basics of computer networks. If you connect to your cable modem using ethernet, then sure, your cable modem can see the MAC address of your NAT box. But your NAT box is connected to your internal network through another interface, and it won't be passing any MAC addresses around if your NAT box is only doing IP routing/NAT between the two interfaces (which would be the normal way of setting things up).
Well in that case, anyone sufficiently bothered would do all their support requests/visits to the ISP's website from the box that's doing the NAT. It could also be configured to block access to the ISP's website from internal computers in case of any accidents.
WTF are you on? Firstly, MAC addresses on an internal LAN never get to the ISP, they are used on ethernet, and have nothing to do with IP, except that IP often travels over ethernet.
Second, you want me to get a MAC address from an old NIC, and then get my NAT to use that IP? I can only use the IP my ISP has allocated to me, or else they will know!
And if you meant use that MAC, then how does getting an unused one help, seeing as I'm now using it?
And what has MAC spoofing got to do with anything? Like I said, MAC addresses never get to the ISP!
Get yourself a good networks book and learn what a network stack is. Oh yeah, I forgot, this is /.
Firstly, you initiate the TCP connection, you pick the port numbers. The destination port will be 80, as you want http service. The source port is up to you, but most operating systems start off lowish.
Secondly, 1024 to stop UNIX servers barfing at them (seeing as TCP/IP on Windows was an afterthought).
OK, point taken. But then you'll still to go to your ISP's page with Javascript enabled, which you aren't about to do if you want to keep your NAT. So it doesn't really help them :)
MAC addresses can not be seen by your ISP. Ethernet uses them for addressing, so IP is "tunnelled" over ethernet using them. Anything reading IP over ethernet strips the ethernet framing info before passing it to a higher network layer (like IP), except for filtering locally.
That won't help at all. That lets you see if your ISP is NATing you, not the other way around. The purpose of NAT is that it happens transparently to the outside, and that's what it does.
Another consideration: How does the NAT box know where to send incoming replies? Isn't there something added to the IP header to indicate the internal source IP of the packet? I would think there would have to be. Could they scan packets for these identifying signatures?
The NAT box keeps track of open connections using source/dest ip/port pairs, making sure that the same set isn't used twice (if it were, then it will transparantely switch the source port). Hence Network Address Translation. Nothing needs to be added. NAT on a 2.4 kernel tries to change as little as possible, so the source port won't even change unless multiple internal hosts are accessing the same services on the same destination.
It is still possible to detect things by looking at traffic patterns, though. If you're using a firewall this won't happen, because there is only one computer to generate things. Unless multiple people use the same computer at once. Obviously there's no way for them to be sure this way.
You believe wrong. MAC addresses have nothing to do with IP level routing, they are there to get IP (or anything else) to get over ethernet. The NAT gateway uses the unique source/dest ip/port to map packets back. The other side of the cable modem sees nothing except the transport to get it over the cable.
AFAIK, netfilter now attempts to change as little as possible, including source port numbers. It'll keep them the same if available.
Weirdly enough I have an exam which is half on UML tomorrow morning. Scary.
I'd agree mainly with the failures of the book; learning UML wrt. soda machines doesn't really help me see what's going on seeing as I'm supposed to be seeing this from a software engineering viewpoint.
However, one of the pitfalls of trying to come up with a case study that outlines a fundamentally subjective process is that some of the design decisions are going to seem arbitrary to some people who don't have a psychic connection to the author.
And I'd agree with that completely; I'm completely unartistic and have difficulty in dealing with anything that's subjective because I find it hard not to be able to gauge my performance. The fact the author didn't point out where he was making these decisions didn't help, because I keep wondering if I'm understanding something wrong because he's decided to do something one particular way; I'm left wondering if the other way is acceptable or completely wrong.
I also felt like I was being dropped in at the deep end, being shown lots of different types of diagrams with no indication of how they go together until the case study (I presume, as I haven't got that far yet :-)
Oh well, it was the course-recommended text *sigh*