Another important one is screen -x to attach to a screen from multiple machines at once. Very useful if you are in the office and find you forgot to close the connection at home. I used to use -R but now use -x almost exclusively.
It's not possible to "clear the DRAM" (as others have suggested), because the attacker will boot his own CD and not give control to your OS after the reset. Thus you won't be able to clear anything.
Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc).
Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".
It might seem difficult to find out which memory is of that category. But it isn't, either! Just prepare two boot CDs. One that fills all memory with a known pattern (eg 0x55). Boot it. Then reset and insert the second CD, which identifies all memory areas that have lost the known pattern. These areas have either suffered DRAM fade, or they have been overwritten during the BIOS boot process. Use heuristics to find out which of the two was the cause. Done!
> The GPL devs are not "giving it back" to the BSD devs, > because the BSD devs can't use it in their projects
A GPL dev CAN give his changes back to the BSD community, effectively "dual licensing" his changes. His main "product" may be GPL'ed, but a couple of bugfixes can be his "giving back" under BSD license, too.
> Of course it might "brick" a hacked iPod without them meaning to. > Even if they are just making a minor update to a simple app, they > might be using a newer version of an existing library.
It's one thing to not know about hacked devices and issue a regular software update that happens to brick a hacked device.
But it's another thing to be well aware about the hacked devices. The fact that they release an international FUD press statement shows that they DO care about them, and not exactly in the positive sense. They don't say "we'll break em", they do say something that - seen in this context - is about equivalent.
> First thing I noticed after doing the chip replacement was that > the quality of the prints immediately improved. I printed for > several weeks, noticed the quality go down again, replaced the > chip (no toner added in there yet...) and viola worked beautiful.
Man you should know that taking out the toner cartridge and putting it back in is solving the problem in itself. The small remainder of toner in an "empty" cartridge is actually what doesn't come out easily. It's just like those cream cans that are just impossible to drain completely.
When the toner runs low, take out the cartridge. Hold it in the same orientation is if it were mounted in the printer, and shake it gently to the left and right. Repeat a couple of times. Put it back in and you've got another week of perfect prints. You can usually extent for another week and another, but eventually it will be "empty" in a sense that even shaking won't fix it.
You might have a chip-locked cartridge, I don't know about that. But as long as the printer driver is happy, I wouldn't expect purposefully software-faded printouts. That would be major news. So my conclusion is that you re-chipped your cartridge without a necessity, and in the process of doing it you shook the cartridge enough to "fix" it for a week or two. All the chip really did was to mute the drivers "toner low" warnings. If I'm correct, the chip is a helper and not a lock, ie it warns but doesn't lock you out.
Next time your prints fade, try to shake the toner and check yourself.
> if a sound system is used, it's still better to route the signal through > the TV so you can control the volume with the same remote as the TV.
There's an additional advantage of routing audio through the TV:
TVs have become complex devices. With flat panels for example, incoming signals must be de-interlaced before being shown. Often additional image processing is done, trying to enhance the visuals.
All this takes processing time, and results in latency in the visual path.
For audio to remain lip-sync, it must be delayed by an equal amount of time. But who knows how much latency your TV has? We have no standard for your TV to communicate its latency to your amp. Actually we don't have (consumer) amps with configurable audio delay either.
So, the best kludge for the moment is to route the audio signal through the TV. The TV can then delay the audio signal by whatever it sees fit.
I've made some such photos in the past. Although they are not Intel chips, they are certainly larger than the pictures you link to. They are in the range of 50-500 megapixel and assembled from lots of individual photos. If you're interested, email me your desktop resolution and I'll convert one for you. Here is a (small) example picture.
> If you leave your car parked on a hill in neutral without > the emergency brake on, and it rolls down the hill and > damages another car, are you liable?
What if you leave it parked in a flat street, without the emergency brake on. Someone else bumps into your car, pushing it into another parked car. Are you liable?
> If you leave a computer unprotected on the internet, and > never take steps to protect it, are you acting negligently > and thus liable for the damage it causes?
What if you copy your own CDs for the car stereo, under fair use rights. You leave the copies in your car and leave the car unlocked - ie do not take the steps to protect the copied CDs. Someone passes by, opens your car and takes away the CDs. This transfer of the CDs is not covered by fair use rights. Are you thus liable for the damage (against the copyright holder)?
> I would like to know if this is a learned behavior from > an outside source or if this is simply something they > have discovered on their own.
This is an interesting question.
You think of animal tool use as "imitation behaviour" and human tool use as "discovered on their own". But is this really so?
I for one didn't discover tools on my own before I was shown existing tools and how to use them (by imitation).
Eventually I learned how to discover new tools. My work requires this, from time to time. But even though my tools are unique ("discovered on my own"), the process that leads to them is not. It may just be imitation. I mean, the process (tool-creation) is always similar, even when the outcome (tool) is unique.
I'm not aware of studies that examine if humans are inherently able to discover new tools. But I wouldn't be surprised to learn that they are not. Or to learn that monkeys can be teached to discover new tools on their own.
The parent said that one possible method to detect leech clients, is to send him a rare block (one that nobody else in the swarm has).
If the client is not a leech, he will soon announce posession of the block. Others will request it, download it and eventually also announce posession.
If he's a leech, he might announce posession but he will certainly not upload it. You can detect this indirectly, by waiting if the block eventually shows up at other clients of the swarm. If it doesn't, you've identified the leech and can drop him off your queue.
If the leech were to team up with another leech, this method could be circumvented. He could receive all your rare packets, and they would "magically" appear as available at the 2nd leech. The 2nd leech would just pretend to have them, although he doesn't and thus won't be able to upload these blocks to anyone.
You would fall for it. You would think your bandwidth is used for good, even when the leech actually doesn't upload much to you. But he uploads to the swarm, doesn't he? Poor him, he's a new peer and just doesn't have many blocks yet.
Obviously, the 2nd leech won't team up without incentives. I mean, unless the 2nd leech wasn't a just a 2nd machine under control of one leecher.
For voluntary cooperation, both leechers must do service vice-versa. This doesn't cost much bandwidth, but it voids the download consistency. The leech must pretend posession of those rare blocks, that the opposite leech has downloaded from someone. So, he can't download them himself.
A solution for this problem is to only keep the quantity of those blocks down. The leech must keep track of which blocks can be used by the good peers to identify leeches (ie which blocks are rare or unique). Only those are covered, while all other blocks are downloaded "normally".
There will be a point, where the leech must leave the swarm. The swarm thinks he's at 100%, because that's what the leech pretends (in help of another leech client). But in fact he isn't. He must join another swarm, or re-join the same swarm with a different id (dynamic IP?) to complete the download.
> Clients should send their rarest packets first, to keep the swarm happy. > So if the packet doesn't show up, you've got a leech and your drop him in the Queue.
This technique can easily be circumvented. A leech client can co-operate with another leech client. As soon as he receives your rare packet, he can tell the other client to pretend to have it, too (without actually sending it).
It makes sense when he does the same for the other client, so both can leech from the swarm.
The only difficulty is how the leech clients find each other, while staying undetected by the rest. This, while solvable too, is not a problem initially, because the other clients must catch up first.
> As for erasing solid state media, I'd feel perfectly safe > simply overwriting it with zeroes, one time over.
For most purposes, this might be perfectly enough.
Certainly an "all-zero" overwrite is far better than a "all-one" overwrite (flash erase operation). But then again it also depends on the controller, because what ends up in the floating gates is what really counts.
See link (below) for some techniques to recover erased or overwritten flash memory. The basic idea is to measure the trapped charge in each cell with higher resolution than just 1/0. In other words: as analog voltage. Since you can't just connect a voltmeter to each gate, you have to trick the read-out circuitry to forward (reveal) this information to you. The document is about how this can be done with some popular chips.
At first these techniques seem to require very invasive access to the memory. But once working, many attacks can be vastly simplified (see TV card scene).
> No, just block port 25 to all servers other than the ISPs for > dynamic IP addresses. If they do not want to use their ISPs > mail server, they can purchase a static IP, or set up a proxy > with a different port.
I did purchase a static IP and pay for it on the monthly bill. Yet half of my outgoing email is still returned as "rejected for possible spam".
Maybe your provider keeps "static" IPS separate from "dynamic IPs". Mine appearently doesn't (just assigns me one of his IPs as static). Or the RBLs are too ignorant to learn about static and dynamic IP ranges of smaller countries like the one I live in (Spain, Europe).
So, go ahead and do whatever you want on your own server. But please DO NOT encourage other people to block so-called "dynamic" IPs, because this blocks most non-US static IPs as well.
I mean, that's like blocking asian senders. Quite efficient, unless you are asian abroad and want read your friends mail.
> You can write very beautiful code and yet have an interface as ugly as sin... > likewise, you can have horrible spaghetti code lying behind a very pretty GUI.
More often than not, the ability to create a pretty & straight-forward GUI comes with the ability to create pretty & straight-forward code.
For a good GUI one has to abstract the task and then re-concretise it. For good code both is essential too, but for Spaghetti code abstracting is sufficient. That's why Spaghetti coders seldomly put good GUIs in front of their code.
Software made by teams are a completely different story though.
What seems to be completely missed is the fact that only "phreaking" enabled 15 year old kids to trade 880KB Amiga game images over 2400bps modem connections, back when international calls cost 2 dollars per minute.
> Perhaps a better analogy can be found in the airline industry (also a service). > So there is at least one industry that has been overselling a service for a > very long time.
Well, the difference is that the airline apologizes and bumps you to 1st class or refunds the ticket, instead of claiming "excessive use" of your behalf.
Emule lets you attach a "File comment" (some 60 chars) and "Quality Rating" (1-5 stars) to your files.
To attach a comment, all you need to have is the complete file.
To view a comment, you need to have it in your download list. You see each comment together with the (optional) rating, and the authors nick.
If a file has comments attached, a tiny green or red exclamation mark is displayed next to its name in the transfer window. A green icon stands for comments with positive or absent rating. A red icon indicates the presence of negative ratings.
Emule users tend to mark fakes with negative ratings, and you can spot them by the red icon shortly after the download has started.
This feature is implemented in Emule since at least 2 years (probably more).
> For you to do actual damage, you would have to know enough my habits to
> guess subjects and words which appeared very commonly in legitimate mail
Well, a spammer could grab your email address from Slashdot, and also your postings. He could then use them to generate an email that contains lots of "good" words. Using HTML or CSS formatting, he could overlay this body with the spam message. I'm sure it would get through to you. But then again, it's far more complex than just grabbing email addresses from usenet.
There exists a solution for diskless Windows XP stations. It is called "Venturcom BXP" and consists of server software and client drivers.
The server installs on WinXP or Win2K3. You also need DHCP, BOOTP/PXE and TFTP servers. BXP includes them if you don't have them already in your LAN.
The client drivers link to the NIC drivers and also include a tiny status tool and the disk-copy program.
After installation, you create a virtual disk on the server and assign it to a client. Once the client boots, this disk appears as additional driveletter. Using the disk-copy program, you copy your system partition over to the virtual disk. Then you change the server configuration to instruct the client to boot from the virtual disk.
At this point, the physical harddrive will appear as additional driveletter, while the virtual disk becomes C:\. You can remove the physical harddrive now if you want, or you can assign the windows pagefile to it for faster operation.
With 100mbit ethernet you can achieve about 8-9 MB/s virtual disk performance. However, ethernet has considerable latency, and a BXP'ed machine doesn't feel as snappy as a real one.
A nice extra feature is the possibility to "write-lock" the virtual disk. That is, all changes made to it can be stored in a separate file, which is deleted when the client is shutdown. Using this feature, the client always boots the same state. This is perfect for classrooms or webcafes where users may modify the configuration, delete system files, or infect the machine with trojans or viruses. All changes are magically undone when rebooting.
It is also possible to assign such a "locked" image to several clients at once (the virtual disk is accessed read-only, and each client gets an individual temporary write-cache for its session). Using this feature you can install and customize one box, and then boot the image on a dozen boxes. For this to work, it is necessary that all clients have identical hardware (down to the PCI card order!).
Other advantages are that the virtual disk is just a file. This provides for easier backup or versioning / branching. Using tools to snapshop the server partition, you can even backup the client while it's running.
You can also use BXP to test-install software. Games for example can't be tested in VMware (lack of virtual 3D hardware). With BXP you can, because only the harddrive is virtual - the box remains physical!
> > The technical specifications of the flash memory in my USB drive says that it is > > guaranteed to work for, at most, 100000 (i.e., one followed by 5 zeros) writes. > > I thought I'd seen specs an order of magnitude larger than that in many cases, but > the problem still may not be as bad as you think in many cases even if it is as bad > as 100000 writes. The reason? Flash devices have systems built in to their > controllers specifically to deal with these problems. The mechanisms may vary, but > the ones I know about are wear leveling and excess capacity (beyond the capacity > that the device reports to the operating system) that can be pressed into service > when a block fails.
Wear levelling can only work, if the changes are done to tiny portions of the whole memory capacity. It can't work, when the whole device is changed.
Why? It's simple. Lets say a cell can be written 100000 times. A device with 32*8 million of those cells (32 MB), can accept a total of 100000 * 32*8 million single bit writes. Or half that amount of 2-bit writes. Or 100000 writes of a 32*8 million bit block.
The idea of the hybrid harddisk is that a RAM cache holds all the changes. Once RAM is full, changes are flushed to the magnetic media. The write-acceleration stems from the fact, that several individual writes (*) can be combined to single operations, and write order can be optimized according to the relative positions of head / platter.
For this to work, RAM utilization has to be high. High RAM utilization also means that lots of RAM must be dumped to FLASH on power failure. But in the ideal situation (100% RAM utilization), FLASH write size is 100%, too. That is, no place for wear levelling. No worn blocks can be exempt from such a write. All blocks have to join, sorry.
On the other hand, 100000 writes mean that you can power-cycle your computer once per minute, 24h per day, during almost 3 months. Or once every hour during 10 years. I bet the power supply unit bails out first..
Marc
(*) Operating systems already try to combine writes of course, but they can only do so to a certain extent. For example, journaled filesystems must write the journal first, then the data, and then journal, and so forth. It's not possible to combine several (related) journal updates within the scope of the operating system, but a hybrid harddrive can easily do so.
> In my mind Program Files is progra~1 and Microsoft is micros~1.
Things get really nasty on international installs.
German Windows for example keeps applications in "C:\Programme\" which also translates to "C:\Progra~1".
Now, some software uses hard-coded paths and on German windows you often also find a "C:\Program files\" folder (usually empty or with just one program in it). This folder is "C:\Progra~2".
With this (not so uncommon) setup, imagine you want to make a backup. You go folder by folder, in alphabetical order. You'll back up "C:\Program files" first and "C:\Programme" second, because blank goes before the letter "m" in most alphabetical comparisons.
Later, you're going to restore to a blank harddrive. You'll restore "C:\Program files" first, and this will allocate "C:\Progra~1". Then you'll restore "C:\Programme" and this will allocate "C:\Progra~2".
Damn, it's exactly the wrong way. How could this happen?
Well, it happened to me with an IOMEGA backup product. Half of the software didn't work anymore, because it had the wrong path in their.INI files and registry keys.
Two lessons learned:
1) Don't trust IOMEGA products for backup.
2) Having transparent (=automatic) multiple names for files is evil. The long/short name stuff should have been implemented in a different way, that makes it less automatic and thus more controllable/predictable to the developpers.
Slashdot Mirror
Another important one is screen -x to attach to a screen from multiple machines at once. Very useful if you are in the office and find you forgot to close the connection at home. I used to use -R but now use -x almost exclusively.
This attack is very powerful.
It's not possible to "clear the DRAM" (as others have suggested), because the attacker will boot his own CD and not give control to your OS after the reset. Thus you won't be able to clear anything.
Anything? Not so quick, my dear! For the CD to boot, first there is the BIOS. And BIOS needs memory as well (for the menus, the screen, the ElToro floppy image etc).
Now the countermeasure is obvious: Keep the sensitive key material in memory areas that is erased during the early boot procedure. Then the attack complexity is raised from "no hardware required" to "specicialists hardware necessary, no guarantees given".
It might seem difficult to find out which memory is of that category. But it isn't, either! Just prepare two boot CDs. One that fills all memory with a known pattern (eg 0x55). Boot it. Then reset and insert the second CD, which identifies all memory areas that have lost the known pattern. These areas have either suffered DRAM fade, or they have been overwritten during the BIOS boot process. Use heuristics to find out which of the two was the cause. Done!
As simple as that.
Regards,
Marc
> The GPL devs are not "giving it back" to the BSD devs,
> because the BSD devs can't use it in their projects
A GPL dev CAN give his changes back to the BSD community, effectively "dual licensing" his changes. His main "product" may be GPL'ed, but a couple of bugfixes can be his "giving back" under BSD license, too.
> Of course it might "brick" a hacked iPod without them meaning to.
> Even if they are just making a minor update to a simple app, they
> might be using a newer version of an existing library.
It's one thing to not know about hacked devices and issue a regular software update that happens to brick a hacked device.
But it's another thing to be well aware about the hacked devices. The fact that they release an international FUD press statement shows that they DO care about them, and not exactly in the positive sense. They don't say "we'll break em", they do say something that - seen in this context - is about equivalent.
My 2 cents,
Marc
> The SATA drives break the compatibility, although you will probably
> be able to get SATA to IDE adapters for some time to come.
Probably this Seagate news goes hand-in-hand with another news that didn't make it to Slashdot yet:
CompactFlash is going to have SATA compatibility built-in! (german news item).
> First thing I noticed after doing the chip replacement was that
> the quality of the prints immediately improved. I printed for
> several weeks, noticed the quality go down again, replaced the
> chip (no toner added in there yet...) and viola worked beautiful.
Man you should know that taking out the toner cartridge and putting it back in is solving the problem in itself. The small remainder of toner in an "empty" cartridge is actually what doesn't come out easily. It's just like those cream cans that are just impossible to drain completely.
When the toner runs low, take out the cartridge. Hold it in the same orientation is if it were mounted in the printer, and shake it gently to the left and right. Repeat a couple of times. Put it back in and you've got another week of perfect prints. You can usually extent for another week and another, but eventually it will be "empty" in a sense that even shaking won't fix it.
You might have a chip-locked cartridge, I don't know about that. But as long as the printer driver is happy, I wouldn't expect purposefully software-faded printouts. That would be major news. So my conclusion is that you re-chipped your cartridge without a necessity, and in the process of doing it you shook the cartridge enough to "fix" it for a week or two. All the chip really did was to mute the drivers "toner low" warnings. If I'm correct, the chip is a helper and not a lock, ie it warns but doesn't lock you out.
Next time your prints fade, try to shake the toner and check yourself.
Regards,
Marc
> if a sound system is used, it's still better to route the signal through
> the TV so you can control the volume with the same remote as the TV.
There's an additional advantage of routing audio through the TV:
TVs have become complex devices. With flat panels for example, incoming signals must be de-interlaced before being shown. Often additional image processing is done, trying to enhance the visuals.
All this takes processing time, and results in latency in the visual path.
For audio to remain lip-sync, it must be delayed by an equal amount of time. But who knows how much latency your TV has? We have no standard for your TV to communicate its latency to your amp. Actually we don't have (consumer) amps with configurable audio delay either.
So, the best kludge for the moment is to route the audio signal through the TV. The TV can then delay the audio signal by whatever it sees fit.
Regards,
Marc
I've made some such photos in the past. Although they are not Intel chips, they are certainly larger than the pictures you link to. They are in the range of 50-500 megapixel and assembled from lots of individual photos. If you're interested, email me your desktop resolution and I'll convert one for you. Here is a (small) example picture.
> On my windows machines it would probably be of more use
> since I can't encrypt the system drive
You can, using DCPP
> If you leave your car parked on a hill in neutral without
> the emergency brake on, and it rolls down the hill and
> damages another car, are you liable?
What if you leave it parked in a flat street, without the emergency brake on. Someone else bumps into your car, pushing it into another parked car. Are you liable?
> If you leave a computer unprotected on the internet, and
> never take steps to protect it, are you acting negligently
> and thus liable for the damage it causes?
What if you copy your own CDs for the car stereo, under fair use rights. You leave the copies in your car and leave the car unlocked - ie do not take the steps to protect the copied CDs. Someone passes by, opens your car and takes away the CDs. This transfer of the CDs is not covered by fair use rights. Are you thus liable for the damage (against the copyright holder)?
Think about it a moment.
Regards,
Marc
> I would like to know if this is a learned behavior from
> an outside source or if this is simply something they
> have discovered on their own.
This is an interesting question.
You think of animal tool use as "imitation behaviour" and human tool use as "discovered on their own". But is this really so?
I for one didn't discover tools on my own before I was shown existing tools and how to use them (by imitation).
Eventually I learned how to discover new tools. My work requires this, from time to time. But even though my tools are unique ("discovered on my own"), the process that leads to them is not. It may just be imitation. I mean, the process (tool-creation) is always similar, even when the outcome (tool) is unique.
I'm not aware of studies that examine if humans are inherently able to discover new tools. But I wouldn't be surprised to learn that they are not. Or to learn that monkeys can be teached to discover new tools on their own.
Marc
Let me see if I make sense.
The parent said that one possible method to detect leech clients, is to send him a rare block (one that nobody else in the swarm has).
If the client is not a leech, he will soon announce posession of the block. Others will request it, download it and eventually also announce posession.
If he's a leech, he might announce posession but he will certainly not upload it. You can detect this indirectly, by waiting if the block eventually shows up at other clients of the swarm. If it doesn't, you've identified the leech and can drop him off your queue.
If the leech were to team up with another leech, this method could be circumvented. He could receive all your rare packets, and they would "magically" appear as available at the 2nd leech. The 2nd leech would just pretend to have them, although he doesn't and thus won't be able to upload these blocks to anyone.
You would fall for it. You would think your bandwidth is used for good, even when the leech actually doesn't upload much to you. But he uploads to the swarm, doesn't he? Poor him, he's a new peer and just doesn't have many blocks yet.
Obviously, the 2nd leech won't team up without incentives. I mean, unless the 2nd leech wasn't a just a 2nd machine under control of one leecher.
For voluntary cooperation, both leechers must do service vice-versa. This doesn't cost much bandwidth, but it voids the download consistency. The leech must pretend posession of those rare blocks, that the opposite leech has downloaded from someone. So, he can't download them himself.
A solution for this problem is to only keep the quantity of those blocks down. The leech must keep track of which blocks can be used by the good peers to identify leeches (ie which blocks are rare or unique). Only those are covered, while all other blocks are downloaded "normally".
There will be a point, where the leech must leave the swarm. The swarm thinks he's at 100%, because that's what the leech pretends (in help of another leech client). But in fact he isn't. He must join another swarm, or re-join the same swarm with a different id (dynamic IP?) to complete the download.
Is it clearer now?
Marc
> Clients should send their rarest packets first, to keep the swarm happy.
> So if the packet doesn't show up, you've got a leech and your drop him in the Queue.
This technique can easily be circumvented. A leech client can co-operate with another leech client. As soon as he receives your rare packet, he can tell the other client to pretend to have it, too (without actually sending it).
It makes sense when he does the same for the other client, so both can leech from the swarm.
The only difficulty is how the leech clients find each other, while staying undetected by the rest. This, while solvable too, is not a problem initially, because the other clients must catch up first.
Regards,
Marc
> As for erasing solid state media, I'd feel perfectly safe
d f
> simply overwriting it with zeroes, one time over.
For most purposes, this might be perfectly enough.
Certainly an "all-zero" overwrite is far better than a "all-one" overwrite (flash erase operation). But then again it also depends on the controller, because what ends up in the floating gates is what really counts.
See link (below) for some techniques to recover erased or overwritten flash memory. The basic idea is to measure the trapped charge in each cell with higher resolution than just 1/0. In other words: as analog voltage. Since you can't just connect a voltmeter to each gate, you have to trick the read-out circuitry to forward (reveal) this information to you. The document is about how this can be done with some popular chips.
At first these techniques seem to require very invasive access to the memory. But once working, many attacks can be vastly simplified (see TV card scene).
http://www.cl.cam.ac.uk/~sps32/DataRem_CHES2005.p
Regards,
Marc
> No, just block port 25 to all servers other than the ISPs for
> dynamic IP addresses. If they do not want to use their ISPs
> mail server, they can purchase a static IP, or set up a proxy
> with a different port.
I did purchase a static IP and pay for it on the monthly bill. Yet half of my outgoing email is still returned as "rejected for possible spam".
Maybe your provider keeps "static" IPS separate from "dynamic IPs". Mine appearently doesn't (just assigns me one of his IPs as static). Or the RBLs are too ignorant to learn about static and dynamic IP ranges of smaller countries like the one I live in (Spain, Europe).
So, go ahead and do whatever you want on your own server. But please DO NOT encourage other people to block so-called "dynamic" IPs, because this blocks most non-US static IPs as well.
I mean, that's like blocking asian senders. Quite efficient, unless you are asian abroad and want read your friends mail.
Marc
> You can write very beautiful code and yet have an interface as ugly as sin...
> likewise, you can have horrible spaghetti code lying behind a very pretty GUI.
More often than not, the ability to create a pretty & straight-forward GUI comes with the ability to create pretty & straight-forward code.
For a good GUI one has to abstract the task and then re-concretise it. For good code both is essential too, but for Spaghetti code abstracting is sufficient. That's why Spaghetti coders seldomly put good GUIs in front of their code.
Software made by teams are a completely different story though.
Marc
What seems to be completely missed is the fact that only "phreaking" enabled 15 year old kids to trade 880KB Amiga game images over 2400bps modem connections, back when international calls cost 2 dollars per minute.
Go download that songs! RIAA grabbed $30M. It's all paid for.
> Ignorance is no defense.
There is a difference between
a) I didn't know I was pirating,
and
b) I didn't know pirating was illegal.
> Perhaps a better analogy can be found in the airline industry (also a service).
> So there is at least one industry that has been overselling a service for a
> very long time.
Well, the difference is that the airline apologizes and bumps you to 1st class or refunds the ticket, instead of claiming "excessive use" of your behalf.
Emule lets you attach a "File comment" (some 60 chars) and "Quality Rating" (1-5 stars) to your files.
To attach a comment, all you need to have is the complete file.
To view a comment, you need to have it in your download list. You see each comment together with the (optional) rating, and the authors nick.
If a file has comments attached, a tiny green or red exclamation mark is displayed next to its name in the transfer window. A green icon stands for comments with positive or absent rating. A red icon indicates the presence of negative ratings.
Emule users tend to mark fakes with negative ratings, and you can spot them by the red icon shortly after the download has started.
This feature is implemented in Emule since at least 2 years (probably more).
Regards,
Marc
> For you to do actual damage, you would have to know enough my habits to
> guess subjects and words which appeared very commonly in legitimate mail
Well, a spammer could grab your email address from Slashdot, and also your postings. He could then use them to generate an email that contains lots of "good" words. Using HTML or CSS formatting, he could overlay this body with the spam message. I'm sure it would get through to you. But then again, it's far more complex than just grabbing email addresses from usenet.
> If you really want a diskless system now
There exists a solution for diskless Windows XP stations. It is called "Venturcom BXP" and consists of server software and client drivers.
The server installs on WinXP or Win2K3. You also need DHCP, BOOTP/PXE and TFTP servers. BXP includes them if you don't have them already in your LAN.
The client drivers link to the NIC drivers and also include a tiny status tool and the disk-copy program.
After installation, you create a virtual disk on the server and assign it to a client. Once the client boots, this disk appears as additional driveletter. Using the disk-copy program, you copy your system partition over to the virtual disk. Then you change the server configuration to instruct the client to boot from the virtual disk.
At this point, the physical harddrive will appear as additional driveletter, while the virtual disk becomes C:\. You can remove the physical harddrive now if you want, or you can assign the windows pagefile to it for faster operation.
With 100mbit ethernet you can achieve about 8-9 MB/s virtual disk performance. However, ethernet has considerable latency, and a BXP'ed machine doesn't feel as snappy as a real one.
A nice extra feature is the possibility to "write-lock" the virtual disk. That is, all changes made to it can be stored in a separate file, which is deleted when the client is shutdown. Using this feature, the client always boots the same state. This is perfect for classrooms or webcafes where users may modify the configuration, delete system files, or infect the machine with trojans or viruses. All changes are magically undone when rebooting.
It is also possible to assign such a "locked" image to several clients at once (the virtual disk is accessed read-only, and each client gets an individual temporary write-cache for its session). Using this feature you can install and customize one box, and then boot the image on a dozen boxes. For this to work, it is necessary that all clients have identical hardware (down to the PCI card order!).
Other advantages are that the virtual disk is just a file. This provides for easier backup or versioning / branching. Using tools to snapshop the server partition, you can even backup the client while it's running.
You can also use BXP to test-install software. Games for example can't be tested in VMware (lack of virtual 3D hardware). With BXP you can, because only the harddrive is virtual - the box remains physical!
Marc
> > The technical specifications of the flash memory in my USB drive says that it is
> > guaranteed to work for, at most, 100000 (i.e., one followed by 5 zeros) writes.
>
> I thought I'd seen specs an order of magnitude larger than that in many cases, but
> the problem still may not be as bad as you think in many cases even if it is as bad
> as 100000 writes. The reason? Flash devices have systems built in to their
> controllers specifically to deal with these problems. The mechanisms may vary, but
> the ones I know about are wear leveling and excess capacity (beyond the capacity
> that the device reports to the operating system) that can be pressed into service
> when a block fails.
Wear levelling can only work, if the changes are done to tiny portions of the whole memory capacity. It can't work, when the whole device is changed.
Why? It's simple. Lets say a cell can be written 100000 times. A device with 32*8 million of those cells (32 MB), can accept a total of 100000 * 32*8 million single bit writes. Or half that amount of 2-bit writes. Or 100000 writes of a 32*8 million bit block.
The idea of the hybrid harddisk is that a RAM cache holds all the changes. Once RAM is full, changes are flushed to the magnetic media. The write-acceleration stems from the fact, that several individual writes (*) can be combined to single operations, and write order can be optimized according to the relative positions of head / platter.
For this to work, RAM utilization has to be high. High RAM utilization also means that lots of RAM must be dumped to FLASH on power failure. But in the ideal situation (100% RAM utilization), FLASH write size is 100%, too. That is, no place for wear levelling. No worn blocks can be exempt from such a write. All blocks have to join, sorry.
On the other hand, 100000 writes mean that you can power-cycle your computer once per minute, 24h per day, during almost 3 months. Or once every hour during 10 years. I bet the power supply unit bails out first..
Marc
(*) Operating systems already try to combine writes of course, but they can only do so to a certain extent. For example, journaled filesystems must write the journal first, then the data, and then journal, and so forth. It's not possible to combine several (related) journal updates within the scope of the operating system, but a hybrid harddrive can easily do so.
> In my mind Program Files is progra~1 and Microsoft is micros~1.
.INI files and registry keys.
Things get really nasty on international installs.
German Windows for example keeps applications in "C:\Programme\" which also translates to "C:\Progra~1".
Now, some software uses hard-coded paths and on German windows you often also find a "C:\Program files\" folder (usually empty or with just one program in it). This folder is "C:\Progra~2".
With this (not so uncommon) setup, imagine you want to make a backup. You go folder by folder, in alphabetical order. You'll back up "C:\Program files" first and "C:\Programme" second, because blank goes before the letter "m" in most alphabetical comparisons.
Later, you're going to restore to a blank harddrive. You'll restore "C:\Program files" first, and this will allocate "C:\Progra~1". Then you'll restore "C:\Programme" and this will allocate "C:\Progra~2".
Damn, it's exactly the wrong way. How could this happen?
Well, it happened to me with an IOMEGA backup product. Half of the software didn't work anymore, because it had the wrong path in their
Two lessons learned:
1) Don't trust IOMEGA products for backup.
2) Having transparent (=automatic) multiple names for files is evil. The long/short name stuff should have been implemented in a different way, that makes it less automatic and thus more controllable/predictable to the developpers.
Marc