More troublesome, sophisticated computer users can "spoof" IP addresses, or use one assigned to somebody else. They use a simple piece of software to forge the IP address on packets of information sent from their computer, much like someone who puts an address on the back of an envelope that isn't theirs. The people most likely to spoof are the very tech-savvy youngsters also mostly likely to be stealing music. Even if the RIAA had an IP address it believed belonged to Andersen, Lybeck thought, that wasn't necessarily the case.
An otherwise good article got it wrong here.
Sure you can place a forged source address in an IP packet that you send. But no conversation can take place because the Internet "knows" a route to that forged address (which isn't your machine) and it is not possible to change that.
Yes, that's true. It seems Microsoft has found a way to break compatibility with foreign DHCP servers and be able to claim that they are conforming with standards. Clever.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
That's part of the point. If a program uses $HOME instead of getpwent or whatever, that means I can have multiple config profiles for that program saved somewhere, assuming it doesn't support them by itself.
Of course a programmer *could* design that behavior. More typically, programs are designed to look in the home directory (obtained though the POSIX getpwuid() function call designed for that purpose) or use the file specified in the -f option on the command line.
Personally, I think it's silly to expect programs to rely on the/etc/profile or similar mechanism to set an environment variable to obtain the user's home directory instead of the API for that purpose. It certainly doesn't save anything -- getenv() vs. getpwuid(). And it could be wrong.
Now what exactly does skype need to know my or anybody else's account name for? I've got no clue, but I'd be very interested to find out.
It probably doesn't. But it most certainly needs to know how to open its configuration file, which it expects in your home directory. To get the path to that file, it calls getpwuid(). That library routine, on a system configured without network files like NIS+ or LDAP, will open/etc/passwd to obtain, among other things, your home directory.
I just searched the source of Pidgin (because it is open source) and found it does indeed access/etc/passwd through getpwuid(getuid())
Yes, that's because it needs to know the user's home directory to find its configuration file. There are many applications that do the same (innocuous) thing.
The most common reason these applications and others read/etc/passwd is that they call getpwuid() to obtain a struct that contains the user's home directory. Now the application knows where to find its configuration files.
you can be using Kubuntu at home, and if you go over to your friend who's using Ubuntu unless you're familiar with Linux in general you might well be left scratching your head trying to figure out how to do what you want to do.
Perhaps you could describe the differences between KDE and GNOME that would leave a KDE user "scratching his head" when looking at a GNOME desktop.
perfectly usable for copying a file from disk to disk in a non networked fashion
From sendfile(2):
Presently (Linux 2.6.9): in_fd, must correspond to a file which sup- ports mmap()-like operations (i.e., it cannot be a socket); and out_fd must refer to a socket.
Applications may wish to fall back to read(2)/write(2) in the case where sendfile() fails with EINVAL or ENOSYS.
IBM instructed developers to purge their sandboxes. This, of course, has nothing to do with the source code in IBM's source control systems. It's just working copies on developers' machines.
Slashdot Mirror
An otherwise good article got it wrong here.
Sure you can place a forged source address in an IP packet that you send. But no conversation can take place because the Internet "knows" a route to that forged address (which isn't your machine) and it is not possible to change that.
Just run your own caching server.
http://zsh.sourceforge.net/FAQ/zshfaq04.html#l44
I think you meant 370/168.
Yes, that's true. It seems Microsoft has found a way to break compatibility with foreign DHCP servers and be able to claim that they are conforming with standards. Clever.
Of course a programmer *could* design that behavior. More typically, programs are designed to look in the home directory (obtained though the POSIX getpwuid() function call designed for that purpose) or use the file specified in the -f option on the command line.
Personally, I think it's silly to expect programs to rely on the /etc/profile or similar mechanism to set an environment variable to obtain the user's home directory instead of the API for that purpose. It certainly doesn't save anything -- getenv() vs. getpwuid(). And it could be wrong.
Of course, no one could ever modify his environment before running a program. That wouldn't be fair.
The most common reason these applications and others read /etc/passwd is that they call getpwuid() to obtain a struct that contains the user's home directory. Now the application knows where to find its configuration files.
Perhaps you could describe the differences between KDE and GNOME that would leave a KDE user "scratching his head" when looking at a GNOME desktop.
This has been said before: the BSD license allows proprietary use. It's not stealing.
I figured I'd vote with my wallet.
From sendfile(2):
I think you mean quash.
NetworkManager has always worked for me on KDE. First with the GNOME applet and now with knetworkmanager -- the KDE applet.
This is old news.
IBM instructed developers to purge their sandboxes. This, of course, has nothing to do with the source code in IBM's source control systems. It's just working copies on developers' machines.