There used to be something like a 2-line kernel patch that did this. The kernel messages can be retrieved by 'dmesg' command or by peeking in/var/log/messages, and they all scroll past in less than a second on my machine so there's not much point in having them at all. I believe that KNOPPIX uses something similar.
It would be nice if the entire kernel-to-login-prompt boot sequence was also logged to syslog rather than the console.
A black screen would be nice, then my login screen for my choice of OS.
I'm with you here, except that if something breaks, I want to be bloody certain that I can see those messages so's I can efficiently fix it.
(BTW, I suppose you could say that my machine is 50% of the way to your goal... it has two monitors, and one of them is blank right up until X11 is ready. No login screen, 'cos it's a single-user PC.)
What appears in the From: line and what appears in the SMTP "MAIL FROM" command are often two entirely different things. The former is set by you, the latter is usually set by your MTA.
No. The vast majority of the time, the MUA gives the MTA a MAIL FROM address which is identical to the From: line in the mail.
Anyway, the basic idea has been around for a long time: the server will keep sending data packets even if the client has not acknowledged receiving some of the previous ones. There is usually a set window size... as in, it will send up to x packets ahead - after which, it will chill for a while and wait for responses to come back for previous ones.
It's TCP that does that, not FTP, so the same will apply to HTTP connections too.
Copying it instead of moving it is bloody stupid, though. I have a friend with a cable modem connection on an old computer with a very slow hard drive. It takes longer to copy a big file from the cache directory to wherever it was supposed to end up than it does to download the file in the first place at ~250kb/s.
I wonder what IE does when there's only enough room for one copy of the file on the drive.
wget -r -l1 http://http.server.name/path/to/dir/ will suck down all the files in that directory; wget -r -np http://http.server.name/path/to/dir/ will pull it down recursively.
So let me get this straight; you're using NAT, but are too incompetent to properly configure it for your NAT'ed servers, and this is a fault of the protocol?
No. If you have an SSH-encrypted connection with both ends NATted, there is no way for either end to connect directly to each other, nor any way for the NAT box to fiddle with the IPs that are sent across the FTP control connection (as that would constitute a MITM attack on the SSH connection).
Chroots are impossible to break if they don't run as root. The only way to break out of a chroot() is to do something like chroot("/../../../"); the chroot system call is only available to root for security reasons.
I don't believe that standard UNIX/Linux systems come with a program that provides shell-level access to running a chrooted program as a non-priviledged user; I wrote a little C program a while ago that does this - chroot-setuid.c
It makes configuration easier - like DHCP, only without needing DHCP:) Once your router/firewall/gateway machine has an IPv6 address, it broadcasts it the prefix (first 64 bits, IIRC) to the local network. Other machines on the network will configure their own IP address to be the prefix, with their MAC address tacked on the end, and likely set their default gateway to the router.
The letters "chi" and "rho" look like X and P respectively.
Blimey! I never thought of that... I remember reading shortly before Windows 95 was released that the Microsoft codename for Win95 was "Chicago" and the codename for the next Big Consumer Release, which would be completely NT based (i.e. the one which we now know as Windows XP) was codenamed "Cairo". How incredibly sneaky... Cairo... Chi Rho... XP
If the sending server doesn't serve the domain, then it's a bogus return address.
Not necessarily. As an example, I have several email addresses at different domains. I send mail through my own mail server, which is not the primary MX (i.e., the server responsible for handling incoming mail for that domain) for any of them.
Many ISPs, too, have separate incoming mail servers and outgoing mail servers. In general, there is no way to tell whether the return address is correct purely by what mail server is sending it.
No, you're misunderstanding how this works. Cross-compilers have been around for ages, this one just happens to have the advantage that it inherently portable (because it is based on GCC) and targets Windows (which is phenomonally popular).
Wine works by reimplementing a part of the Windows API. Mingw32 is a compiler which takes C/C++ programs and Windows libraries and generates Windows executables. Its C/C++ support is just about flawless as it uses GCC; it can link programs against native Windows libraries just like any Windows compiler would; and it produces ordinary Windows executables.
These Windows executables, however, won't run natively on the (Linux) host machine.
Note that this is also not an automated system for writing portable programs; Xmingwin won't compile anything that wouldn't compile on a normal Windows machine. But if you have code that is portable, you can save a lot of hassle by having just one machine to build binaries for several platforms.
Rubbish! Excluding the fact that I have seen few viruses in the last few years that weren't spread by holes email clients such as Outlook, the output of a compiler can generally be assumed to be virus free. (The exception would be for a hack similar to Ken Thompson's trojan login on the original Unix, but the chances of that working on diverse systems such as Linux and *BSD is somewhat unlikely.)
A hacked native Windows compiler seems to me to be much more likely.
Dunno if it supports WinNT/Alpha, but it should run on NetBSD - after all, it's just a slightly modified version of gcc with some supporting tools for making Windows executables.
Indeed there is. Apache has mod_throttle which does this, and there are doubtless similar solutions for other web servers. Still, most people don't think about implementing them until it's too late.
Slashdot Mirror
Sadly, I wasn't.
There used to be something like a 2-line kernel patch that did this. The kernel messages can be retrieved by 'dmesg' command or by peeking in /var/log/messages, and they all scroll past in less than a second on my machine so there's not much point in having them at all. I believe that KNOPPIX uses something similar.
It would be nice if the entire kernel-to-login-prompt boot sequence was also logged to syslog rather than the console.
A black screen would be nice, then my login screen for my choice of OS.
I'm with you here, except that if something breaks, I want to be bloody certain that I can see those messages so's I can efficiently fix it.
(BTW, I suppose you could say that my machine is 50% of the way to your goal... it has two monitors, and one of them is blank right up until X11 is ready. No login screen, 'cos it's a single-user PC.)
No. The vast majority of the time, the MUA gives the MTA a MAIL FROM address which is identical to the From: line in the mail.
With the new law, Americans can get an extra five years on their sentence if the felony involved encryption.
It's TCP that does that, not FTP, so the same will apply to HTTP connections too.
Ettercap is your friend here. :)
I wonder what IE does when there's only enough room for one copy of the file on the drive.
wget -r -l1 http://http.server.name/path/to/dir/ will suck down all the files in that directory; wget -r -np http://http.server.name/path/to/dir/ will pull it down recursively.
No. If you have an SSH-encrypted connection with both ends NATted, there is no way for either end to connect directly to each other, nor any way for the NAT box to fiddle with the IPs that are sent across the FTP control connection (as that would constitute a MITM attack on the SSH connection).
I don't believe that standard UNIX/Linux systems come with a program that provides shell-level access to running a chrooted program as a non-priviledged user; I wrote a little C program a while ago that does this - chroot-setuid.c
CP.
Mozilla supports IPv6 natively. Not sure about Internet Explorer.
It makes configuration easier - like DHCP, only without needing DHCP :) Once your router/firewall/gateway machine has an IPv6 address, it broadcasts it the prefix (first 64 bits, IIRC) to the local network. Other machines on the network will configure their own IP address to be the prefix, with their MAC address tacked on the end, and likely set their default gateway to the router.
The author certainly doesn't look like he's twelve.
I think that would be what one calls "changing font settings".
What about this page?
Absolutely. But what're you going to do, bleed on me?
Blimey! I never thought of that... I remember reading shortly before Windows 95 was released that the Microsoft codename for Win95 was "Chicago" and the codename for the next Big Consumer Release, which would be completely NT based (i.e. the one which we now know as Windows XP) was codenamed "Cairo". How incredibly sneaky ... Cairo ... Chi Rho ... XP
Not necessarily. As an example, I have several email addresses at different domains. I send mail through my own mail server, which is not the primary MX (i.e., the server responsible for handling incoming mail for that domain) for any of them.
Many ISPs, too, have separate incoming mail servers and outgoing mail servers. In general, there is no way to tell whether the return address is correct purely by what mail server is sending it.
Yes, they still have the coke machine.
Wine works by reimplementing a part of the Windows API. Mingw32 is a compiler which takes C/C++ programs and Windows libraries and generates Windows executables. Its C/C++ support is just about flawless as it uses GCC; it can link programs against native Windows libraries just like any Windows compiler would; and it produces ordinary Windows executables.
These Windows executables, however, won't run natively on the (Linux) host machine.
Note that this is also not an automated system for writing portable programs; Xmingwin won't compile anything that wouldn't compile on a normal Windows machine. But if you have code that is portable, you can save a lot of hassle by having just one machine to build binaries for several platforms.
It isn't different at all. Xmingwin is just the term that the author of the article uses to refer to a mingw32 cross-compiler.
A hacked native Windows compiler seems to me to be much more likely.
Dunno if it supports WinNT/Alpha, but it should run on NetBSD - after all, it's just a slightly modified version of gcc with some supporting tools for making Windows executables.
'twould be legal if the person downloading it already owned a copy on CD.
Indeed there is. Apache has mod_throttle which does this, and there are doubtless similar solutions for other web servers. Still, most people don't think about implementing them until it's too late.