jcl

Note that he was awarded a patent for a device that doesn't exist, based on an apparently untested theory, because he speculates that it might eventually be possible to develop technology that does something similar. Good to know that the USPTO takes its job seriously.

Heh. This bug was discovered and partially patched in 1997. History would seem to indicate that "moderately critical" is a slight overstatement

It looks like the iostream header indirectly pulls in cstdlib. It's not portable behavior as far as I know. Not an uncommon problem. Wait till you get into templates. Sometimes I can't believe people use C++ at all.

Huh. Never noticed pkill on Linux before; I always use killall. Vaguely remember using it on Solaris though. SIGHUP terminates the target process by default. The process has to install an appropriate signal handler to get the reload/restart behavior.

File system doesn't matter, it's entirely a memory management issue. Your processor doesn't support NX, so that's right out. It's possible that XP could support something like W^X (which would work on any x86 processor ever made) but if it does I haven't heard about it. But I haven't look either. You aren't really missing much in my opinion.

Indeed. One line in your crontab.

Heh. The idiomatic way to deal with this sort of thing is to use conditional compilation via preprocessor guards. void clear_screen() { #if defined WIN32 system("cls"); #elif defined UNIX system("clear"); #endif } The preprocessor will insert the code corresponding to the first branch of the conditional that tests true (or will remove the code for the false branches, depending on how you look at it). When the source file is compiled you have to compiler define which ever symbol fits the current platform. For Linux/GCC you would use something like $ gcc -DUNIX foo.c Normally you'd

It's supported by current Intel processors as well, as eXecute Disable (XD). It can also be kluged into older IA-32 processors; OpenBSD's W^X does it by fiddling with the segmentation support left over from caveman days.

The only portable way is to blast enough newlines through the output stream to scroll away anything that might be there.

Correct across the board. Including the bit about your teacher

Falling off the end of a function is equivalent to a return statement without a value and is only legal in functions with a return type of void (i.e. functions that have no return value). But as a special case falling off the end of main() is eqivalent to returning a value of zero.

The operating system doesn't matter. Vulnerabilities in the browser are local to the browser. Vulnerabilities in the operating system aren't Mozilla's problem. Browsers, Web servers, Internet services, a few other things.

It's an antitrust case, it doesn't have to make sense. What happened was that EU found that MS had abused its monopoly to damage competitors in the audio/video software market. It's apparently a principle of antitrust law that the punishment should be related to the crime, no matter how silly or ineffectual that punishment might be. Bonus points if it hurts consumers. There's also a €500 million fine (a whole week of revenue for MS), an ongoing battle over opening some comm protocols for licensing, and some other stuff. It's a fairly significant case.

Agreed. Most likely his machine either doesn't support APM or ACPI or power management is disabled in XP. AFAIK it can be enabled in XP manually by fiddling in the device manager (the 'Computer' driver or something) but if I'd be hesitant to force it. Given the general quality of hardware/firmware support for power management in PCs I'm more surprised when the operating system can power down a system than when it can't. I haven't owned a machine yet that didn't have some kind of PM breakage.

For those who haven't heard: This is part of a large-ish antitrust battle between the EU and MS. Short story is that the EU is forcing MS to ship a version of Windows XP sans Media Player. Microsoft, showing a bit of a sense of humor, initially planned to call the resulting system 'Windows XP Reduced Media Edition'. The EU rejected that name and after some back and forth both sides have agreed to call it 'Windows XP Home Edition N' and 'Windows XP Professional Edition N'. It will be interesting to see how Longhorn is affected. One the one hand it's supposed to be more modular, so it might

Indeed. Quoth RFC 2616 (HTTP/1.1)

If the readers can cope with a little work, the old hand-scrambling methods -- "foo at bar dot com" and the like -- seem to work reasonably well. Lots of variations on Usenet. Yup. As long as the address isn't in the form.

An IP address is... well, an Internet Protocol address. Pretty much like any other kind of address in intent and application. IP version 4 addresses are 32-bit words usually treated as a sequence of four octets (bytes) and written in the familiar xxx.xxx.xxx.xxx style where xxx is an integer in the range 0 .. 255. Maybe the best known example is 127.0.0.1, the loopback address. A DNS cache is a set of mappings from host names (e.g. www.besttechie.net) to IP addresses (e.g. 67.43.1.57). Like most caches it's used to speed up operations by keeping data nearby and thereby avoiding the expense

This is wonderful. If I'm not mistaken this the first distro war we've had on BT. And what a surprise, Gentoo is involved. Seriously, I didn't see that coming. Really. If I had a camera I'd post a picture of my expresion of wonderment. It looks a bit like this: 8-/ I honestly absolutely never would have expected this.

Not much I can do to help (never used MDK or a modem under Linux) but for those of you in a better position the MDK 10 driver is here.

Nope. The error is a caused by a combination of the rate at which the clock is polled and the lack of synchronization between the clock and the program. It's very, very unlikely that the program will check the clock exactly once per second at the exact moment when the clock rolls over to a second. You can make it more accurate by increasing the polling rate but it's not going to be perfect. There are also environmental factors. For example, preemptive multitasking really screws with timing. It's possible that there will be a context switch between the clock poll and the execution of the l

You're right, it doesn't make much difference. In most cases it's optimizing the idle loop. You spend hours applying heavy optimizations to programs that aren't CPU-bound in the first place. It may shave a few seconds off of some operations but odds are the time saves will be less than the time spent building the software. There are of course exceptions, but they're few enough that you can handle them individually. Which you probably want to do anyway. There is no single set of CFLAGS that will produce ideal results for all packages. In fact the effects of the various flags are almost

Ubuntu is a Debian derivative. Other than that and the installer thing it was an accurate assessment /me ponders why popular opinion is that Ubuntu is easy and Debian is difficult when they use more or less the same installer, packaging tools, desktops....

It should be /etc/X11/XF86Config or XF86Config-4. As I recall Xorg broke config file compatibility with XFree86 a while back -- changed the name of the keyboard driver or something -- but it shouldn't be a difficult fix. I think the xorg.conf I'm using on my desktop was originally an XF86Config-4 from before Xorg was released. Edit: AFAIK it's generated when the systems boots. It wouldn't do much good to copy the generic config file anyway

Multiply by 60 or 3600 // Loop for an hour and a quarter for (time_t t = time(0); difftime(time(0), t) < (3600 + 15 * 60); ) { cout << a; } The error is determined by the granularity of the clock. If you build the timing code on top of a second-based clock it should be accurate to within a second or so. 'course you'd need to test it to be sure (rule to live by: test everything) which could be a problem if the timeout is quite long. You also have to factor in the time it takes to execute the code within the loop. There are better ways to do this, but they're non