Oh, I suspect that he might very well have been using full-disk encryption, which would meet the definition of 'heavily encrypted'. The lesson to take away here is that it doesn't matter how heavily you encrypt your data if you let your device get captured after you've logged in. From the motion for detention, he made a sale at a diner while being watched by Secret Service agents and got picked up 'shortly thereafter', whatever that means, and if he failed to completely power down his laptop between sale and arrest, it's game over. Lesson for the day: if you're carrying evidence that will destroy your life, remember that closing the lid on your laptop doesn't actually wipe its memory.
As an aside, I also suspect the motive for the phrasing is less 'undermining cryptography' as 'look how awesome we are'. Almost all documents by any law enforcement agency on a major bust puff up how devious and sophisticated the bad guy was, so they can imply that they were even better.
The oddity to this is that they already have an approval mechanism -- it's evident when they say that if you leave a group that someone has added you to, you cannot be re-added without authorization. That makes it pretty clear to me that it would be trivial to make that setting a default, but they don't want to.
Anyone care to start making a bot that automatically joins and then leaves groups as they are detected?
Leisure reading on wireless-equipped tablets is becoming popular, however. I'm doing all of my reading nowadays either on a PDA or at my computer. The number of people reading on personal electronics is increasing quite nicely.
Personally, though, I have difficulty with the notion of paying much for a book I can't pull out of my archive and re-read later, loan to a friend, fix typos in, or reorganize to my taste. This site looks like a 'read-only-while-subscribed' service. If they don't allow archiving to ePub, then it has no value to me.
1. It was tested, under controlled conditions, by experienced engineers who only turned the thing on long enough to test it. What happens when you get some sadistic grunt on the trigger who just holds the fire button down?
He writes out a paper saying, in big bold (but still unreadable) letters, "Absolutely do not, under any circumstances, give this person Viagra"?
"... we dare not increase the chance of reproduction."
(I left a med-school path in college after I started to encounter patients that I was slightly horrified might be saved. I can truly see a doctor thinking the above, if not actually writing it.)
Funny, you didn't follow the link which proves Eason right.
Speaking as the person that wrote the page you linked to (Hi Slashdot! Please don't hurt my server; it's small.), I'd like to point out that it doesn't (and was not intended to) "prove Eason right", but to demonstrate that he had reasonable cause to believe even the most extreme version of what is claimed he said.
There is a subtle, but important difference there. Especially since there is no record available at this time of what he actually did say.
I think it's referring to the ability to read DVD+R discs there. Note that on the lower left box on the back, it's talking about burning from a camcorder or VCR, and that that format will be compatable. I'll admit that the "Archive up to..." line is a bit deceptive, though, since it implies that you'd be doing the archiving from the device in question.
When I was mentioning the tech specs on the box, I was referring to the panel on the side of the box entitled "Technical specifications:" where it says: "Compatability for writing: CD-Recordable and CD-ReWritable, DVD+RW", but no mention of DVD+R. In light of this, I'm not entirely sure where I stand. In my mind, when I purchased the thing, it was entirely clear to me that I couldn't expect to use it to burn DVD+R discs, but I do see how someone could have been confused by that one back panel, but only if they didn't bother to read the technical specifications. Considering the amount of vague, misworded, or downright misleading advertising considered "acceptable" today, though, I'm not sure it warrants singling out Philips for attention.
It was a screwup on HP's part, and according to one poster, they are offering refunds to those people who bought the drive on the assumption that it would later support DVD+R.
Incidentally, HP is the only company that I know of that promised DVD+R support. IIRC, Philips only said that they *might* support DVD+R in a future firmware update, but didn't promise anything. The spec sheet on the box did not list DVD+R support.
Because it wasn't so that I could burn a simple DVD -- it was so that I could do high speed rewriting on the platform I do most of my work on (Debian GNU/Linux), the platform I play games on (Windows 98), and have the possibility of burning DVD video that has a good chance of working on a standard DVD player. As of this moment, no other device suits that need. I do a fair number of things on my systems that I just can't do with a Macintosh.
You, on the other hand, sound like you need that Macintosh, so don't let my endorsement of the drive get in your way.
I used it back when it was new technology. It was in fact a very slow drive, but it allowed for random access file manipulation and effectively unlimited rewriting, which CD-Rs didn't. And CD-R discs weren't as cheap back then.
I own both a DVD-RAM and a DVD+RW (a Philips DVDRW208, the exact model as the second drive in the review), and use them primarily for data storage. This rant starts with some DVD-RAM history and moves on to the DVD+RW, so if you're only interested in the latter, skip down a ways.
I got the DVD-RAM some years back, with the intent of using it as a shared data medium between a Windows machine and a Linux machine (running kernel 2.2.5 or so, IIRC). At that time, I had been using a PD (Phase Dual, the DVD-RAM precursor), and since the DVD-RAM dirve I was interested in (a SCSI Panasonic LF-D101) also had support for PD cartridges, it was a natural step up. It worked pretty much exactly as advertised, except that at one point, I reformatted one of the discs (with FAT32) in such a way that for some reason Linux was never able to mount it again, though Windows had no problem with it. Reformatting it from one OS or the other resulted in the opposing OS being unable to read it, so I eventually formatted it ext2fs and used it to make direct backups that didn't require tar to keep permissions and such. It was slow, and it was a little clunky, but it got the job done pretty well.
A short while ago, I upgraded the kernel on that particular Linux machine to 2.4.18, and got a bit of a surprise -- it was no longer possible to reformat the discs, although they did mount rw and I was able to manipulate the data. Well, I had been looking at DVD+RW for some time, had eventually decided on the Philips model as the best of the bunch, and when I saw it for sale online, I ordered it.
Okay, the people interested in DVD+RW stuff can start reading again
The DVD+RW dropped into the new (dual boot Windows 98/Linux 2.4.19-pre2) system quite nicely, although I do recall from reading other people's experiences that it much preferred being the slave drive on an IDE chain. This suited me fine, as I already had an IDE DVD-ROM (AOpen 1640 Pro-A, with 3rd-party RPC-1 firmware) in the system. Installing the drivers on the Windows side was a multiple pass process, as the packet writer initially refused to work with the DVD+RW media supplied with the drive (more on this below). Also a test burn I was making with Nero crashed the machine about halfway through, so I'm not overy enchanted with the quality of the Windows drivers. Nothing new there. On the Linux side, I passed hdc=ide-scsi and hdd=ide-scsi to the kernel to make both drives accessable from the SCSI subsystems, and started compiling the software at the DVD+RW for Linux page. I also tested a CD-RW burn with XCDRoast, which worked just fine, although the speed got locked at 4x, and I'm not entirely sure why (the drive itself should support 10x CD-RW burning).
Writing to the DVD+RW media under Linux has to pretty much be done exclusively with growisofs. There's a kernel patch available that is supposed to enable packet writing for the device, but I was unable to get it to work. The result is data that can be written to the disc and read pretty much on any DVD-ROM that can handle standard ISO9660 data and read the DVD+RW media at all (fortunately, most of them can). Unfortunately, writing this way reduces much of the functionality of the DVD+RW to that of a very fast DVD-RW -- you have to erase all the data to erase one file, though fortunately growisofs can trivially add data. Ideally, someone will write a working packet writing driver for Linux, fix the UDF driver (more on this below) and get those patches included in the 2.5 series. Until then, however, I'll just have to make do. Fortunately, the drive is so damn fast, that I don't mind writing things in large chunks.
Bolstered by my success writing under Linux, I went back to Windows to check on the readability. Windows was able to read the disc just fine, though due to the limitations of the Joliet CD extension, filenames were restricted to 64 characters if I wanted them to show up correctly in Windows (RockRidge fortunately has no such restriction, but Windows doesn't support it). To my delight, the InCD Packet Writing driver suddenly started working as well (I suspect it simply needed something to have been written to the disc once). I activated it, reformatted the DVD+RW disc as UDF, and tried dragging and dropping a few files onto it. Worked like a charm, and no speed drop as far as I could tell. So I booted back to Linux to see how well Linux could deal with it.
Well, the disc mounted. Files were retrievable. Unfortunately, the uid and gid of all the files was set to 4294967295. Remounting it with -o gid=1000,uid=1000 got relatively sane values, though it would have been nice to have the driver automatically set the ownership to either root or nobody by default. Unfortunately, the disc was still detected as write-protected by the kernel, so it was impossible to test writing to the disc. Still, I'm not entirely disappointed. I can write to it in chunks from Linux and have it read by either Linux or Windows, and drag-and-drop to it from Windows and have it read in either Windows or Linux, and that's good enough for my purposes.
You know, you have this obsession with the DVD Forum that I find most unhealthy, and somehow, you keep getting modded up for it.
For DVD video, DVD+RW has pretty much exactly the same success rate as DVD-RW at being read in standard DVD players, and it handles data much better to boot. (Did you actually read the review, or did you just come here to troll the DVD+RW standards folks?) If it can be played in as many DVD players as DVD-RW, have data read by most DVD-ROMs, read DVD discs, read DVD-R discs, even read DVD-RW discs, it can bloody well put "DVD" as part of its name.
Ah, I see. So in order to keep people from slashdotting megatokyo.com, you post a link to megatokyo.com for them to jump to to read about why it's a bad idea for everyone to jump to megatokyo.com. Good idea, that...
Although the initial advertising claimed otherwise, with the more recent firmwares (2.3.x, the one I have currently is 2.3.2) DO in fact support transferring data from the device back to the hard disk. There is a FAQ that has links to the various places which have software that can do this -- one of which is a SourceForge Project.
The PJB itself is a fairly nifty device (though the main website tends to get either broken out outdated from time to time -- and the pictures they have of the products are in some cases DEAD WRONG! The only colors that are really available as shown are the titanium with black buttons and the all black; the blue one is actually kind of an off teal with dark teal buttons) -- storage capacities range from 6GB to 30GB, making the high-end model the largest capacity wearable MP3 player that I know about.
There are Linux synchronization tools available, but they were all unfortunately in a more or less half-finished state the last time I checked, so I still rip under Linux and then boot back to Windows to transfer the MP3 files to the PJB. It also has the downside of being USB rather than firewire, so transferring large amounts of data can take a while. Battery life is around 10 hours with the rechargeable LI battery. Recharging can only be done in the main device though -- no external chargers are aviailable. It also makes a loud tone when the battery is getting low, and will make the tone again after a few seconds of playing if you stop and then start the device again, which can be somewhat disconcerting if you weren't expecting it, especially since it triggers when there's still an hour or two of life left in the device. It is documented in the manual, but was easy to overlook or forget.
The navigation buttons are fairly easy to use and simple to understand. I've had one problem with an mp3 that had a click in it that wasn't present when played on the PC, but it was an isolated case, and was one of my oldest rips, so it might be a genuine glitch in the encoding.
Well, this turned into more of a full review than a comment on another device that can do two-way transfers, so I should probably shut up now. I will add a final note that I had problems when trying to reach the company directly or order directly from their website, so I ended up buying from MP3FactoryDirect and quite satisfied with that.
Remove www.debian.org from your list. It does use.png images (and there are half a dozen of them on the main page, at least), just not exclusively.For that matter, including www.gnu.org is somewhat unfair, as they pretty much only use the one image on the entire site, and although it's in jpeg format on the main page, it is also available in.png (in fact, the high resolution version is only available in.png). See http://www.gnu.org/graphics/agnuhead.html.
So who is using PNG? Some of the people you list as not using PNG.
(... mutter mutter... moderators that don't check claims... mutter mutter...)
More disturbing to me is that the key used to sign that message (as found in c.s.p.d) had an invalid self-signature when I yanked it off the keyservers.
Can anyone confirm that Zimmerman normally uses that key? Does anyone have a valid version of it?
A question at some point has to be asked, how much spam leakage is considered acceptable for an ISP. The general Mail-Abuse Filters currently available are very conservative in the addresses that they accept, and rightly so. Still, little things like this make me think that there should be a special category for ISPs that are trying to do the right thing with regards to e-mail and spam, but for whatever reason can't get their acts together well enough to prevent large amounts of spam leaving their borders. It is, after all, the responsibility of a provider to insure that they are not a problem on the network, not the responsibility of the network to clean up for them.
The idea of creating a real-info blacklist has been bounced around a few times and generally rejected as legally infeasable (would generate too many lawsuits), but still, I keep wishing that as long as ISPs are using AUPs that are incredibly restrictive on users they might as well go all the way and put in a clause stating that by joining the service, you agree that if you are terminated for abuse, the reason for termination and any personal information submitted for the purpose of gaining access may be distributed to all other ISPs that are interested in making account acceptance decisions based upon that information. Maybe give it a 3 or 7 year expiration, kind of like bad credit. Access to a list like this might give even slow ISPs a chance to keep ahead of the problem by preventing it from becoming an issue.
But enough dreaming. For now, we have to make do with whatever technical solutions are available, whether they be RBL-like general blacklists or personal filters. At least those with skill tend not to be spammed much.
The second issue brought up by the article (albeit somewhat indirectly) is the gradual blockage of direct access to mail to dial-up users, either by blocking SMTP at the router level, or by using the MAPS DUL. Despite having great sympathies for the desire to relieve the general frustration caused by spammers with disposable accounts by simply removing one major source of those accounts from the picture, it unfairly places the communication ability of anyone not rich enough for static IPs at the mercy of the frequently abysmal performance of the mail server of their ISP (@Home, for instance, has mail servers that go down on a regular basis, and despite repeated claims to the contrary has been losing a rather disturbing amount of e-mail altogether) -- whether or not that ISP is having any more difficulty controlling its dialup/dynamic-ip users than it is its users with static addresses. Granted, a number of ISPs are filtering at the router or submitting their dialup addresses directly to the DUL themselves, but I have yet to see one of them disclose in their advertisements that they provide a crippled internet connection.
So in summary, what we still need to control this problem ourselves is a better way of publicizing the e-mail distribution points that take a long time to deal with spammers, and a better way of identifying only those dynamic address ranges belonging to ISPs that are either incapable of dealing with their dynamic-IP userbase or have given up on it completely -- and then a centralized location to check up on ISPs with broken services ahead of time, sort of like a Better Business Bureau for the internet.
How to do it? I have no idea. Here's to hoping someone else does.
PGP/GPG Compatabililty problems
on
GPG vs. PGP?
·
· Score: 2
I encountered the following problems when switching from PGP to GPG (on a Unix system), sending messages to someone using PGP for Windows on the remote end:
Difference in detached signatures -- I'm not sure what changed, but it broke Eudora's verification on the remote end, which verified the detached PGP message fine, but refused to deal with the GPG one. Also, signed-and-encrypted messages from GPG that look like a single block seem to appear as detached-signature-inside-encryption to some Windows programs (this latter may have been user error on the other side, as it went away at some point).
Difference in the treatment of newlines at the end of clearsigned messages. GPG doesn't add one (deliberately, I'm told, to match the OpenPGP standard), and PGP does. This may break some scripts that are expecting a newline before the signature marker no matter what the situation.
Even when using the RSA plugin, GPG refused to create RSA keys. That may be about to change, and it may have been at least partially the result of a bug. I was told on IRC today that GPG key generation suffered from brokenness.
As it currently stands, have three PGP programs in use on my machine -- PGP 2.6 so I can create v3 RSA keys, PGP 5.0 to get around some of the problems mentioned above, and GPG 1.0.2 that I've patched to remove the RSA warning and announcement of system type in the version string. If you are planning to use GPG, I heartily recommend keeping those other two around as well.
Re:PGPing your email?
on
GPG vs. PGP?
·
· Score: 1
I think you had some odd grown-ups around you. In my mind, if you don't mean it, you shouldn't write it.
In any case, I make a habit of signing any e-mail messages coming from my machine so that it becomes recognized as one of my habits -- and therefore if a message shows up from me in someone's e-mail box that isn't signed, the question of its authenticity might be immediately raised (i.e. if someone spoofs a message from me to anyone who regularly receives e-mail from me, it won't pass unnoticed simply because it will lack a valid signature; if I didn't consistently sign my e-mails, the person on the receiving end might simply think I either forgot or hadn't bothered that time).
I encrypt all mail to anyone who has shown acceptance of it for similar reasons.
Re:What about RSA now?
on
GPG vs. PGP?
·
· Score: 1
My understanding is that they have already integrated it into the working tree, so when 1.0.3 comes out, it will be there.
As others have already pointed out, 56k is fine. While LucasArts may some day either release or contract to have ported Linux versions of their games, Sony/Verant almost certainly will NOT. They are downright paranoid about their system, and are firm believers in security through obscurity (which has already failed with Everquest). They attempt to prevent people from affecting their environment by completely taking over the system. You cannot switch out of the Everquest game once it is started to check mail, ICQ, or anything else. Since this would be impossible to enforce under Linux, it will probably never see a client.
If you have any familiarity with MUDs, especially DIKU MUDs, add graphics and a huge playerbase and you have the current crop of MMRPGs. Gameplay revolves around characters that you design within a certain framework, then drop into a world competing for resources with all the other players.
The good thing about this is that you can encounter people with common gaming interests, skills, and share a certain sense of camaraderie and group accomplishment. The bad thing about this is that you can also encounter people who are playing for the sole purpose of hurting other players, and you will encounter a lot of people who are simply thoughtless twits. The amount of your time they can waste with their various forms of harassment varies from game to game (Ultima Online was the worst in this regard, Everquest the best), but it is ever present.
While the elements of traditional CRPGs usually exist (attribute values, hit points, mana, etc.), the amount of role-playing that goes on is heavily dependent upon the environment, and specific game. Ultima Online provided a technical environment that was much more conducive to role-playing than either of its competitors, but suffered from an incredible number of antisocial players. The sheer number of people makes it difficult to build a role-playing environment that doesn't immediately get swamped by idiots, something that was made worse in Everquest by the immense amount of game time it takes to get from one place to another.
If you're looking for an actual internet role-playing game, you'll need to wait a while. Nobody has figured it out yet (though the upcoming Neverwinter Nights does look promising). If you want to get together with nifty people for a persistent-character hack-and-slash, you actually might be better off with a small-group environment such as in the Diablo or Baldur's Gate series. MMRPGs are really for the very tolerant.
Slashdot Mirror
What? Tell me. WHAT ARE THEY SEEING?
... problems with data truncation.
Oh, I suspect that he might very well have been using full-disk encryption, which would meet the definition of 'heavily encrypted'. The lesson to take away here is that it doesn't matter how heavily you encrypt your data if you let your device get captured after you've logged in. From the motion for detention, he made a sale at a diner while being watched by Secret Service agents and got picked up 'shortly thereafter', whatever that means, and if he failed to completely power down his laptop between sale and arrest, it's game over. Lesson for the day: if you're carrying evidence that will destroy your life, remember that closing the lid on your laptop doesn't actually wipe its memory.
As an aside, I also suspect the motive for the phrasing is less 'undermining cryptography' as 'look how awesome we are'. Almost all documents by any law enforcement agency on a major bust puff up how devious and sophisticated the bad guy was, so they can imply that they were even better.
The oddity to this is that they already have an approval mechanism -- it's evident when they say that if you leave a group that someone has added you to, you cannot be re-added without authorization. That makes it pretty clear to me that it would be trivial to make that setting a default, but they don't want to.
Anyone care to start making a bot that automatically joins and then leaves groups as they are detected?
Leisure reading on wireless-equipped tablets is becoming popular, however. I'm doing all of my reading nowadays either on a PDA or at my computer. The number of people reading on personal electronics is increasing quite nicely.
Personally, though, I have difficulty with the notion of paying much for a book I can't pull out of my archive and re-read later, loan to a friend, fix typos in, or reorganize to my taste. This site looks like a 'read-only-while-subscribed' service. If they don't allow archiving to ePub, then it has no value to me.
That's appropriate, since Emacs is famous for attempting to become an operating system.
1. It was tested, under controlled conditions, by experienced engineers who only turned the thing on long enough to test it. What happens when you get some sadistic grunt on the trigger who just holds the fire button down?
Well, hypothetically the safeties kick in. In practice, when things go wrong you get $18,000 worth of second degree burns. And that's during a controlled test.
Of course, nobody ever encounters additional surprises when going from controlled tests to open production.
Woo! A mouse with zero tactile feedback! Just what I always wanted in an input tool that I need to be precise.
He writes out a paper saying, in big bold (but still unreadable) letters, "Absolutely do not, under any circumstances, give this person Viagra"?
"... we dare not increase the chance of reproduction."
(I left a med-school path in college after I started to encounter patients that I was slightly horrified might be saved. I can truly see a doctor thinking the above, if not actually writing it.)
There is a subtle, but important difference there. Especially since there is no record available at this time of what he actually did say.
Huh... <...yanks box out to look at it again...>
I think it's referring to the ability to read DVD+R discs there. Note that on the lower left box on the back, it's talking about burning from a camcorder or VCR, and that that format will be compatable. I'll admit that the "Archive up to..." line is a bit deceptive, though, since it implies that you'd be doing the archiving from the device in question.
When I was mentioning the tech specs on the box, I was referring to the panel on the side of the box entitled "Technical specifications:" where it says: "Compatability for writing: CD-Recordable and CD-ReWritable, DVD+RW", but no mention of DVD+R. In light of this, I'm not entirely sure where I stand. In my mind, when I purchased the thing, it was entirely clear to me that I couldn't expect to use it to burn DVD+R discs, but I do see how someone could have been confused by that one back panel, but only if they didn't bother to read the technical specifications. Considering the amount of vague, misworded, or downright misleading advertising considered "acceptable" today, though, I'm not sure it warrants singling out Philips for attention.
It was a screwup on HP's part, and according to one poster, they are offering refunds to those people who bought the drive on the assumption that it would later support DVD+R.
Incidentally, HP is the only company that I know of that promised DVD+R support. IIRC, Philips only said that they *might* support DVD+R in a future firmware update, but didn't promise anything. The spec sheet on the box did not list DVD+R support.
Because it wasn't so that I could burn a simple DVD -- it was so that I could do high speed rewriting on the platform I do most of my work on (Debian GNU/Linux), the platform I play games on (Windows 98), and have the possibility of burning DVD video that has a good chance of working on a standard DVD player. As of this moment, no other device suits that need. I do a fair number of things on my systems that I just can't do with a Macintosh.
You, on the other hand, sound like you need that Macintosh, so don't let my endorsement of the drive get in your way.
It was odd enough that I had dumped the output of ls -alF to a text file, and I looked it up when I wrote the message.
I used it back when it was new technology. It was in fact a very slow drive, but it allowed for random access file manipulation and effectively unlimited rewriting, which CD-Rs didn't. And CD-R discs weren't as cheap back then.
I own both a DVD-RAM and a DVD+RW (a Philips DVDRW208, the exact model as the second drive in the review), and use them primarily for data storage. This rant starts with some DVD-RAM history and moves on to the DVD+RW, so if you're only interested in the latter, skip down a ways.
I got the DVD-RAM some years back, with the intent of using it as a shared data medium between a Windows machine and a Linux machine (running kernel 2.2.5 or so, IIRC). At that time, I had been using a PD (Phase Dual, the DVD-RAM precursor), and since the DVD-RAM dirve I was interested in (a SCSI Panasonic LF-D101) also had support for PD cartridges, it was a natural step up. It worked pretty much exactly as advertised, except that at one point, I reformatted one of the discs (with FAT32) in such a way that for some reason Linux was never able to mount it again, though Windows had no problem with it. Reformatting it from one OS or the other resulted in the opposing OS being unable to read it, so I eventually formatted it ext2fs and used it to make direct backups that didn't require tar to keep permissions and such. It was slow, and it was a little clunky, but it got the job done pretty well.
A short while ago, I upgraded the kernel on that particular Linux machine to 2.4.18, and got a bit of a surprise -- it was no longer possible to reformat the discs, although they did mount rw and I was able to manipulate the data. Well, I had been looking at DVD+RW for some time, had eventually decided on the Philips model as the best of the bunch, and when I saw it for sale online, I ordered it.
Okay, the people interested in DVD+RW stuff can start reading again
The DVD+RW dropped into the new (dual boot Windows 98/Linux 2.4.19-pre2) system quite nicely, although I do recall from reading other people's experiences that it much preferred being the slave drive on an IDE chain. This suited me fine, as I already had an IDE DVD-ROM (AOpen 1640 Pro-A, with 3rd-party RPC-1 firmware) in the system. Installing the drivers on the Windows side was a multiple pass process, as the packet writer initially refused to work with the DVD+RW media supplied with the drive (more on this below). Also a test burn I was making with Nero crashed the machine about halfway through, so I'm not overy enchanted with the quality of the Windows drivers. Nothing new there. On the Linux side, I passed hdc=ide-scsi and hdd=ide-scsi to the kernel to make both drives accessable from the SCSI subsystems, and started compiling the software at the DVD+RW for Linux page. I also tested a CD-RW burn with XCDRoast, which worked just fine, although the speed got locked at 4x, and I'm not entirely sure why (the drive itself should support 10x CD-RW burning).
Writing to the DVD+RW media under Linux has to pretty much be done exclusively with growisofs. There's a kernel patch available that is supposed to enable packet writing for the device, but I was unable to get it to work. The result is data that can be written to the disc and read pretty much on any DVD-ROM that can handle standard ISO9660 data and read the DVD+RW media at all (fortunately, most of them can). Unfortunately, writing this way reduces much of the functionality of the DVD+RW to that of a very fast DVD-RW -- you have to erase all the data to erase one file, though fortunately growisofs can trivially add data. Ideally, someone will write a working packet writing driver for Linux, fix the UDF driver (more on this below) and get those patches included in the 2.5 series. Until then, however, I'll just have to make do. Fortunately, the drive is so damn fast , that I don't mind writing things in large chunks.
Bolstered by my success writing under Linux, I went back to Windows to check on the readability. Windows was able to read the disc just fine, though due to the limitations of the Joliet CD extension, filenames were restricted to 64 characters if I wanted them to show up correctly in Windows (RockRidge fortunately has no such restriction, but Windows doesn't support it). To my delight, the InCD Packet Writing driver suddenly started working as well (I suspect it simply needed something to have been written to the disc once). I activated it, reformatted the DVD+RW disc as UDF, and tried dragging and dropping a few files onto it. Worked like a charm, and no speed drop as far as I could tell. So I booted back to Linux to see how well Linux could deal with it.
Well, the disc mounted. Files were retrievable. Unfortunately, the uid and gid of all the files was set to 4294967295. Remounting it with -o gid=1000,uid=1000 got relatively sane values, though it would have been nice to have the driver automatically set the ownership to either root or nobody by default. Unfortunately, the disc was still detected as write-protected by the kernel, so it was impossible to test writing to the disc. Still, I'm not entirely disappointed. I can write to it in chunks from Linux and have it read by either Linux or Windows, and drag-and-drop to it from Windows and have it read in either Windows or Linux, and that's good enough for my purposes.
You know, you have this obsession with the DVD Forum that I find most unhealthy, and somehow, you keep getting modded up for it.
For DVD video, DVD+RW has pretty much exactly the same success rate as DVD-RW at being read in standard DVD players, and it handles data much better to boot. (Did you actually read the review, or did you just come here to troll the DVD+RW standards folks?) If it can be played in as many DVD players as DVD-RW, have data read by most DVD-ROMs, read DVD discs, read DVD-R discs, even read DVD-RW discs, it can bloody well put "DVD" as part of its name.
Ah, I see. So in order to keep people from slashdotting megatokyo.com, you post a link to megatokyo.com for them to jump to to read about why it's a bad idea for everyone to jump to megatokyo.com. Good idea, that...
Although the initial advertising claimed otherwise, with the more recent firmwares (2.3.x, the one I have currently is 2.3.2) DO in fact support transferring data from the device back to the hard disk. There is a FAQ that has links to the various places which have software that can do this -- one of which is a SourceForge Project.
The PJB itself is a fairly nifty device (though the main website tends to get either broken out outdated from time to time -- and the pictures they have of the products are in some cases DEAD WRONG! The only colors that are really available as shown are the titanium with black buttons and the all black; the blue one is actually kind of an off teal with dark teal buttons) -- storage capacities range from 6GB to 30GB, making the high-end model the largest capacity wearable MP3 player that I know about.
There are Linux synchronization tools available, but they were all unfortunately in a more or less half-finished state the last time I checked, so I still rip under Linux and then boot back to Windows to transfer the MP3 files to the PJB. It also has the downside of being USB rather than firewire, so transferring large amounts of data can take a while. Battery life is around 10 hours with the rechargeable LI battery. Recharging can only be done in the main device though -- no external chargers are aviailable. It also makes a loud tone when the battery is getting low, and will make the tone again after a few seconds of playing if you stop and then start the device again, which can be somewhat disconcerting if you weren't expecting it, especially since it triggers when there's still an hour or two of life left in the device. It is documented in the manual, but was easy to overlook or forget.
The navigation buttons are fairly easy to use and simple to understand. I've had one problem with an mp3 that had a click in it that wasn't present when played on the PC, but it was an isolated case, and was one of my oldest rips, so it might be a genuine glitch in the encoding.
Well, this turned into more of a full review than a comment on another device that can do two-way transfers, so I should probably shut up now. I will add a final note that I had problems when trying to reach the company directly or order directly from their website, so I ended up buying from MP3FactoryDirect and quite satisfied with that.
Remove www.debian.org from your list. It does use .png images (and there are half a dozen of them on the main page, at least), just not exclusively.For that matter, including www.gnu.org is somewhat unfair, as they pretty much only use the one image on the entire site, and although it's in jpeg format on the main page, it is also available in .png (in fact, the high resolution version is only available in .png). See http://www.gnu.org/graphics/agnuhead.html.
So who is using PNG? Some of the people you list as not using PNG.
(... mutter mutter ... moderators that don't check claims ... mutter mutter ...)
More disturbing to me is that the key used to sign that message (as found in c.s.p.d) had an invalid self-signature when I yanked it off the keyservers.
Can anyone confirm that Zimmerman normally uses that key? Does anyone have a valid version of it?
The idea of creating a real-info blacklist has been bounced around a few times and generally rejected as legally infeasable (would generate too many lawsuits), but still, I keep wishing that as long as ISPs are using AUPs that are incredibly restrictive on users they might as well go all the way and put in a clause stating that by joining the service, you agree that if you are terminated for abuse, the reason for termination and any personal information submitted for the purpose of gaining access may be distributed to all other ISPs that are interested in making account acceptance decisions based upon that information. Maybe give it a 3 or 7 year expiration, kind of like bad credit. Access to a list like this might give even slow ISPs a chance to keep ahead of the problem by preventing it from becoming an issue.
But enough dreaming. For now, we have to make do with whatever technical solutions are available, whether they be RBL-like general blacklists or personal filters. At least those with skill tend not to be spammed much.
The second issue brought up by the article (albeit somewhat indirectly) is the gradual blockage of direct access to mail to dial-up users, either by blocking SMTP at the router level, or by using the MAPS DUL. Despite having great sympathies for the desire to relieve the general frustration caused by spammers with disposable accounts by simply removing one major source of those accounts from the picture, it unfairly places the communication ability of anyone not rich enough for static IPs at the mercy of the frequently abysmal performance of the mail server of their ISP (@Home, for instance, has mail servers that go down on a regular basis, and despite repeated claims to the contrary has been losing a rather disturbing amount of e-mail altogether) -- whether or not that ISP is having any more difficulty controlling its dialup/dynamic-ip users than it is its users with static addresses. Granted, a number of ISPs are filtering at the router or submitting their dialup addresses directly to the DUL themselves, but I have yet to see one of them disclose in their advertisements that they provide a crippled internet connection.
So in summary, what we still need to control this problem ourselves is a better way of publicizing the e-mail distribution points that take a long time to deal with spammers, and a better way of identifying only those dynamic address ranges belonging to ISPs that are either incapable of dealing with their dynamic-IP userbase or have given up on it completely -- and then a centralized location to check up on ISPs with broken services ahead of time, sort of like a Better Business Bureau for the internet.
How to do it? I have no idea. Here's to hoping someone else does.
Difference in detached signatures -- I'm not sure what changed, but it broke Eudora's verification on the remote end, which verified the detached PGP message fine, but refused to deal with the GPG one. Also, signed-and-encrypted messages from GPG that look like a single block seem to appear as detached-signature-inside-encryption to some Windows programs (this latter may have been user error on the other side, as it went away at some point).
Difference in the treatment of newlines at the end of clearsigned messages. GPG doesn't add one (deliberately, I'm told, to match the OpenPGP standard), and PGP does. This may break some scripts that are expecting a newline before the signature marker no matter what the situation.
Even when using the RSA plugin, GPG refused to create RSA keys. That may be about to change, and it may have been at least partially the result of a bug. I was told on IRC today that GPG key generation suffered from brokenness.
As it currently stands, have three PGP programs in use on my machine -- PGP 2.6 so I can create v3 RSA keys, PGP 5.0 to get around some of the problems mentioned above, and GPG 1.0.2 that I've patched to remove the RSA warning and announcement of system type in the version string. If you are planning to use GPG, I heartily recommend keeping those other two around as well.
In any case, I make a habit of signing any e-mail messages coming from my machine so that it becomes recognized as one of my habits -- and therefore if a message shows up from me in someone's e-mail box that isn't signed, the question of its authenticity might be immediately raised (i.e. if someone spoofs a message from me to anyone who regularly receives e-mail from me, it won't pass unnoticed simply because it will lack a valid signature; if I didn't consistently sign my e-mails, the person on the receiving end might simply think I either forgot or hadn't bothered that time).
I encrypt all mail to anyone who has shown acceptance of it for similar reasons.
My understanding is that they have already integrated it into the working tree, so when 1.0.3 comes out, it will be there.
If you have any familiarity with MUDs, especially DIKU MUDs, add graphics and a huge playerbase and you have the current crop of MMRPGs. Gameplay revolves around characters that you design within a certain framework, then drop into a world competing for resources with all the other players.
The good thing about this is that you can encounter people with common gaming interests, skills, and share a certain sense of camaraderie and group accomplishment. The bad thing about this is that you can also encounter people who are playing for the sole purpose of hurting other players, and you will encounter a lot of people who are simply thoughtless twits. The amount of your time they can waste with their various forms of harassment varies from game to game (Ultima Online was the worst in this regard, Everquest the best), but it is ever present.
While the elements of traditional CRPGs usually exist (attribute values, hit points, mana, etc.), the amount of role-playing that goes on is heavily dependent upon the environment, and specific game. Ultima Online provided a technical environment that was much more conducive to role-playing than either of its competitors, but suffered from an incredible number of antisocial players. The sheer number of people makes it difficult to build a role-playing environment that doesn't immediately get swamped by idiots, something that was made worse in Everquest by the immense amount of game time it takes to get from one place to another.
If you're looking for an actual internet role-playing game, you'll need to wait a while. Nobody has figured it out yet (though the upcoming Neverwinter Nights does look promising). If you want to get together with nifty people for a persistent-character hack-and-slash, you actually might be better off with a small-group environment such as in the Diablo or Baldur's Gate series. MMRPGs are really for the very tolerant.