Nowadays, if you're willing to stay even just a little bit outside of the Yamanote loop line, and if you know where to look (hint: online, especially if you can read a bit of Japanese, in which case Jalan.net is the place to go), you can get small hotel rooms for the same price as capsule hotels in Tokyo.
I should know: I'm sitting in such a room right now. The place where I'm staying has weekly rates which rival the cheapest apartment room rentals -- which usually have the inconvenience of requiring upfront monthly payments, deposits, and often "key money" and "gift money" (unless dealing with special agencies like Sakura House who specialize in housing foreigners, the first month of rent can easily cost you four times the normal rent, and we haven't talked about the utilities yet)
Since this is/. : did I mention that my room has top-notch Internet connectivity? I was downloading stuff from my Montreal-based "home" server at over 50 Mb/s yesterday night! You get an Ethernet jack in the room, and the place is blanketed with free wifi. (Of course you still end up behind a NAT, but I don't think I've ever seen a hotel handing out public IPs...)
The hotel is split in smoking and non-smoking floors, and there's even a women-only floor. There's a coin laundry on the first floor, nice bathing and toilet facilities (cleaner than most 6000-8000 yen/night downtown Shinjuku business hotels I've stayed in), microwave ovens and hot water on each floor... With convenience stores and 100yen shops close by, it makes it really easy to live on a shoestring budget even in this supposedly extremely expensive city.
And this place is far from unique: hell, there's another one just like it right across the street.
Did I mention the best part yet? Unlike most budget hotels... there are virtually no noisy foreigners here!
Fundamentally the DNS is about navigation. It's about helping users get where they are trying to go.
Fundamentally, the DNS is a distributed database.
I imagine that the word "navigation" was mostly used to refer to maritime traffic when the DNS was designed. Or maybe interstellar traffic, depending what these guys were watching on TV.
By the way, of particular interest to this discussion is section 2.3 of RFC 1035:
The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementor is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
ALL behavior observed from other hosts.
OpenDNS is playing fair with its users since they voluntarily use the service. But an ISP whose resolvers lie to its clients ("other hosts") about the existence of a domain is certainly going against the spirit of this paragraph -- not to mention the principle of least astonishment.
Funny... the quote in my.sig is kind of relevant today.
Keeping in mind that some of these figures are outdated by now, combined with NTT's intense marketing campaigns for their "B-Flets" (100Mb/s 2-way) and "Flets Hikari" (shared 1Gb/s?...you get 100Mb/s I think) FTTH services, we're probably talking about over 3 million customers with 100Mb/s fiber Internet!
The area where I live doesn't have coverage yet, but even my current cable modem connection beats the hell out of anything I used to have at home back in North America in terms of both bandwidth and latency.
You've gotta be kidding
on
Spam is Dead
·
· Score: 1
Spam declining? You've gotta be kidding.
Last October, as I was in the process of fine-tuning my SpamAssassin
installation, I took the time to compute some stats to get a better idea of the
big picture. The results?
Between November 11, 2004 and October 9, 2005, a bit less than a year, my
mailbox had received 95708 confirmed spams.
On the other hand, in the last week of October 2005, I had received an average
of 419.42 spams per day. Take that number and scale it to a year: 153193 spams
per year. That's 60% more than before!!!
Given, my mailbox might not be a "typical" one, since I've been using the same
address for over a decade, and it's all over the place (for example, in several
WHOIS records), and I will admit that the spam that actually makes it to my
mailbox has declined — the various tools I use to filter my mail keep
improving, and I give them a good tune-up once a year or so — but with these
numbers, I really don't see how anyone could claim that spam itself is
declining... yet. It's the anti-spam tools that are improving. Or maybe spam
is getting easier to detect, because "we've seen it all" already? Of those
95708 spams, 97.4% scored above 99% on a Bayesian analysis. Combine this with a
few other methods, and I rarely see more than a spam or two in my inbox. And I
haven't ever had a single false positive (yes, I check them all... once in a
while... which reminds me that I'm overdue...)
Oh, I forgot to mention that those numbers do not include any viruses that
have been silently dropped by ClamAV before ever making it to SpamAssassin.
Nowadays that includes some phishing spams too.
By the way, the front end is just an old gentoo box, please don't beat it up to bad. I don't want to work on the weekend!
Oops. Sounds like it's been beat up a bit. The frontend is now apparently getting "connection refused" from the database.
And there I was 80% finished transcribing the full listing for easier browsing... The online interface is nice, but not so good for casual browsing of the entire list. Making a complete list available in a flat format (e.g. tab-delimited) might have been a good idea. I mean, it's not like I know what I'm looking for, I don't know the music of the era... But by browsing the titles, I can find those that look potentially interesting.
A better example - try playing any of the.voc files from the original soundblaster - and that's only a decade or so ago.
I believe sox can handle these good old VOC files, so you can convert them to a format that is more readily playable these days. I still have a bunch of those somewhere...
Now, if I could only find a way to convert the proprietary video format used by my SH501is phone into something I could actually use!
If for some reason you don't feel like rebooting just yet, a friend and I wrote a little kernel module which puts a wrapper around sys_brk() which should prevent this vulnerability from being exploited.
I'm no kernel guru, so if this breaks, you own the pieces... But it's fairly simple code.
I'll still assume this was on a corporate/campus network, not at home.
I/wish/ I had that much bandwidth at home. Although I'm pretty comfortable with my home SDSL link, I'd rather run my bittorent downloads on a well-connected system... In the case of well-seeded torrents, the end result is actually a bit worse since I still have to download it home after, but OTOH, I usually get to contribute significantly more to the torrent.
You did it AGAIN. Please use little 'b' to mean bits, and use big 'B' to mean bytes.
"Again"? While it is ironic that I apparently _did_ make that mistake in my second comment, I believe that the first one was actually quite correct.
2400 kBytes per second? That's 19.2 megabits per second. Really? If not, please be more careful with your b's vs. B's next time.
Yes, I really mean it! 2400 kb/s -- close to 20 megabits per second.
The system I was using for this transfer has 100 megabits per second of Internet transit connectivity (12.5MB/s), so it's not impossible. I often get around 800 kilobytes per second (6.4Mb/s) when using Bittorrent to download well-seeded, popular anime fansubs. My previous torrent speed record was 1300 kilobytes per second (10.4Mb/s).
Perhaps one or a few of the users that were seeding the kernel were topologically close to my system, or had similarly great connectivity...
[And, being lazy, I'm using kilobytes and megabytes here, not "kibibytes" or "mibibytes" -- or whatever it is we're now supposed to call 1024 bytes and 1048576 bytes..]
Wow! I got 2400 kB/s! I don't think I've ever downloaded kernel source that fast...
I was really hoping that someone would start a torrent -- actually, I was thinking of starting one myself if I didn't find one here...
<paranoia> Now, I still have to get the PGP signature from kernel.org since you didn't redistribute it, you know, just to make sure you didn't add anything funny to the kernel;-> </paranoia>
rsync is fine when you have the bandwidth available, and when the time it takes to run the backup remains tolerable. However, unless you can write-lock the filesystem during the process, one interesting problem with a backup that takes a long time to run is that the backup copy represents a state that never really existed: the filesystem might have changed significantly while the backup was running.
My favorite solution to this is breaking 3-way mirrors; see my earlier comment about this (along with the informative replies). It gives you an instant, "checkpoint" backup of your drive.
Let's not forget of course that you can use a versionning filesystem (some Veritas products come to mind) to achieve a "checkpoint" state for your backups. These systems also usually include plenty of built-in backup strategies to answer your question... but we're talking about some bigger dollar signs here.
[...]
you're going to approach JR East and ask them to give you real money? All you have is a bunch of long encrypted strings.
Ok, you can't get cash for it -- but, I don't know about this particular implementation, but unless the cards somehow authenticate the terminals/readers with a challenge/response protocol (in which case it would be hard to impersonate a reader to steal credits in the first place), perhaps you can simply store the tokens you stole ("long encrypted strings" as you called them) to retransmit them later to a legitimate reader? Hey, free transit! ^_^
Sure, this won't instantly make you rich, so the motivation isn't there as much... but if the protocol allows this, someone is bound to try it eventually!
You also need to hit the checkbox to disable ads on the Index.
That is rather sad. I actually like the banner ads on the index page! And I rarely load the index page more than 2~3 times in a given day (I set my index page to display as many articles as possible, and that usually covers a day), so in order to be eligible for the "plum" I would have to completely sacrifice seeing those ads?
I can't stand the bigger ads, which is why I became a subscriber in the first place. I love the banner ads at the top of the index page: it's the first thing on the page, I get to see it before I actually start reading anything, so it doesn't "interrupt" my thought processes. And at that point I will be quite willing to visit the site pointed to by the ad if I'm actually interested. But the big ads in the middle of the page really annoy me, and that's why I turn those off with my subscription.
I guess either (1) OSDN thinks that by enabling ads on the index page our credits would dry up faster, or (2) they want to encourage us to spend our credits on the index page and hope that we'll compensate by turning the big ads back on!
Too bad... given those terms, I guess I'll live without the "plums".
"It's always a concern, particularly from private corporations, to have encrypted data flowing out of your network."
I would rather be concerned by unencrypted data exported from my network. I expect all corporate data transfers to be properly encrypted, to their designated recipients. You can't just start to block all encrypted traffic flowing out of a corporate network without seriously disrupting operations -- unless your system is smart enough to somehow recognize the particular kind of traffic you want to block.
Now let's hope that whoever implements the next generation of P2P software will be smart enough to use standard methods (e.g. SSH or SSL) to ensure that the encrypted P2P traffic can't easily be distinguished from "legitimate" uses of the network;-)
Trying to filter P2P traffic may be a nice goal, but is technically hard to achieve. Once you've given someone access to an IP network, you can't really control what they are transmitting -- unless you control one of the endpoints. Else, anything can be tunnelled over anything (sometimes ASMOP). If bandwidth usage is your concern, graph user bandwidth usage and ask them to justify it in terms of job-related items. Don't try to consider a simple bandwidth abuse problem like it is another kind of problem just because it's P2P. KISS. If you're worried about sensitive corporate data that an employee may be transmitting out of your network, perhaps you should be worried about that USB keychain in his pocket too.
For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.
For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)
In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4/README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
Lucky you! Akihabara is heaven on earth for true geeks! You shouldn't have any problems shopping over there, the prices are well indicated (but sometimes you can try to get better bargain... politely ask "what is the discount price"). But learning just a bit of Japanese can make quite a difference -- e.g. how to formally introduce yourself, and politely ask if they speak English....
But even if you don't want to learn any Japanese per se, I would recommend learning a bit of "katakana".
In Japanese, three sets of symbols/alphabets are used. "Kanjis" are the most complicated, with each symbol representing one or more meanings and having one or more possible pronunciations. The two others, "hiragana" and "katakana" (collectively known as "kana"), are more simple, and represent sounds/syllabs.
Katakana is almost always used to write foreign words, most of them English. This means that if you can read katakana characters, chances are that you will be able to guess the meaning. This is especially true for technical material.
The first time I went to Japan, I spent about twenty hours studying katakana before going, and didn't regret it. Not only did it help me in my Anime and computer shopping, but also in understanding a lot of restaurant menus -- especially fast food ^_^ I think it's definitely worth it.
For a quick learning experience, I recommend Anne Matsumoto Stewart's "All About Katakana", ISBN 4770016964. It's quite cheap, and fun to boot:) Your favorite online bookstore should be able to ship it within a day or so, it's usually in stock.
Now for the _real_ fun, also learn "hiragana" and practice by reading the name of the train stations;->
I read that 3ware stopped selling their Escalade controllers a few weeks ago. They now "focus" on their Palisade NASes... I just checked their web site, and even the announcement to that effect is already gone!
This is bad news. The Escalade controller was definitely my favorite for midrange applications. It is well supported in the Linux kernel, and presents a SCSI interface to your system while still using cheap IDE drives... My favorite server has an Escalade 6800 with four 40G HDs in a RAID 1-0 configuration, which means splitting read requests on four drives -- that's quite fast!
Has anybody tried the Adaptec AAR-2400A? It might be a good alternative...
In a mission-critical environment, it is possible to achieve a very high degree of system-redundancy by using hard drives as a backup solution by "breaking mirrors". (Of course if the system is mission-critical, I'd rather have a geographically distributed set of systems, but that's not always possible...)
The idea is that you setup hot-swappable disks in a three-way mirror, that is, three drives containing the exact same data. When you want/need to take a backup, you simply pull the third drive out of the array. The system still has two drive with the full data set, so you don't loose your redundancy. You insert another drive to replace the one you pulled, and in a matter of hours it will be in sync with the rest of the array. That sync time will depend on the size of the hard drives you use, but should be well under 24 hours for up to at least 40 gigs.
Of course, you need hot-swappable disk drives, and ideally a hardware RAID controller, and you might even want to consider having a disk for every day of the week, so that solution isn't exactly cheap. However, it gives you an instant snapshot of the system when you take your backup, and restoring is simply a matter of putting the backup drive in the machine (or another similar machine, if the first was damaged/lost). If you're paranoid (not to mention incredibly rich), you might even consider a four-way mirror to have two backups, and already have instant redundancy when you restore the system!
Another interesting thing to do is to use disk-level encryption in such a scenario. Since all your drives are encrypted, so are your backups. The problem with that is that you need to provide the key (passphrase or hardware token, or combination) at boot time, which means additional downtime if there's an unscheduled reboot and you're not around with the key...
Also, you might want to do things such as checkpointing your databases right before pulling the backup drive out in order to minimize the chance of data loss. But in the end, it can't be worse than an unexpected power down, and well-written applications and OSes deal with that pretty well. A logging filesystem will definitely help.
Interesting. Let's suppose that Alice has access to a trusted server located somewhere out of the FBI's jurisdiction/reach... And now let's suppose that she receives her e-mail (possibly encrypted) on that system, but reads it remotely from her PC in the US, using SSH to encrypt the communication. In such a situation, the PC is definitely used as a "communication device", and I guess the FBI would have to get an authorization to do a telecommunication interception in order to use a keylogger to grab her SSH key passphrase (or remote system password if not using a key)...
Of course this scenario requires a trusted server in a trusted location -- but that's not too hard to get...
Hmmm...
-- "Words have meaning, and names have power." --Lorien
> The bitrate is the quality of the audio, not the amount of compression.
Hmmm, I'm afraid you are off-track here. Encoding bitrate, usually in kilobits per second, actually describes how many bits you need to encode a second of audio. Therefore, it does indicate the amount of compression that you are achieving (over the original sample bitrate). For example, CD-quality uncompressed audio is 44.1Khz 16 bit stereo sampling, therefore approximately 1411 kilobits per second. If the encoding outputs a stream with a bitrate of 128 kilobits per second, you've achieved a compression ratio of a bit more than 10 to 1.
The japanese word for "idol" is usually written in katakana, one of japanese's two syllabic alphabets -- the one used to render foreign words, or sometimes to add emphasis to a word (the way we would use bold or italic characters). Unfortunately, I can't write katakana on Slashdot, but if you follow the usual conventions to write japanese using our alphabet, you would get 'A-I-DO-RU'. On the other hand, it really is pronounced "eye-doh-ru" -- again, with the "r" in the "ru" pronounced as a mix or "r" and "l"... e.g., they don't say "sayonala" nor "sayonara", but something in between.
Slashdot Mirror
Nowadays, if you're willing to stay even just a little bit outside of the Yamanote loop line, and if you know where to look (hint: online, especially if you can read a bit of Japanese, in which case Jalan.net is the place to go), you can get small hotel rooms for the same price as capsule hotels in Tokyo.
I should know: I'm sitting in such a room right now. The place where I'm staying has weekly rates which rival the cheapest apartment room rentals -- which usually have the inconvenience of requiring upfront monthly payments, deposits, and often "key money" and "gift money" (unless dealing with special agencies like Sakura House who specialize in housing foreigners, the first month of rent can easily cost you four times the normal rent, and we haven't talked about the utilities yet)
Since this is /. : did I mention that my room has top-notch Internet connectivity? I was downloading stuff from my Montreal-based "home" server at over 50 Mb/s yesterday night! You get an Ethernet jack in the room, and the place is blanketed with free wifi. (Of course you still end up behind a NAT, but I don't think I've ever seen a hotel handing out public IPs...)
The hotel is split in smoking and non-smoking floors, and there's even a women-only floor. There's a coin laundry on the first floor, nice bathing and toilet facilities (cleaner than most 6000-8000 yen/night downtown Shinjuku business hotels I've stayed in), microwave ovens and hot water on each floor... With convenience stores and 100yen shops close by, it makes it really easy to live on a shoestring budget even in this supposedly extremely expensive city.
And this place is far from unique: hell, there's another one just like it right across the street.
Did I mention the best part yet? Unlike most budget hotels... there are virtually no noisy foreigners here!
Which is why I won't tell you where it is ;->
Fundamentally, the DNS is a distributed database.
I imagine that the word "navigation" was mostly used to refer to maritime traffic when the DNS was designed. Or maybe interstellar traffic, depending what these guys were watching on TV.
By the way, of particular interest to this discussion is section 2.3 of RFC 1035 :
OpenDNS is playing fair with its users since they voluntarily use the service. But an ISP whose resolvers lie to its clients ("other hosts") about the existence of a domain is certainly going against the spirit of this paragraph -- not to mention the principle of least astonishment.
Funny... the quote in my .sig is kind of relevant today.
Mod parent up!
f
...you get 100Mb/s I think) FTTH services, we're probably talking about over 3 million customers with 100Mb/s fiber Internet!
Japan's clearly leading in terms of bandwidth delivery to home users.
One can find some interesting facts and figures in the following report presented last year:
http://www.asiabroadbandsummit.com/4th/shimizu.pd
Keeping in mind that some of these figures are outdated by now, combined with NTT's intense marketing campaigns for their "B-Flets" (100Mb/s 2-way) and "Flets Hikari" (shared 1Gb/s?
The area where I live doesn't have coverage yet, but even my current cable modem connection beats the hell out of anything I used to have at home back in North America in terms of both bandwidth and latency.
Spam declining? You've gotta be kidding.
Last October, as I was in the process of fine-tuning my SpamAssassin installation, I took the time to compute some stats to get a better idea of the big picture. The results?
Between November 11, 2004 and October 9, 2005, a bit less than a year, my mailbox had received 95708 confirmed spams.
On the other hand, in the last week of October 2005, I had received an average of 419.42 spams per day. Take that number and scale it to a year: 153193 spams per year. That's 60% more than before!!!
Given, my mailbox might not be a "typical" one, since I've been using the same address for over a decade, and it's all over the place (for example, in several WHOIS records), and I will admit that the spam that actually makes it to my mailbox has declined — the various tools I use to filter my mail keep improving, and I give them a good tune-up once a year or so — but with these numbers, I really don't see how anyone could claim that spam itself is declining... yet. It's the anti-spam tools that are improving. Or maybe spam is getting easier to detect, because "we've seen it all" already? Of those 95708 spams, 97.4% scored above 99% on a Bayesian analysis. Combine this with a few other methods, and I rarely see more than a spam or two in my inbox. And I haven't ever had a single false positive (yes, I check them all... once in a while... which reminds me that I'm overdue...)
Oh, I forgot to mention that those numbers do not include any viruses that have been silently dropped by ClamAV before ever making it to SpamAssassin. Nowadays that includes some phishing spams too.
Oops. Sounds like it's been beat up a bit. The frontend is now apparently getting "connection refused" from the database.
And there I was 80% finished transcribing the full listing for easier browsing... The online interface is nice, but not so good for casual browsing of the entire list. Making a complete list available in a flat format (e.g. tab-delimited) might have been a good idea. I mean, it's not like I know what I'm looking for, I don't know the music of the era... But by browsing the titles, I can find those that look potentially interesting.
I believe sox can handle these good old VOC files, so you can convert them to a format that is more readily playable these days. I still have a bunch of those somewhere...
Now, if I could only find a way to convert the proprietary video format used by my SH501is phone into something I could actually use!
I'm surprised that no one has mentionned SANS yet.
A search for "forensics" on their home page brings up a list of many System Forensics tracks held at previous and upcoming conferences.
SANS training is not exactly affordable (unless your employer is paying!), but is well recognized and (in my experience) of excellent quality.
If for some reason you don't feel like rebooting just yet, a friend and I wrote a little kernel module which puts a wrapper around sys_brk() which should prevent this vulnerability from being exploited.
I'm no kernel guru, so if this breaks, you own the pieces... But it's fairly simple code.
I /wish/ I had that much bandwidth at home. Although I'm pretty comfortable with my home SDSL link, I'd rather run my bittorent downloads on a well-connected system... In the case of well-seeded torrents, the end result is actually a bit worse since I still have to download it home after, but OTOH, I usually get to contribute significantly more to the torrent.
"Again"? While it is ironic that I apparently _did_ make that mistake in my second comment, I believe that the first one was actually quite correct.
Yes, I really mean it! 2400 kb/s -- close to 20 megabits per second.
The system I was using for this transfer has 100 megabits per second of Internet transit connectivity (12.5MB/s), so it's not impossible. I often get around 800 kilobytes per second (6.4Mb/s) when using Bittorrent to download well-seeded, popular anime fansubs. My previous torrent speed record was 1300 kilobytes per second (10.4Mb/s).
Perhaps one or a few of the users that were seeding the kernel were topologically close to my system, or had similarly great connectivity...
[And, being lazy, I'm using kilobytes and megabytes here, not "kibibytes" or "mibibytes" -- or whatever it is we're now supposed to call 1024 bytes and 1048576 bytes..]
Wow! I got 2400 kB/s! I don't think I've ever downloaded kernel source that fast...
I was really hoping that someone would start a torrent -- actually, I was thinking of starting one myself if I didn't find one here...
<paranoia> ;->
Now, I still have to get the PGP signature from kernel.org since you didn't redistribute it, you know, just to make sure you didn't add anything funny to the kernel
</paranoia>
Still, thanks ^_^
rsync is fine when you have the bandwidth available, and when the time it takes to run the backup remains tolerable. However, unless you can write-lock the filesystem during the process, one interesting problem with a backup that takes a long time to run is that the backup copy represents a state that never really existed: the filesystem might have changed significantly while the backup was running.
My favorite solution to this is breaking 3-way mirrors; see my earlier comment about this (along with the informative replies). It gives you an instant, "checkpoint" backup of your drive.
Let's not forget of course that you can use a versionning filesystem (some Veritas products come to mind) to achieve a "checkpoint" state for your backups. These systems also usually include plenty of built-in backup strategies to answer your question... but we're talking about some bigger dollar signs here.
Ok, you can't get cash for it -- but, I don't know about this particular implementation, but unless the cards somehow authenticate the terminals/readers with a challenge/response protocol (in which case it would be hard to impersonate a reader to steal credits in the first place), perhaps you can simply store the tokens you stole ("long encrypted strings" as you called them) to retransmit them later to a legitimate reader? Hey, free transit! ^_^
Sure, this won't instantly make you rich, so the motivation isn't there as much... but if the protocol allows this, someone is bound to try it eventually!
That is rather sad. I actually like the banner ads on the index page! And I rarely load the index page more than 2~3 times in a given day (I set my index page to display as many articles as possible, and that usually covers a day), so in order to be eligible for the "plum" I would have to completely sacrifice seeing those ads?
I can't stand the bigger ads, which is why I became a subscriber in the first place. I love the banner ads at the top of the index page: it's the first thing on the page, I get to see it before I actually start reading anything, so it doesn't "interrupt" my thought processes. And at that point I will be quite willing to visit the site pointed to by the ad if I'm actually interested. But the big ads in the middle of the page really annoy me, and that's why I turn those off with my subscription.
I guess either (1) OSDN thinks that by enabling ads on the index page our credits would dry up faster, or (2) they want to encourage us to spend our credits on the index page and hope that we'll compensate by turning the big ads back on!
Too bad... given those terms, I guess I'll live without the "plums".
I would rather be concerned by unencrypted data exported from my network. I expect all corporate data transfers to be properly encrypted, to their designated recipients. You can't just start to block all encrypted traffic flowing out of a corporate network without seriously disrupting operations -- unless your system is smart enough to somehow recognize the particular kind of traffic you want to block.
Now let's hope that whoever implements the next generation of P2P software will be smart enough to use standard methods (e.g. SSH or SSL) to ensure that the encrypted P2P traffic can't easily be distinguished from "legitimate" uses of the network ;-)
Trying to filter P2P traffic may be a nice goal, but is technically hard to achieve. Once you've given someone access to an IP network, you can't really control what they are transmitting -- unless you control one of the endpoints. Else, anything can be tunnelled over anything (sometimes ASMOP). If bandwidth usage is your concern, graph user bandwidth usage and ask them to justify it in terms of job-related items. Don't try to consider a simple bandwidth abuse problem like it is another kind of problem just because it's P2P. KISS. If you're worried about sensitive corporate data that an employee may be transmitting out of your network, perhaps you should be worried about that USB keychain in his pocket too.
For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.
For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)
In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
Lucky you! Akihabara is heaven on earth for true geeks! You shouldn't have any problems shopping over there, the prices are well indicated (but sometimes you can try to get better bargain... politely ask "what is the discount price"). But learning just a bit of Japanese can make quite a difference -- e.g. how to formally introduce yourself, and politely ask if they speak English....
But even if you don't want to learn any Japanese per se, I would recommend learning a bit of "katakana".
In Japanese, three sets of symbols/alphabets are used. "Kanjis" are the most complicated, with each symbol representing one or more meanings and having one or more possible pronunciations. The two others, "hiragana" and "katakana" (collectively known as "kana"), are more simple, and represent sounds/syllabs.
Katakana is almost always used to write foreign words, most of them English. This means that if you can read katakana characters, chances are that you will be able to guess the meaning. This is especially true for technical material.
The first time I went to Japan, I spent about twenty hours studying katakana before going, and didn't regret it. Not only did it help me in my Anime and computer shopping, but also in understanding a lot of restaurant menus -- especially fast food ^_^ I think it's definitely worth it.
For a quick learning experience, I recommend Anne Matsumoto Stewart's "All About Katakana", ISBN 4770016964. It's quite cheap, and fun to boot :) Your favorite online bookstore should be able to ship it within a day or so, it's usually in stock.
Now for the _real_ fun, also learn "hiragana" and practice by reading the name of the train stations ;->
I read that 3ware stopped selling their Escalade controllers a few weeks ago. They now "focus" on their Palisade NASes... I just checked their web site, and even the announcement to that effect is already gone!
This is bad news. The Escalade controller was definitely my favorite for midrange applications. It is well supported in the Linux kernel, and presents a SCSI interface to your system while still using cheap IDE drives... My favorite server has an Escalade 6800 with four 40G HDs in a RAID 1-0 configuration, which means splitting read requests on four drives -- that's quite fast!
Has anybody tried the Adaptec AAR-2400A? It might be a good alternative...
In a mission-critical environment, it is possible to achieve a very high degree of system-redundancy by using hard drives as a backup solution by "breaking mirrors". (Of course if the system is mission-critical, I'd rather have a geographically distributed set of systems, but that's not always possible...)
The idea is that you setup hot-swappable disks in a three-way mirror, that is, three drives containing the exact same data. When you want/need to take a backup, you simply pull the third drive out of the array. The system still has two drive with the full data set, so you don't loose your redundancy. You insert another drive to replace the one you pulled, and in a matter of hours it will be in sync with the rest of the array. That sync time will depend on the size of the hard drives you use, but should be well under 24 hours for up to at least 40 gigs.
Of course, you need hot-swappable disk drives, and ideally a hardware RAID controller, and you might even want to consider having a disk for every day of the week, so that solution isn't exactly cheap. However, it gives you an instant snapshot of the system when you take your backup, and restoring is simply a matter of putting the backup drive in the machine (or another similar machine, if the first was damaged/lost). If you're paranoid (not to mention incredibly rich), you might even consider a four-way mirror to have two backups, and already have instant redundancy when you restore the system!
Another interesting thing to do is to use disk-level encryption in such a scenario. Since all your drives are encrypted, so are your backups. The problem with that is that you need to provide the key (passphrase or hardware token, or combination) at boot time, which means additional downtime if there's an unscheduled reboot and you're not around with the key...
Also, you might want to do things such as checkpointing your databases right before pulling the backup drive out in order to minimize the chance of data loss. But in the end, it can't be worse than an unexpected power down, and well-written applications and OSes deal with that pretty well. A logging filesystem will definitely help.
Interesting. Let's suppose that Alice has access to a trusted server located somewhere out of the FBI's jurisdiction/reach... And now let's suppose that she receives her e-mail (possibly encrypted) on that system, but reads it remotely from her PC in the US, using SSH to encrypt the communication. In such a situation, the PC is definitely used as a "communication device", and I guess the FBI would have to get an authorization to do a telecommunication interception in order to use a keylogger to grab her SSH key passphrase (or remote system password if not using a key)...
Of course this scenario requires a trusted server in a trusted location -- but that's not too hard to get...
Hmmm...
--
"Words have meaning, and names have power." --Lorien
Hmmm, I'm afraid you are off-track here. Encoding bitrate, usually in kilobits per second, actually describes how many bits you need to encode a second of audio. Therefore, it does indicate the amount of compression that you are achieving (over the original sample bitrate). For example, CD-quality uncompressed audio is 44.1Khz 16 bit stereo sampling, therefore approximately 1411 kilobits per second. If the encoding outputs a stream with a bitrate of 128 kilobits per second, you've achieved a compression ratio of a bit more than 10 to 1.
Why is the file size larger than MPEG Audio Layer III when it's using the same constant bit rate of 128 kb/s? Am I missing something here?
The japanese word for "idol" is usually written in katakana, one of japanese's two syllabic alphabets -- the one used to render foreign words, or sometimes to add emphasis to a word (the way we would use bold or italic characters). Unfortunately, I can't write katakana on Slashdot, but if you follow the usual conventions to write japanese using our alphabet, you would get 'A-I-DO-RU'. On the other hand, it really is pronounced "eye-doh-ru" -- again, with the "r" in the "ru" pronounced as a mix or "r" and "l"... e.g., they don't say "sayonala" nor "sayonara", but something in between.