An attacker using this exploit can run arbitrary code. They can control your mount table, and mount a malicious NFS or SMB share over some directory whose contents get run a lot (for instance, they could replace your crontab with one that downloads and runs an evil executable of their choice, or replace/lib to contain a modified copy of libc that does evil things whenever you start a new executable).
Of course, the attacker is intent on getting shell access, they could always use one of the above techniques to start sshd.
Your config files are scattered all over your system, and I'll bet you don't know where half of them are.
On some older Linux systems with silly locations like/usr/local/etc, that might be true. On newer distributions that's just not true - they're in/etc.
According to the Filesystem Hierarchy Standard (which Linux distributions are converging towards), system-wide config files are required to go in/etc. In Debian, putting a file elsewhere when it should be in/etc is a bug; I seem to remember it counts as Serious, because it's a policy violation.
The converse is also true. If a file is in/etc but is not a configuration file, it shouldn't be there, although there are a couple of exceptions for historical or technical reasons[1].
To get users' personal config files (and documents) you also want a backup of/home, and you might also want to hang onto bits of/var (on a dpkg-based system, if you have a backup of/var, you have a complete list of installed packages, which is nice to have around).
--- [1] On my Debian system,/etc/rmt is a trivial shell-script wrapper for a program which was historically required to be in/etc (8 lines, of which 6 are an explanatory comment)./etc/mtab and/etc/ifupdown.state are variable state files which should probably be in/var, but need to be used early in the boot process before/var is guaranteed to be mounted.
The fact that it was there in the first place was a workaround for stupid legal issues - at the time GnuPG development started, the author wasn't sure whether DSA signatures were patented, so he allowed El Gamal keys to be used for signatures as well as encryption. It turned out DSA signatures were OK, and the default for all recent versions is to use DSA signatures with El Gamal for encryption.
The other available key types (RSA+RSA, DSA+El Gamal) are there for interoperability; I think the consensus seems to be that DSA+El Gamal is probably better, but RSA+RSA needs to be there because that's what the original PGP used.
On the other hand, I agree that it sounds from the announcement as though the optimizations that caused the flaw were unwise.
That "Lytha Way" reminds me of some recent guest articles on diabloii.net, in which an expert Diablo II player describes how he completed the game on Hell difficulty with the following strange characters:
- A melee-only Sorceress whose name I forget: her primary spell was Teleport (for targeting purposes), with Enchant (extra damage) in a secondary role
- Gunter, the Barbarian who wanted to be a wizard: a Barbarian with no melee ability whatsoever, using only warcries and the fire spells provided by the items he was wearing
- Maldar the Magnificent, the compassionate, pacifist Necromancer: completed the game without killing a single monster, except those that had to die in order to complete quests (quest bosses and so on). His primary spells were Bone Wall (summon a wall), Bone Prison (trap a monster), and Dim Vision (target monster can't see).
An attacker could override arbitrary directories, if they could control the mount table. As another poster pointed out, if they mounted a network share containing a malicious script over the top of, say,/etc/cron.daily, you'd never know, and it'd execute at midnight.
Alternatively, if they knew your OS version, they could replace/lib with a nearly-identical version, except that the standard C library (libc) contained some sort of malicious code which executed once (the first time fork() was called, say), and it'd get loaded the first time you ran any dynamically-linked program. Again, unless you habitually mess with the contents of/lib (not advisable), you'd never know - the only symptom would be a slight slowdown when starting new programs, and it could even be coded to be self-removing so it only triggered once, while quietly opening up remote access in the background.
It's quite possible to override a DHCP server, even without intending to; the request is broadcast, and if multiple machines send a response back, the first one received wins.
I've been bitten by this myself: I have cable at home, and someone on the same subnet has (presumably) set up their NAT box backwards, so when I request a DHCP address, I get one of their internal addresses (192.168.100.x) as well as one from the ISP. Because they're on the same subnet and the ISP's DHCP server is elsewhere on the network, they consistently return a response faster, too.
I worked around that by configuring my DHCP client daemon to ignore all responses from the 192.168.100 subnet, but that's not an option if your DHCP client isn't configurable.
It depends whether the NPC in question had been thought of when the engine was written, or whether it was added later. I don't know how often Everquest developers update the client, but if it had no concept of "invincible", it's possible that they would decide a client update would be too much effort, and stick to things the client could already do.
I used to make mods for X-Wing vs TIE Fighter; admittedly, the available tools were all reverse-engineered, so we never really knew for sure what the engine was capable of, but it was pretty limited in areas Totally Games (the developers) hadn't needed.
One of the early XWvTF missions that used add-on models was the Death Star trench run from A New Hope. The Death Star was represented by a square something like a hundred miles wide, with a trench running across it (10 polygons making up 5 rectangles - "ground" to the left, "ground" to the right, and two sides and a floor for the trench). A few other mod makers (including me) used the same mesh as a convenient representation of "the ground" in other ground-based scenarios.
It turned out that the XWvTF engine didn't have a form of invincibility that was useful; the "invincible" flag in mission files actually meant "no collision detection", and flying down the Death Star trench pursued by TIE fighters would be no fun if you flew straight through it whenever you should have crashed, so people usually just gave it a few million points of hull strength instead.
In the sequel, X-Wing Alliance, "invincible" was implemented in a much nicer way: invincible ships could get hit, they could lose shields, they could even be seriously damaged (slightly alarming in one mission where you fly alongside Luke Skywalker), but they never dropped below 1% hull strength.
(If you still play XWvTF or XWA, see my linked homepage for some old custom models and an XvT mission pack)
American English is already used like technical standards on the Internet. People don't drop their native languages (just like app authors don't often drop their native formats), but they do use English in contexts where "cross-platform compatibility" is important (newsgroups/mailing lists/forums - wherever they don't know whether the people involved will understand their first language).
I quite like having Unicode formats myself, ASCII isn't quite good enough. Never mind transcribing foreign words, ASCII can't cope with correct English typography either:-)
The hardware's fine, it's the software that's wobbly.:-)
"unstable", a.k.a. "sid", is the section of Debian that new software gets uploaded to - it's sometimes a bit untested, but usually works. It's good for development, and it's also necessary if you have new hardware that older releases don't support properly, like my Powerbook.
Whenever I see a mention of automated keyword matching like this, I wonder what such a system would think of gamers discussing Counterstrike or TFC.
"... yeah, they got the hostages back; we managed to plant the bomb in the missile silo though. One of the SAS guys tried to defuse it, but I shot him with my AK-47, so the terrorists won."
purl.org provides "persistent URLs", basically a permanent HTTP redirect (for instance, the Dublin Core people use http://purl.org/dc/ which redirects to http://dublincore.org/ - more importantly, they use purl.org for namespace URLs which need to stay valid indefinitely, like http://purl.org/dc/terms/1.0 which redirects to the Dublin Core Terms specification in RDF).
These don't address the fact that documents get altered or deleted, for which you're still dependent on the original author maintaining the old content at the same URL.
Sometimes documents not being modified isn't necessarily what you want, anyway - for instance, sites with navigation/stylistic stuff "wrapping" the content (like my site) might want to redo that without altering the content.
Also, sometimes a URL isn't meant to always refer to one version, but is meant to refer to the latest version (like w3.org specifications, which have a long date-stamped URL for "this version", and a short URL for "latest version of this specification").
Basically, it's up to the content author to follow good practices.
On pseudorandom.co.uk I use a year in the URL for all permanent content, except a couple of "navigation" pages (the games section, the "contact me" page) which pre-date my current URL scheme - there are so many references to those elsewhere in my site, I don't want to have move the pages, fix the links and install redirectors.
For content that existed before I switched to year-based URLs, I moved the content page to a new URL based on the year of first publication, and installed redirectors from the old name (mod_rewrite is very useful for this sort of thing).
The university I'm at has a simple policy to avoid running out of bandwidth: they monitor bandwidth use per IP address (or per physical network socket, I'm not sure which way they run it). If you consistently use too much (where "too much" roughly means "enough to inconvenience everyone else"), they tell you to stop. In theory, if you keep using too much, they disconnect you, but in practice most people get the hint after the first warning or two. Formally, we aren't told what the limit is; informally, I've heard the computing service start taking an interest once you break 1GB/day on a regular basis.
As a matter of policy, they don't sniff network traffic (they'd rather not be responsible for it).
They do block a couple of ports, but only the ones you really don't want to use over the Internet (NetBIOS) and a couple they need to block for policy reasons (SMTP to the outside world is blocked, to make sure that if we spam, it goes through the central mail relay, so they can tell who was responsible; it's a little annoying, since I can use my web host as an authenticated relay from any network except university, but I can live with it).
I think it's even possible to convince them to unblock those ports for your IP, if you can come up with a good enough reason, although I've never tried.
It's a good policy IMO; you can't transfer huge amounts of data all the time, but you can have very impressive bandwidth for a short time (I've downloaded Linux ISOs from another college at about 40MBit/sec!) and pretty much any network protocol is allowed (good for computer science students and like-minded people).
I know I'm anonymous, but can anyone tell me whether I have to/ really really should turn on devfs if I upgrade to 2.6?
I've tried using devfs under 2.4 several times but have never succeeded in getting it to work with my crufty (been around since slink) debian box.
And since I use ALSA and XFS the 2.6 kernel would simplify compiling desktop kernels no end.
I don't know about 2.6, but I use 2.4.x with devfs on two stable boxes ("servers" running on obsolete desktop hardware) and two unstable boxes (a desktop and a Powerbook), and they all work fine. Tab-completing commands is so much nicer when you only have device nodes for hardware you actually have; it's also handy to be able to see (say) whether your CD drive was detected properly, or how many partitions a hard disk has, by looking at the device nodes.
If you're using at least Debian 3.0 stable (woody), install devfsd, install a devfs kernel, reboot, and everything should Just Work.
Debian's packaged X display managers have TCP/IP connections disabled by default; they only accept connections from the local machine, via Unix domain sockets (which have conventional Unix user-based access control, as well as the XAuth authentication system) and via shared memory.
However, the fact that the underlying protocol is network-transparent enables ssh tunnelling to work (the ssh process at each end of the tunnel basically acts as a proxy for the Unix domain socket).
hundreds of programs from different sources... almost all of which need a Unix C runtime library ("libc").
If you have access to a Debian machine (or something else which uses dpkg), try this:
dpkg --simulate --remove libc6
(you might need/sbin and/usr/sbin in your PATH; if you don't use something Debianish, I'm sure other package management systems like RPM have an equivalent incantation)
This will tell you what would happen if you removed libc6; on my computer, it complains about broken dependencies for around 750 packages, including Konqueror, KOffice, OpenOffice, Mozilla, XFree86, Apache, Perl and Python to name but a few. That's not including things which depend on libc indirectly (for instance, Perl modules which need Perl).
Anyway, you'll observe that hundreds of programs from different sources depend on having a C library, and won't be much use without one. In the case of Debian (and every other major Linux distribution I'm aware of), the default C library is glibc 2.x, also known as libc6.
(If your distribution statically links some executables, they won't actually need a C library at runtime, but only because they have the necessary bits embedded in them at compile time - it's likely that they'll have been compiled against glibc too, and therefore will contain parts of glibc.)
It's entirely possible to put together a distribution of Linux which uses a different implementation of libc as its C library (as I mentioned, revol is such a system - if I remember correctly, it uses dietlibc), but few distributors do.
It's also possible to put together a distribution of Linux with no libc at all, but it wouldn't be an implementation of Unix, and if you wanted to actually achieve anything with it, you'd have to reimplement a lot of the basics yourself.
Gnome users might be using GNU/Linux, but KDE users sure aren't.
Really?
$ ldd/usr/bin/konqueror | grep libc
libc.so.6 =>/lib/libc.so.6 (0x0e89c000) $ ldd/usr/lib/libkdecore.so.4 | grep libc
libc.so.6 =>/lib/libc.so.6 (0x6fa17000) $ dpkg -S/lib/libc.so.6 libc6:/lib/libc.so.6 $ head -2/usr/share/doc/libc6/copyright This is the Debian prepackaged version of the GNU C Library version 2.3.x
Without glibc, my Debian box certainly wouldn't be much of an OS - practically none of the programs would work. The major components of a Unix system are a kernel and a C library - Linux is only one of those.
Incidentally, if you think you can use XFree86 and KDE on Linux without needing command-line tools, I suggest you have a look at the scripts your system uses to boot, particularly the line "#!/bin/sh" at the top. Just because you don't use them yourself doesn't mean they're not necessary.
(On the other hand, I've seen one Linux distribution which can reasonably claim to not be GNU/Linux - revol, which runs on Psion Revo electronic organisers with 16M of RAM and no disks or removable media. It doesn't use GNU tools and libraries because they're too big; if I remember correctly it uses dietlibc for the C library and busybox for the shell utilities.)
X is a low-level component; it's the implementation of GUI mode. You almost always interact with things that use X, rather than with X itself - for instance, instead of drawing window frames and resizing windows for you, X has the concept of a window manager, which is a separate program to draw window frames and handle resizing/etc.
I'm sure 9/10 Mac users don't understand Quartz, and I certainly don't understand X or the equivalently low-level bits of the Windows GUI (I said MFC in the subject line, but as I understand it, MFC is more like a toolkit like Gtk or Qt - I don't know whether the Windows GUI even has a name, since it's so tightly attached to the rest of Windows).
Unless you're programming to the X protocol (or complaining about its perceived shortcomings, which seems to be a popular activity in any X-related story on/.), you don't really need to understand X, any more than you need to understand the finer points of ext2 in order to manipulate files.
The only bits of X you might need to understand for "normal use" are the areas where it touches the user experience, like the clipboard, the fact that you can remap keys, possibly the concept of a window manager, and perhaps the fact that there is a program called an X server which provides your GUI.
In a "consumer" Linux distro, ideally you'd interact with X settings via something like the KDE Control Centre, or the GNOME or other desktop equivalent. Obviously, it's still nice to have plain-text config files behind the scenes, so if something breaks seriously, it's possible for an experienced user to fix it - a Windows-like "you have a GUI or you have nothing" approach is equally good for inexperienced users, but if it breaks, experienced users don't have that chance to fix it.
While I agree that distributing "keygens" is unethical, putting my "devil's advocate" hat on for a minute, I don't really see how it's an infringement of copyright:
Suppose I reverse-engineer an app that uses CD-keys (Gamespy 3D, say) and determine how it checks CD-keys.
Further, suppose I write a keygen which produces valid CD-keys on request. Remember, a CD-key is just a meaningless string with some particular property - if I remember correctly, one app a few years ago accepted any multiple of 7 as a key.
OK, now suppose I distribute the keygen, which consists entirely of my code.
If you assert that I infringed copyright at some point during that process: when did I distribute a creative work created by Gamespy?
If you think the situation I described would involve breaking the law: instead, suppose someone else reverse-engineered Gamespy 3D and told me how it checks keys, and I did a "clean-room" implementation of a keygen based on that. Would that be legal? If not, which of us would have broken the law?
Right-click on "Listen to All Tracks: Hi-fi Play" for the artist you're interested in (actually listen to something first so they set the cookies and stuff - no need for a real e-mail address, I used one that bounces), save the.m3u file somewhere, and
wget -i whatever.m3u
or to preserve artist names as subdirectories (as I did, since they're not always very good at ID3-tagging their content)
for f in *.m3u; do b=`echo $f | sed -e s,\\.m3u,,`; mkdir -p $b && ( cd $b && wget -i../$b.m3u ) && touch $b/done; done
Um, as far as I'm aware, we *have* a reliable (and consistent) copy/paste. No, it's not *exactly* the same as in Windows (in case you hadn't noticed, X desktop environments aren't Windows), but if you use common "end user" apps like KDE 3.x, Gnome and Mozilla, you won't go far wrong by assuming everything works like Windows.
There are two "selections", PRIMARY and CLIPBOARD (actually, there's also SECONDARY, but I'm not aware of any program which ever uses it). X just provides these, it's up to application authors (or toolkits used by those authors, like Gtk+ and QT) to do something sensible with them.
Not forcing a particular "policy" is a general principle the whole of X follows, for better versatility - if it didn't, we'd be stuck with either 1970s UI conventions, or rewriting X. Instead, X lets applications decide on their own behaviour - if you want consistent behaviour, you can have it, if you want inconsistent behaviour (or if you want to establish a new convention) you can have that too.
Anyway, the established convention is that CLIPBOARD is like the Windows clipboard; Edit/Copy, Edit/Paste, Ctrl+C and Ctrl+V act on it. This works in the vast majority of X apps.
PRIMARY is the currently selected text, and is a transient sort of thing; as a bonus feature for experienced users, you can copy it into another application by middle-clicking. However, you can use KDE 3.x or Gnome without needing to know that PRIMARY exists.
Informal documentation: http://www.jwz.org/doc/x-cut-and-p aste.html (that page links to the formal specification).
The historical problem the parent post might be thinking of is that KDE 1 and 2 used to do it wrong (they used PRIMARY for the copy/paste menu items and Ctrl+C/Ctrl+V, ignoring CLIPBOARD; just selecting text didn't do anything useful). This was horribly inconsistent, but has been fixed now (as far as I know, only Debian still has a version with this problem in its current release, and Debian 'stable' is notoriously out-of-date).
KDE 3.x has been changed to work the same way as other apps do: selecting text copies it to PRIMARY, middle-clicking pastes from PRIMARY, Ctrl+C or Edit/Copy copy to CLIPBOARD, Ctrl+V or Edit/Paste pastes from CLIPBOARD.
The convention even extends to terminal emulators, by the way. xterms only use PRIMARY (they don't have a menu with Copy/Paste options, and Ctrl+C/Ctrl+V need to go to the terminal as-is), but if you're using xterm you're probably an experienced enough X user to know about middle-clicking anyway.
Meanwhile, KDE 3's Konsole has Copy and Paste menu items which use CLIPBOARD just like any other KDE app (or just like "DOS boxes" in Windows, for that matter); I assume gnome-terminal does the same, although I haven't used Gnome for a while.
That's precisely the point, people *don't* want to do boring repetitive tasks, especially if they know enough about computers to know that the computer could do it for them.
OK, how about:
- In a word processor document, do something based on formatting; for instance, put all bold, underlined text into 24pt and remove the underlines.
(Yes, I know someone who understood the word processor would have used a stylesheet in the first place, but I know people who work on a shared computer and aren't confident enough to edit the stylesheets, since they don't know whether they'll accidentally change them for everyone.)
- From a "busy" folder containing many file types, select all.ppt files and move them elsewhere.
- The same operation, but only if they've been modified recently.
- Convert an entire directory of Word documents to HTML.
(While on a summer placement I wrote a Delphi program to clean up Word 97 HTML, remove some of the obvious stupidity, replace the headers/stylesheets with nicer ones, and add links, for web publication (having the content creators work in HTML directly wasn't an option, since this was a no-budget HTMLization of existing Word97 content); however, whenever the Word docs changed, it was necessary to go through the directory re-exporting them manually. Had I not been able to provide the program, the task would have been even more boring.)
- Given a list of objects for which up to two "more info" files (with known names) may or may not be present, create a nice HTML index listing all the objects by name and number, and linking to their "more info" HTML files.
(The same program did this - the user just had to open a spreadsheet containing the list, delete all but the first column and export to CSV. I hate to think how long it would have taken without my program.)
I'm a native UK English speaker, and I'd say "sandpaper" for the paper-with-sand-glued-on you use to smooth wood.
If I remember correctly, emery paper is a type of harder sandpaper for use on metal (it's a while since I've done that sort of thing though, I mostly stick to software:-)
If you're only within reach of scrupulous characters, security isn't a concern. ("Scrupulous" = "having scruples"; "scruples" has a similar meaning to "morals" or "ethics")
Of course, if there are any unscrupulous characters around, then you need to think about security.
There have been legal noises made about whether spam is actually illegal - the consensus seems to be that it should be (for some suitable definition of spam), but it'd be difficult to prosecute anyone for it in most places without new laws.
On the other hand, knowingly obtaining unauthorised access to a computer system (e.g. with a trojan) is unquestionably illegal, so if spammers are taking a risk like that, they're getting pretty desparate. A spammer who does this and gets caught will *not* be in a good situation.
someone who's going to pirate music is going to do it and then find a reason to justify it
Some people who copy music illegally feel guilty that they're doing something wrong, but carry on anyway. (Oh, and don't call it piracy, please, it has nothing to do with robbing ships.)
The point the grandparent post is making is that, for some people, DRM-crippled media will be enough to tip the balance towards illegal copying.
Standard CDs will play on any CD player, and there's a readily available specification for making compatible CD players. The cost of legal CDs is the price of the CD; the cost of illegal copies is the feeling of guilt and the potential penalty if you get caught. Many people feel guilty enough about illegal copying that the cost of legal CDs is less than the "cost" of illegal copies, so they buy legal CDs.
DRM-crippled optical music media happen to play on most consumer CD players, because the makers of those CD players cut corners and don't follow the specification rigorously. The cost of illegal copies is the same as for standard CDs, plus a bit of time investment in breaking the DRM; the cost of legal non-CDs is the price, plus the inconvenience of not being able to play them in some CD players, or on a computer, or rip them for use in an iPod or similar, or use them in a PC-based MP3 jukebox without finding the actual physical CD, and so on. Depending on the relative "cost" the customer places on guilt and on this inconvenience, the inconvenience might well end up as a higher cost, so they go for the illegal copies.
I'm not saying it's right, but if you think in terms of relative costs, you can see why the extra burden of DRM restrictions makes illegal copies look more attractive.
Slashdot Mirror
An attacker using this exploit can run arbitrary code. They can control your mount table, and mount a malicious NFS or SMB share over some directory whose contents get run a lot (for instance, they could replace your crontab with one that downloads and runs an evil executable of their choice, or replace /lib to contain a modified copy of libc that does evil things whenever you start a new executable).
Of course, the attacker is intent on getting shell access, they could always use one of the above techniques to start sshd.
Your config files are scattered all over your system, and I'll bet you don't know where half of them are.
/usr/local/etc, that might be true. On newer distributions that's just not true - they're in /etc.
/etc. In Debian, putting a file elsewhere when it should be in /etc is a bug; I seem to remember it counts as Serious, because it's a policy violation.
/etc but is not a configuration file, it shouldn't be there, although there are a couple of exceptions for historical or technical reasons[1].
/home, and you might also want to hang onto bits of /var (on a dpkg-based system, if you have a backup of /var, you have a complete list of installed packages, which is nice to have around).
/etc/rmt is a trivial shell-script wrapper for a program which was historically required to be in /etc (8 lines, of which 6 are an explanatory comment). /etc/mtab and /etc/ifupdown.state are variable state files which should probably be in /var, but need to be used early in the boot process before /var is guaranteed to be mounted.
On some older Linux systems with silly locations like
According to the Filesystem Hierarchy Standard (which Linux distributions are converging towards), system-wide config files are required to go in
The converse is also true. If a file is in
To get users' personal config files (and documents) you also want a backup of
---
[1] On my Debian system,
The fact that it was there in the first place was a workaround for stupid legal issues - at the time GnuPG development started, the author wasn't sure whether DSA signatures were patented, so he allowed El Gamal keys to be used for signatures as well as encryption. It turned out DSA signatures were OK, and the default for all recent versions is to use DSA signatures with El Gamal for encryption.
The other available key types (RSA+RSA, DSA+El Gamal) are there for interoperability; I think the consensus seems to be that DSA+El Gamal is probably better, but RSA+RSA needs to be there because that's what the original PGP used.
On the other hand, I agree that it sounds from the announcement as though the optimizations that caused the flaw were unwise.
That "Lytha Way" reminds me of some recent guest articles on diabloii.net, in which an expert Diablo II player describes how he completed the game on Hell difficulty with the following strange characters:
- A melee-only Sorceress whose name I forget: her primary spell was Teleport (for targeting purposes), with Enchant (extra damage) in a secondary role
- Gunter, the Barbarian who wanted to be a wizard: a Barbarian with no melee ability whatsoever, using only warcries and the fire spells provided by the items he was wearing
- Maldar the Magnificent, the compassionate, pacifist Necromancer: completed the game without killing a single monster, except those that had to die in order to complete quests (quest bosses and so on). His primary spells were Bone Wall (summon a wall), Bone Prison (trap a monster), and Dim Vision (target monster can't see).
An attacker could override arbitrary directories, if they could control the mount table. As another poster pointed out, if they mounted a network share containing a malicious script over the top of, say, /etc/cron.daily, you'd never know, and it'd execute at midnight.
/lib with a nearly-identical version, except that the standard C library (libc) contained some sort of malicious code which executed once (the first time fork() was called, say), and it'd get loaded the first time you ran any dynamically-linked program. Again, unless you habitually mess with the contents of /lib (not advisable), you'd never know - the only symptom would be a slight slowdown when starting new programs, and it could even be coded to be self-removing so it only triggered once, while quietly opening up remote access in the background.
Alternatively, if they knew your OS version, they could replace
It's quite possible to override a DHCP server, even without intending to; the request is broadcast, and if multiple machines send a response back, the first one received wins.
I've been bitten by this myself: I have cable at home, and someone on the same subnet has (presumably) set up their NAT box backwards, so when I request a DHCP address, I get one of their internal addresses (192.168.100.x) as well as one from the ISP. Because they're on the same subnet and the ISP's DHCP server is elsewhere on the network, they consistently return a response faster, too.
I worked around that by configuring my DHCP client daemon to ignore all responses from the 192.168.100 subnet, but that's not an option if your DHCP client isn't configurable.
It depends whether the NPC in question had been thought of when the engine was written, or whether it was added later. I don't know how often Everquest developers update the client, but if it had no concept of "invincible", it's possible that they would decide a client update would be too much effort, and stick to things the client could already do.
I used to make mods for X-Wing vs TIE Fighter; admittedly, the available tools were all reverse-engineered, so we never really knew for sure what the engine was capable of, but it was pretty limited in areas Totally Games (the developers) hadn't needed.
One of the early XWvTF missions that used add-on models was the Death Star trench run from A New Hope. The Death Star was represented by a square something like a hundred miles wide, with a trench running across it (10 polygons making up 5 rectangles - "ground" to the left, "ground" to the right, and two sides and a floor for the trench). A few other mod makers (including me) used the same mesh as a convenient representation of "the ground" in other ground-based scenarios.
It turned out that the XWvTF engine didn't have a form of invincibility that was useful; the "invincible" flag in mission files actually meant "no collision detection", and flying down the Death Star trench pursued by TIE fighters would be no fun if you flew straight through it whenever you should have crashed, so people usually just gave it a few million points of hull strength instead.
In the sequel, X-Wing Alliance, "invincible" was implemented in a much nicer way: invincible ships could get hit, they could lose shields, they could even be seriously damaged (slightly alarming in one mission where you fly alongside Luke Skywalker), but they never dropped below 1% hull strength.
(If you still play XWvTF or XWA, see my linked homepage for some old custom models and an XvT mission pack)
American English is already used like technical standards on the Internet. People don't drop their native languages (just like app authors don't often drop their native formats), but they do use English in contexts where "cross-platform compatibility" is important (newsgroups/mailing lists/forums - wherever they don't know whether the people involved will understand their first language).
:-)
I quite like having Unicode formats myself, ASCII isn't quite good enough. Never mind transcribing foreign words, ASCII can't cope with correct English typography either
[Posting anon since this is way off topic]
:-)
The hardware's fine, it's the software that's wobbly.
"unstable", a.k.a. "sid", is the section of Debian that new software gets uploaded to - it's sometimes a bit untested, but usually works. It's good for development, and it's also necessary if you have new hardware that older releases don't support properly, like my Powerbook.
Whenever I see a mention of automated keyword matching like this, I wonder what such a system would think of gamers discussing Counterstrike or TFC.
"... yeah, they got the hostages back; we managed to plant the bomb in the missile silo though. One of the SAS guys tried to defuse it, but I shot him with my AK-47, so the terrorists won."
"OK, next game we need to kill the President..."
purl.org provides "persistent URLs", basically a permanent HTTP redirect (for instance, the Dublin Core people use http://purl.org/dc/ which redirects to http://dublincore.org/ - more importantly, they use purl.org for namespace URLs which need to stay valid indefinitely, like http://purl.org/dc/terms/1.0 which redirects to the Dublin Core Terms specification in RDF).
These don't address the fact that documents get altered or deleted, for which you're still dependent on the original author maintaining the old content at the same URL.
Sometimes documents not being modified isn't necessarily what you want, anyway - for instance, sites with navigation/stylistic stuff "wrapping" the content (like my site) might want to redo that without altering the content.
Also, sometimes a URL isn't meant to always refer to one version, but is meant to refer to the latest version (like w3.org specifications, which have a long date-stamped URL for "this version", and a short URL for "latest version of this specification").
Basically, it's up to the content author to follow good practices.
On pseudorandom.co.uk I use a year in the URL for all permanent content, except a couple of "navigation" pages (the games section, the "contact me" page) which pre-date my current URL scheme - there are so many references to those elsewhere in my site, I don't want to have move the pages, fix the links and install redirectors.
For content that existed before I switched to year-based URLs, I moved the content page to a new URL based on the year of first publication, and installed redirectors from the old name (mod_rewrite is very useful for this sort of thing).
The university I'm at has a simple policy to avoid running out of bandwidth: they monitor bandwidth use per IP address (or per physical network socket, I'm not sure which way they run it). If you consistently use too much (where "too much" roughly means "enough to inconvenience everyone else"), they tell you to stop. In theory, if you keep using too much, they disconnect you, but in practice most people get the hint after the first warning or two. Formally, we aren't told what the limit is; informally, I've heard the computing service start taking an interest once you break 1GB/day on a regular basis.
As a matter of policy, they don't sniff network traffic (they'd rather not be responsible for it).
They do block a couple of ports, but only the ones you really don't want to use over the Internet (NetBIOS) and a couple they need to block for policy reasons (SMTP to the outside world is blocked, to make sure that if we spam, it goes through the central mail relay, so they can tell who was responsible; it's a little annoying, since I can use my web host as an authenticated relay from any network except university, but I can live with it).
I think it's even possible to convince them to unblock those ports for your IP, if you can come up with a good enough reason, although I've never tried.
It's a good policy IMO; you can't transfer huge amounts of data all the time, but you can have very impressive bandwidth for a short time (I've downloaded Linux ISOs from another college at about 40MBit/sec!) and pretty much any network protocol is allowed (good for computer science students and like-minded people).
I know I'm anonymous, but can anyone tell me whether I have to/ really really should turn on devfs if I upgrade to 2.6?
I've tried using devfs under 2.4 several times but have never succeeded in getting it to work with my crufty (been around since slink) debian box.
And since I use ALSA and XFS the 2.6 kernel would simplify compiling desktop kernels no end.
I don't know about 2.6, but I use 2.4.x with devfs on two stable boxes ("servers" running on obsolete desktop hardware) and two unstable boxes (a desktop and a Powerbook), and they all work fine. Tab-completing commands is so much nicer when you only have device nodes for hardware you actually have; it's also handy to be able to see (say) whether your CD drive was detected properly, or how many partitions a hard disk has, by looking at the device nodes.
If you're using at least Debian 3.0 stable (woody), install devfsd, install a devfs kernel, reboot, and everything should Just Work.
What specific problems do you have with it?
Debian's packaged X display managers have TCP/IP connections disabled by default; they only accept connections from the local machine, via Unix domain sockets (which have conventional Unix user-based access control, as well as the XAuth authentication system) and via shared memory.
However, the fact that the underlying protocol is network-transparent enables ssh tunnelling to work (the ssh process at each end of the tunnel basically acts as a proxy for the Unix domain socket).
hundreds of programs from different sources ... almost all of which need a Unix C runtime library ("libc").
/sbin and /usr/sbin in your PATH; if you don't use something Debianish, I'm sure other package management systems like RPM have an equivalent incantation)
If you have access to a Debian machine (or something else which uses dpkg), try this:
dpkg --simulate --remove libc6
(you might need
This will tell you what would happen if you removed libc6; on my computer, it complains about broken dependencies for around 750 packages, including Konqueror, KOffice, OpenOffice, Mozilla, XFree86, Apache, Perl and Python to name but a few. That's not including things which depend on libc indirectly (for instance, Perl modules which need Perl).
Anyway, you'll observe that hundreds of programs from different sources depend on having a C library, and won't be much use without one. In the case of Debian (and every other major Linux distribution I'm aware of), the default C library is glibc 2.x, also known as libc6.
(If your distribution statically links some executables, they won't actually need a C library at runtime, but only because they have the necessary bits embedded in them at compile time - it's likely that they'll have been compiled against glibc too, and therefore will contain parts of glibc.)
It's entirely possible to put together a distribution of Linux which uses a different implementation of libc as its C library (as I mentioned, revol is such a system - if I remember correctly, it uses dietlibc), but few distributors do.
It's also possible to put together a distribution of Linux with no libc at all, but it wouldn't be an implementation of Unix, and if you wanted to actually achieve anything with it, you'd have to reimplement a lot of the basics yourself.
Gnome users might be using GNU/Linux, but KDE users sure aren't.
/usr/bin/konqueror | grep libc /lib/libc.so.6 (0x0e89c000) /usr/lib/libkdecore.so.4 | grep libc /lib/libc.so.6 (0x6fa17000) /lib/libc.so.6 /lib/libc.so.6 /usr/share/doc/libc6/copyright
Really?
$ ldd
libc.so.6 =>
$ ldd
libc.so.6 =>
$ dpkg -S
libc6:
$ head -2
This is the Debian prepackaged version of the GNU C Library version
2.3.x
Without glibc, my Debian box certainly wouldn't be much of an OS - practically none of the programs would work. The major components of a Unix system are a kernel and a C library - Linux is only one of those.
Incidentally, if you think you can use XFree86 and KDE on Linux without needing command-line tools, I suggest you have a look at the scripts your system uses to boot, particularly the line "#!/bin/sh" at the top. Just because you don't use them yourself doesn't mean they're not necessary.
(On the other hand, I've seen one Linux distribution which can reasonably claim to not be GNU/Linux - revol, which runs on Psion Revo electronic organisers with 16M of RAM and no disks or removable media. It doesn't use GNU tools and libraries because they're too big; if I remember correctly it uses dietlibc for the C library and busybox for the shell utilities.)
X is a low-level component; it's the implementation of GUI mode. You almost always interact with things that use X, rather than with X itself - for instance, instead of drawing window frames and resizing windows for you, X has the concept of a window manager, which is a separate program to draw window frames and handle resizing/etc.
/.), you don't really need to understand X, any more than you need to understand the finer points of ext2 in order to manipulate files.
I'm sure 9/10 Mac users don't understand Quartz, and I certainly don't understand X or the equivalently low-level bits of the Windows GUI (I said MFC in the subject line, but as I understand it, MFC is more like a toolkit like Gtk or Qt - I don't know whether the Windows GUI even has a name, since it's so tightly attached to the rest of Windows).
Unless you're programming to the X protocol (or complaining about its perceived shortcomings, which seems to be a popular activity in any X-related story on
The only bits of X you might need to understand for "normal use" are the areas where it touches the user experience, like the clipboard, the fact that you can remap keys, possibly the concept of a window manager, and perhaps the fact that there is a program called an X server which provides your GUI.
In a "consumer" Linux distro, ideally you'd interact with X settings via something like the KDE Control Centre, or the GNOME or other desktop equivalent. Obviously, it's still nice to have plain-text config files behind the scenes, so if something breaks seriously, it's possible for an experienced user to fix it - a Windows-like "you have a GUI or you have nothing" approach is equally good for inexperienced users, but if it breaks, experienced users don't have that chance to fix it.
While I agree that distributing "keygens" is unethical, putting my "devil's advocate" hat on for a minute, I don't really see how it's an infringement of copyright:
Suppose I reverse-engineer an app that uses CD-keys (Gamespy 3D, say) and determine how it checks CD-keys.
Further, suppose I write a keygen which produces valid CD-keys on request. Remember, a CD-key is just a meaningless string with some particular property - if I remember correctly, one app a few years ago accepted any multiple of 7 as a key.
OK, now suppose I distribute the keygen, which consists entirely of my code.
If you assert that I infringed copyright at some point during that process: when did I distribute a creative work created by Gamespy?
If you think the situation I described would involve breaking the law: instead, suppose someone else reverse-engineered Gamespy 3D and told me how it checks keys, and I did a "clean-room" implementation of a keygen based on that. Would that be legal? If not, which of us would have broken the law?
Right-click on "Listen to All Tracks: Hi-fi Play" for the artist you're interested in (actually listen to something first so they set the cookies and stuff - no need for a real e-mail address, I used one that bounces), save the .m3u file somewhere, and
../$b.m3u ) && touch $b/done; done
wget -i whatever.m3u
or to preserve artist names as subdirectories (as I did, since they're not always very good at ID3-tagging their content)
for f in *.m3u; do b=`echo $f | sed -e s,\\.m3u,,`; mkdir -p $b && ( cd $b && wget -i
Maybe we'll finally get a reliable copy/paste
p aste.html
Um, as far as I'm aware, we *have* a reliable (and consistent) copy/paste. No, it's not *exactly* the same as in Windows (in case you hadn't noticed, X desktop environments aren't Windows), but if you use common "end user" apps like KDE 3.x, Gnome and Mozilla, you won't go far wrong by assuming everything works like Windows.
There are two "selections", PRIMARY and CLIPBOARD (actually, there's also SECONDARY, but I'm not aware of any program which ever uses it). X just provides these, it's up to application authors (or toolkits used by those authors, like Gtk+ and QT) to do something sensible with them.
Not forcing a particular "policy" is a general principle the whole of X follows, for better versatility - if it didn't, we'd be stuck with either 1970s UI conventions, or rewriting X. Instead, X lets applications decide on their own behaviour - if you want consistent behaviour, you can have it, if you want inconsistent behaviour (or if you want to establish a new convention) you can have that too.
Anyway, the established convention is that CLIPBOARD is like the Windows clipboard; Edit/Copy, Edit/Paste, Ctrl+C and Ctrl+V act on it. This works in the vast majority of X apps.
PRIMARY is the currently selected text, and is a transient sort of thing; as a bonus feature for experienced users, you can copy it into another application by middle-clicking. However, you can use KDE 3.x or Gnome without needing to know that PRIMARY exists.
Informal documentation:
http://www.jwz.org/doc/x-cut-and-
(that page links to the formal specification).
The historical problem the parent post might be thinking of is that KDE 1 and 2 used to do it wrong (they used PRIMARY for the copy/paste menu items and Ctrl+C/Ctrl+V, ignoring CLIPBOARD; just selecting text didn't do anything useful). This was horribly inconsistent, but has been fixed now (as far as I know, only Debian still has a version with this problem in its current release, and Debian 'stable' is notoriously out-of-date).
KDE 3.x has been changed to work the same way as other apps do: selecting text copies it to PRIMARY, middle-clicking pastes from PRIMARY, Ctrl+C or Edit/Copy copy to CLIPBOARD, Ctrl+V or Edit/Paste pastes from CLIPBOARD.
The convention even extends to terminal emulators, by the way. xterms only use PRIMARY (they don't have a menu with Copy/Paste options, and Ctrl+C/Ctrl+V need to go to the terminal as-is), but if you're using xterm you're probably an experienced enough X user to know about middle-clicking anyway.
Meanwhile, KDE 3's Konsole has Copy and Paste menu items which use CLIPBOARD just like any other KDE app (or just like "DOS boxes" in Windows, for that matter); I assume gnome-terminal does the same, although I haven't used Gnome for a while.
That's precisely the point, people *don't* want to do boring repetitive tasks, especially if they know enough about computers to know that the computer could do it for them.
.ppt files and move them elsewhere.
OK, how about:
- In a word processor document, do something based on formatting; for instance, put all bold, underlined text into 24pt and remove the underlines.
(Yes, I know someone who understood the word processor would have used a stylesheet in the first place, but I know people who work on a shared computer and aren't confident enough to edit the stylesheets, since they don't know whether they'll accidentally change them for everyone.)
- From a "busy" folder containing many file types, select all
- The same operation, but only if they've been modified recently.
- Convert an entire directory of Word documents to HTML.
(While on a summer placement I wrote a Delphi program to clean up Word 97 HTML, remove some of the obvious stupidity, replace the headers/stylesheets with nicer ones, and add links, for web publication (having the content creators work in HTML directly wasn't an option, since this was a no-budget HTMLization of existing Word97 content); however, whenever the Word docs changed, it was necessary to go through the directory re-exporting them manually. Had I not been able to provide the program, the task would have been even more boring.)
- Given a list of objects for which up to two "more info" files (with known names) may or may not be present, create a nice HTML index listing all the objects by name and number, and linking to their "more info" HTML files.
(The same program did this - the user just had to open a spreadsheet containing the list, delete all but the first column and export to CSV. I hate to think how long it would have taken without my program.)
I'm a native UK English speaker, and I'd say "sandpaper" for the paper-with-sand-glued-on you use to smooth wood.
:-)
If I remember correctly, emery paper is a type of harder sandpaper for use on metal (it's a while since I've done that sort of thing though, I mostly stick to software
If you're only within reach of scrupulous characters, security isn't a concern. ("Scrupulous" = "having scruples"; "scruples" has a similar meaning to "morals" or "ethics")
Of course, if there are any unscrupulous characters around, then you need to think about security.
There have been legal noises made about whether spam is actually illegal - the consensus seems to be that it should be (for some suitable definition of spam), but it'd be difficult to prosecute anyone for it in most places without new laws.
On the other hand, knowingly obtaining unauthorised access to a computer system (e.g. with a trojan) is unquestionably illegal, so if spammers are taking a risk like that, they're getting pretty desparate. A spammer who does this and gets caught will *not* be in a good situation.
someone who's going to pirate music is going to do it and then find a reason to justify it
Some people who copy music illegally feel guilty that they're doing something wrong, but carry on anyway. (Oh, and don't call it piracy, please, it has nothing to do with robbing ships.)
The point the grandparent post is making is that, for some people, DRM-crippled media will be enough to tip the balance towards illegal copying.
Standard CDs will play on any CD player, and there's a readily available specification for making compatible CD players. The cost of legal CDs is the price of the CD; the cost of illegal copies is the feeling of guilt and the potential penalty if you get caught. Many people feel guilty enough about illegal copying that the cost of legal CDs is less than the "cost" of illegal copies, so they buy legal CDs.
DRM-crippled optical music media happen to play on most consumer CD players, because the makers of those CD players cut corners and don't follow the specification rigorously. The cost of illegal copies is the same as for standard CDs, plus a bit of time investment in breaking the DRM; the cost of legal non-CDs is the price, plus the inconvenience of not being able to play them in some CD players, or on a computer, or rip them for use in an iPod or similar, or use them in a PC-based MP3 jukebox without finding the actual physical CD, and so on. Depending on the relative "cost" the customer places on guilt and on this inconvenience, the inconvenience might well end up as a higher cost, so they go for the illegal copies.
I'm not saying it's right, but if you think in terms of relative costs, you can see why the extra burden of DRM restrictions makes illegal copies look more attractive.