You are aware that the Japanese language has over 2000 kanji which you are expected to read if you are a japanese citizen? Add that to the problem that outside the large tourist areas english skills are pretty poor (compared to what you may be used to in eg Europe) and you may have serious problems understanding the menu in a restaurant.
When I was there I used an electronic dictionary quite a bit (though I have studied Japanese, if you haven't one of those is pretty useless). I think a simple PDA could help quite a bit. Particularly if it has a vocabulary which is sorted well so it is easy to find relevant words.
Personally I have never seen a "parlour book" that has done a decent job of helping you understand what the other guy is saying. (Even if you can make them understand your question.)
And a cheap Palm (monocrome) has good battery and isn't very expensive.
I find your notation a bit hard to grasp. I tried to invent my own but it seems like drawing pictures of it just makes it harder than just text. (I probably just haven't been clever enough to think of a picture though.)
If you first stripe and then mirror and one drive fails you have one partially failed subarray and one fully working subarray. If one of the drives in the fully working subarray fail the entire array fails as that subarray has the only working copy of the array. If the still working drive in the partially failed array fails then the array continues to work. In other words, there is a 1/3 chance that the "right" drive fails.
If you first mirror and then stripe the system and one drive fails you have two functional subarrays. Now if the lone drive in the damaged subarray fail the entire array fail. But if one of the disks in the fully operational subarray fails the array continues to work. Iow, there is a 2/3 chance that one of the "right" disks fail.
Well that's how I reasoned about it. Please feel free to point out any mistakes. I haven't considered any points about performance issues.
It sucks if you are on Windows and don't have a program which gives you virtual desktops. Install that and you can use GIMP a lot better. (And FYI I hate programs with MDI style interfaces since I typically work with multiple monitors.)
ALWAYS put RAID 1 on the lower level and then use RAID 0 to bunch these two devices together. Reason being if you do that your array has a 2/3 chance of surviving two HDD crashes at the same time.
For a lot of data this seems a bit redundant IMHO. There is a difference between data you can recreate but don't want to loose (ripped CDs etc) and data you can't recreate (documents, photos). Depending on your storage needs it may be redundant to put it all on the same type of array.
You know, I've always found it strange that so many in the US work on the side while they are going to college. It seems to me that if you can actually do that then you're not getting your moneys worth from your college.
Studying should be a full time occupation if you ask me. And during the first few years of college it sure was for me. Going to classes 8-5 each day didn't really leave much room for work on the side. (Though the Swedish system doesn't require you to either.)
And you sure can learn the stuff that they teach in schools on your own. Typically it will go a lot faster in school though.
Of course they didn't call their chips "GPU"s since nVidias marketing team hadn't invented the name yet. OTOH I think it is a pretty good name, at least today. (I'm not quite convinced that the GeForce 1 should be called GPU if you want a more technical term.)
And since it's "Graphical Processing Unit" pretty much anything that uses special chips to do graphic calculators have one. IMHO if it can't be used as a simple processor then it hasn't deserved the term GPU.
The genereal idea for AVRCP is really for it to be used when there already is a audio or video connection in place. Eg if you have headphones and listen to streamed audio you should be able to alter the volume/skip tracks etc directly from the headphones. (And any changes made on the sender should be communicated with the headphones.)
So it's not really a typical remote like you requested. (Though it could possibly be used as such.) OTOH the same idea of using hinting to pre-start the Bluetooth connection could be used as was suggested for the capacitors and UWB idea in this thread.
I haven't really tried to use the Bluetooth HID profile as a remote control so I'm not sure how severe the lag actually is.
Naturally this is a place were Zigbee may be better suited than Bluetooth. It seems from the article like they are already putting both technologies on one chip (same radio).
Even seen a WiFi keyboard? Bluetooth is a lot more than a cable replacing technology. Through Profiles it defines things up to Application Level in the OSI model.
They are not competing, just as Zigbee and Bluetooth are not really competing.
Since Bluetooth is always listening out for transmissions, it means that they can drain the batteries of whatever item in a short period of time. Incorrect, Bluetooth support several different power modes. Sleep being but one of them.
This, combined with the dropping of R&D on Bluetooth, have dashed my hopes that a new Bluetooth protocol to do UDP-style messages for remote control will ever happen.
I suppose now the race is on to see who can make the most incompatible Zigbee TVs, VCRs etc. Sony sure as hell won't want their TV remotes to magically work with JVC surround sound amplifiers. First off, the acclaimed dropped development of Bluetooth is not true and a misunderstanding of the issue. See other post (by me) in this thread.
Secondly, there is already a "remote" standard for Bluetooth. It is just quite new and not yet widely implemented. (Future version of eg mobile phones may support it though.) Finally you can already use a modern mobile phone as a keyboard to remote control a computer. (And not with the serial command hack, it's acting like a real input device.) Eg the Sony-Ericsson K700 has this feature (the profile is Human Input Device, Device aspect).
Zigbee may well find a niche, but I doubt mobile devices will be one (as it's slow even compared to Bluetooth and no assured interoperability).
Now I'll admin that radio theory isn't my specialty; but "legacy frequency hoppers"? Seems to me that most moderns systems (like WiFi) use frequency hopping.
And you claim that Bluetooth is useless for keyboards and mice, yet many seem to be using it just fine right now. (There is a significant lag at start up though, that is quite correct.) When in use there is no real issue with lag however.
Furthermore R&D on Bluetooth isn't ended. Ericsson (creator or Bluetooth) has disbanded their own team for developing Bluetooth; but that is because there are numerous other manufacturers of Bluetooth chipsets that do the work as well or better than they do it themselves. All future development on Bluetooth is done through the Bluetooth SIG and thus Ericsson don't need their own group exclusively (besides they have been making a lot of cut-backs lately).
Finally you claim that interoperability isn't needed. Personally I doubt than any competing technology will have a chance to be accepted if it doesn't ensure interoperability.
Personally I think Zigbee could be used as a replacement for the lower levels of Bluetooth (though future version of Bluetooth are quite a bit faster than current ones). I'm sure that there will be some uses for Zigbee, but it seems like the privacy/integrety issues in Zigbee are completely ignored.
Zigbee is a cable replacing technology, Bluetooth is far more than that. And regarding prices of components, well I'll believe the suggested prices for Zigbee when I see them.
This is basically what multicast promised, but due to infrastructure problems, has yet to deliver.
Even if you have multicast "swarming" techniques are still a big bonus. Combining swarming downloads and multicast allow you to "join" a multicast broadcast at any time and still get the entire file. This would be particularly useful if you use error coding like Swarmcast did as it allows you to begin assembling the beginning of the file independently of what parts you are getting. (That's a simplification naturally.)
It will be interesting to see if this will become popular right of the bat or if it will take a "SwarmTorrent" before the masses takes notice.
First off multicast is not in wide use, and it most likely will never be for IP4. With IP6 we have a bit of a head start and perhaps can use that to ensure that it is standard when new products are sold. The problem is that most network equipment doesn't support multicast and thus it is not useable IRL.
Besides, multicast doesn't really solve all your problems. Eg it ownly works in the basic way if all users begin their download at the same time. For other situations it is not as useful. To get around it you'd, again, have to use technology like SwarmCasting (see their old papers for how to apply it on multicast systems).
The big advantages with Windows infrastructure are the tools for managing lots of machines (eg: Group Policy) and the ease of integration.
Only if you haven't used Unix extensively. Compared to Windows managing multiple computers in Unix/Linux is trivial. You scripts don't care how many computers they connect to after all.
And managing things like AV/Firewall/WindowsUpdate is still not as streamlined as it can be on a Unix system.
It used to be that you could even read data from other programs in your Office files. It didn't clean out the memory properly before it was used apparently.
I believe it was Schneier who put up a topic about this were he listed a bunch of stuff he had seen in other peoples office docuemtns. (Stuff like WWW-sites they'd gone to and passwords.)
That's why you compress the XML data. Sure it is mentioned in that article but his comment is that zip is too CPU heavy and RAM intensive to be useful and that no-one uses it.
While XML has problems you can use a binary system, but then you just get a completely different set of problems. Perhaps it would be best to define data structures with XML and then compress that into a binary format. That way you could (at least in some ways) get the best of both worlds.
A straight binary format is bad though. You loose a lot of flexibility just to make it smaller and a little faster to parse. With XML you can trade size for speed with compression.
The basic issue is that it's a lot easier to get a binary format wrong. And debugging a binary format over eg network is just a bitch.
On the surface Linux and HURD are very similar. That's because most people don't ever interact directly with the kernel.
The entire idea with HURD though is quite a lot different from Linux (and other monolithic designs). The biggest one being that HURD uses user space for almost everything. Ultimately this gives the OS a lot more flexibility and stability.
On the whole I think that the design behind the HURD is a more interesting than other current OSes. I guess we'll just wait until it's gotten a bit further. (I do believe it's useful for basic server stuff though.)
The point of this board isn't to give users to-notch 3D performance, or even good performance. The idea is to make a card that is completely open and available on all platforms (not only software but also many different hardware platforms).
You are quite right about price/performance ratio though, but that isn't quite the idea here. Think outside the box.
An implementation by Swedish FOA (military/Security research) was demonstarated on Swedish TV the other day. That system used microphones on portable video cameras. You could have police/media covering an event and afterwards make a 3D model of the event.
In case of a gunshot the multiple cameras were used to pinpoint the gunner who could then be tracked until apprehended. (The point of this system was to prove that the guy arrested was the guy that shot.)
These systems are for use in situation with large crowds though. Eg in resonse to soccer hooligans or large demonstrations with violent demonstrators. It is not designed for permanent installation. (There isn't much problem with gun shots in Sweden.)
It's based on an FPGA. You know, those reprogrammable chips. So it is quite certain that it can be optimised. It may even herald the next coming of FPGAs (today they are mostly used at universities for playing and at big hardware companies for early prototyping).
Hell, I might get one of these cards just for the reason that it has a FPGA!
Re:If you don't want people looking at your pantie
on
7 Megapixel Camera Phone
·
· Score: 2, Informative
Besides that this is a troll I just thought I should point one thing out. In Japan (and many other countries I presume) a skirt is part of the school uniform. As such they don't really have the "option" of wearing one or not.
Slashdot Mirror
You are aware that the Japanese language has over 2000 kanji which you are expected to read if you are a japanese citizen? Add that to the problem that outside the large tourist areas english skills are pretty poor (compared to what you may be used to in eg Europe) and you may have serious problems understanding the menu in a restaurant.
When I was there I used an electronic dictionary quite a bit (though I have studied Japanese, if you haven't one of those is pretty useless). I think a simple PDA could help quite a bit. Particularly if it has a vocabulary which is sorted well so it is easy to find relevant words.
Personally I have never seen a "parlour book" that has done a decent job of helping you understand what the other guy is saying. (Even if you can make them understand your question.)
And a cheap Palm (monocrome) has good battery and isn't very expensive.
I find your notation a bit hard to grasp. I tried to invent my own but it seems like drawing pictures of it just makes it harder than just text. (I probably just haven't been clever enough to think of a picture though.)
If you first stripe and then mirror and one drive fails you have one partially failed subarray and one fully working subarray. If one of the drives in the fully working subarray fail the entire array fails as that subarray has the only working copy of the array. If the still working drive in the partially failed array fails then the array continues to work. In other words, there is a 1/3 chance that the "right" drive fails.
If you first mirror and then stripe the system and one drive fails you have two functional subarrays. Now if the lone drive in the damaged subarray fail the entire array fail. But if one of the disks in the fully operational subarray fails the array continues to work. Iow, there is a 2/3 chance that one of the "right" disks fail.
Well that's how I reasoned about it. Please feel free to point out any mistakes. I haven't considered any points about performance issues.
It sucks if you are on Windows and don't have a program which gives you virtual desktops. Install that and you can use GIMP a lot better. (And FYI I hate programs with MDI style interfaces since I typically work with multiple monitors.)
ALWAYS put RAID 1 on the lower level and then use RAID 0 to bunch these two devices together. Reason being if you do that your array has a 2/3 chance of surviving two HDD crashes at the same time.
For a lot of data this seems a bit redundant IMHO. There is a difference between data you can recreate but don't want to loose (ripped CDs etc) and data you can't recreate (documents, photos). Depending on your storage needs it may be redundant to put it all on the same type of array.
You know, I've always found it strange that so many in the US work on the side while they are going to college. It seems to me that if you can actually do that then you're not getting your moneys worth from your college.
Studying should be a full time occupation if you ask me. And during the first few years of college it sure was for me. Going to classes 8-5 each day didn't really leave much room for work on the side. (Though the Swedish system doesn't require you to either.)
And you sure can learn the stuff that they teach in schools on your own. Typically it will go a lot faster in school though.
Well it's Tom's Hardware guide, so what did you expect? Relevant conclusions?
Of course they didn't call their chips "GPU"s since nVidias marketing team hadn't invented the name yet. OTOH I think it is a pretty good name, at least today. (I'm not quite convinced that the GeForce 1 should be called GPU if you want a more technical term.)
And since it's "Graphical Processing Unit" pretty much anything that uses special chips to do graphic calculators have one. IMHO if it can't be used as a simple processor then it hasn't deserved the term GPU.
The genereal idea for AVRCP is really for it to be used when there already is a audio or video connection in place. Eg if you have headphones and listen to streamed audio you should be able to alter the volume/skip tracks etc directly from the headphones. (And any changes made on the sender should be communicated with the headphones.)
So it's not really a typical remote like you requested. (Though it could possibly be used as such.) OTOH the same idea of using hinting to pre-start the Bluetooth connection could be used as was suggested for the capacitors and UWB idea in this thread.
I haven't really tried to use the Bluetooth HID profile as a remote control so I'm not sure how severe the lag actually is.
Naturally this is a place were Zigbee may be better suited than Bluetooth. It seems from the article like they are already putting both technologies on one chip (same radio).
Even seen a WiFi keyboard? Bluetooth is a lot more than a cable replacing technology. Through Profiles it defines things up to Application Level in the OSI model.
They are not competing, just as Zigbee and Bluetooth are not really competing.
Since Bluetooth is always listening out for transmissions, it means that they can drain the batteries of whatever item in a short period of time.
Incorrect, Bluetooth support several different power modes. Sleep being but one of them.
This, combined with the dropping of R&D on Bluetooth, have dashed my hopes that a new Bluetooth protocol to do UDP-style messages for remote control will ever happen.
I suppose now the race is on to see who can make the most incompatible Zigbee TVs, VCRs etc. Sony sure as hell won't want their TV remotes to magically work with JVC surround sound amplifiers.
First off, the acclaimed dropped development of Bluetooth is not true and a misunderstanding of the issue. See other post (by me) in this thread.
Secondly, there is already a "remote" standard for Bluetooth. It is just quite new and not yet widely implemented. (Future version of eg mobile phones may support it though.) Finally you can already use a modern mobile phone as a keyboard to remote control a computer. (And not with the serial command hack, it's acting like a real input device.) Eg the Sony-Ericsson K700 has this feature (the profile is Human Input Device, Device aspect).
Zigbee may well find a niche, but I doubt mobile devices will be one (as it's slow even compared to Bluetooth and no assured interoperability).
Now I'll admin that radio theory isn't my specialty; but "legacy frequency hoppers"? Seems to me that most moderns systems (like WiFi) use frequency hopping.
And you claim that Bluetooth is useless for keyboards and mice, yet many seem to be using it just fine right now. (There is a significant lag at start up though, that is quite correct.) When in use there is no real issue with lag however.
Furthermore R&D on Bluetooth isn't ended. Ericsson (creator or Bluetooth) has disbanded their own team for developing Bluetooth; but that is because there are numerous other manufacturers of Bluetooth chipsets that do the work as well or better than they do it themselves. All future development on Bluetooth is done through the Bluetooth SIG and thus Ericsson don't need their own group exclusively (besides they have been making a lot of cut-backs lately).
Finally you claim that interoperability isn't needed. Personally I doubt than any competing technology will have a chance to be accepted if it doesn't ensure interoperability.
Personally I think Zigbee could be used as a replacement for the lower levels of Bluetooth (though future version of Bluetooth are quite a bit faster than current ones). I'm sure that there will be some uses for Zigbee, but it seems like the privacy/integrety issues in Zigbee are completely ignored.
Zigbee is a cable replacing technology, Bluetooth is far more than that. And regarding prices of components, well I'll believe the suggested prices for Zigbee when I see them.
To conclude, I believe your post is a troll.
Even if you have multicast "swarming" techniques are still a big bonus. Combining swarming downloads and multicast allow you to "join" a multicast broadcast at any time and still get the entire file. This would be particularly useful if you use error coding like Swarmcast did as it allows you to begin assembling the beginning of the file independently of what parts you are getting. (That's a simplification naturally.)
It will be interesting to see if this will become popular right of the bat or if it will take a "SwarmTorrent" before the masses takes notice.
First off multicast is not in wide use, and it most likely will never be for IP4. With IP6 we have a bit of a head start and perhaps can use that to ensure that it is standard when new products are sold. The problem is that most network equipment doesn't support multicast and thus it is not useable IRL.
Besides, multicast doesn't really solve all your problems. Eg it ownly works in the basic way if all users begin their download at the same time. For other situations it is not as useful. To get around it you'd, again, have to use technology like SwarmCasting (see their old papers for how to apply it on multicast systems).
Only if you haven't used Unix extensively. Compared to Windows managing multiple computers in Unix/Linux is trivial. You scripts don't care how many computers they connect to after all.
And managing things like AV/Firewall/WindowsUpdate is still not as streamlined as it can be on a Unix system.
It used to be that you could even read data from other programs in your Office files. It didn't clean out the memory properly before it was used apparently.
I believe it was Schneier who put up a topic about this were he listed a bunch of stuff he had seen in other peoples office docuemtns. (Stuff like WWW-sites they'd gone to and passwords.)
Ah, it wasn't quite clear from context. And quite a lot of other people made the suggestion in a serious manner later on.
That's why you compress the XML data. Sure it is mentioned in that article but his comment is that zip is too CPU heavy and RAM intensive to be useful and that no-one uses it.
While XML has problems you can use a binary system, but then you just get a completely different set of problems. Perhaps it would be best to define data structures with XML and then compress that into a binary format. That way you could (at least in some ways) get the best of both worlds.
A straight binary format is bad though. You loose a lot of flexibility just to make it smaller and a little faster to parse. With XML you can trade size for speed with compression.
The basic issue is that it's a lot easier to get a binary format wrong. And debugging a binary format over eg network is just a bitch.
The lag for a DNS change can be several hours, 12+ hours is standard to wait for a change to take effect. Not particularly useful if you ask me.
Torrents are good for big files. There are extremely unsuited for something like RSS-feeds.
On the surface Linux and HURD are very similar. That's because most people don't ever interact directly with the kernel.
The entire idea with HURD though is quite a lot different from Linux (and other monolithic designs). The biggest one being that HURD uses user space for almost everything. Ultimately this gives the OS a lot more flexibility and stability.
On the whole I think that the design behind the HURD is a more interesting than other current OSes. I guess we'll just wait until it's gotten a bit further. (I do believe it's useful for basic server stuff though.)
The point of this board isn't to give users to-notch 3D performance, or even good performance. The idea is to make a card that is completely open and available on all platforms (not only software but also many different hardware platforms).
You are quite right about price/performance ratio though, but that isn't quite the idea here. Think outside the box.
An implementation by Swedish FOA (military/Security research) was demonstarated on Swedish TV the other day. That system used microphones on portable video cameras. You could have police/media covering an event and afterwards make a 3D model of the event.
In case of a gunshot the multiple cameras were used to pinpoint the gunner who could then be tracked until apprehended. (The point of this system was to prove that the guy arrested was the guy that shot.)
These systems are for use in situation with large crowds though. Eg in resonse to soccer hooligans or large demonstrations with violent demonstrators. It is not designed for permanent installation. (There isn't much problem with gun shots in Sweden.)
It's based on an FPGA. You know, those reprogrammable chips. So it is quite certain that it can be optimised. It may even herald the next coming of FPGAs (today they are mostly used at universities for playing and at big hardware companies for early prototyping).
Hell, I might get one of these cards just for the reason that it has a FPGA!
Besides that this is a troll I just thought I should point one thing out. In Japan (and many other countries I presume) a skirt is part of the school uniform. As such they don't really have the "option" of wearing one or not.