My argument was that media does not have to be portable for companies to standardize on it. Valve still made lots of money, even if they did neglect non-Microsoft operating systems; the BBC will, like most companies, neglect the consideration of non-Microsoft platforms due to being ignorant to the existance of those platforms.
This isn't to say that they won't take platform compatability into consideration or that the choice they make won't play on your platform.. furthermore, it doesn't mean that support on your platform won't necessarily be made.. I'm only saying that I hope they DO choose a platform-independant medium.
But if the format is something unreadable and obscure like VIVO or something more evil, or locked via DRM.. why bother making it available at all if nobody can reasonably view it?
"Q: What size of QR Code can be read? A: Readability depends on the module size and operating environment, for example, if a module size is 0.5mm (19.7 mils) square, the readable QR Code size is 105 x 105 modules (52mm (2.0") square) or less."
It seems that you can print on arbitrary module sizes, but it's readability depends on the quality of the scanner.
Checkout 2D barcodes such as QR-code, DataMatrix, and MaxiCode: here
QR-code can store 2,953 bytes in a single code.. I'm not sure what the size of the code is, but looking at photographs of it shows that it is "damn'ed small".
There is certainly something sneakier one could do.. how about posting the content onto various free forums around the net and then pulling them from the google-cache?
Actually, I just bought one of those and it is pretty shitty. The cells are physically larger than those in Apple's pack which requires them to use a very thin and flexible casing. The top and bottom of the casing are made of plastic inserts which were already peeling off, exposing the battery, when I purchased the thing.
The advantage is that I have a new battery for only $150.. disadvantage is that I'm afraid of it blowing up.
Before XFree4.0, GGI+framebuffer (KGI or FBdev)+XGGI was the only solution free solution for multihead in Linux, and the ONLY solution for what is now Xinerama (continous display).
KGI is old hat.. I used it for Linux back in the days of Linux 2.2 when I was experimenting with dual-head X11 (Xinerama didn't exist yet).
There was a nasty skirmish on the lkml about whether to include KGI into the kernel or not. Linus rejected it and the Linux framebuffer you know now was included.
Doing a google, there IS a free HFS utility for Windows: http://gamma.nic.fi/~lpesonen/HFVExplore r/
This means that 2/3 operating systems (Linux and MacOS) can read the format natively, and one can do it with a free 3rd party utility.. not too shabby.
As others have said, ext2 can be read from all three but requires 3rd party utilities on MacOS X and Windows.. plus, you can't boot MacOS from ext2:)
I don't think it's being too unrealistic to expect that we will be able to manipulate matter at a subatomic level within a few hundred years, and when we do have that capability we can alter the waste so that it is harmless.
Assuming this is possible, and I believe it is.. I think it will happen before then, within the next 30 years... but it will require a nuclear process, and who knows what kind of waste there will be from that process.
I wouldn't say to use removable caddy.. hotswap with that is too expensive (and risky?). I think the story submitter had the right solution with the firewire/usb2 enclosure... although..
It might make some sense if he DID use samba, netatalk, and NFS.. as part of a portable NAS device... why doesn't someone make something like that?
Oh right, they do... it is a bit large, but I could imagine worse.
Thinking about it.. why couldn't he get get a laptop with a large harddrive and connect that via USB, firewire, or ethernet to the target machines? If the laptop's harddrive isn't large enough ehe can still use the external drive on the laptop for the extra storage. Apple laptops can act as firewire harddrives out of the box without modification.
What about staying on topic? It is very likely that the network is too slow for transfering 40 gigabytes with reasonable speed. If he is at work, he likely won't get financing for such a drastic change, the machines may be physically separated, there may be security reasons why they cannot be on the same network, etc.
Anyway, as I stated before.. UDF is the way to go if he can get writing to work; otherwise, FAT32 is the only solution.
The ipod is just a firewire external harddrive. It is bootable on the Mac because it uses HFS+ as the filesystem. Windows does NOT work with *that* ipod.
Apple has two ipod versions, one for MacOS and one for Windows. The one for Windows is formated with FAT32, whilst the Mac version uses HFS+.
I don't think MacOS can boot from the FAT32 version, but I could be mistaken.
There is read-only support for UDF on Windows XP/2000, Linux, and MacOS X. You might have trouble writing though without somehow telling MacOS and Windows that your harddrive is a CDR.
Linux supports ext*, fat*, iso9660 xfs, jfs, reiserfs, efs, isofs, ufs, udf (experimental), minix, VxFS, HPFS, HFS, HFS+ (limited?), QNX, ntfs (limited), BFS, Amiga FFS, ADFS, BeFS, and finally System V/Xenix/V7/Coherent FS (that is a long one!). MacOS 10.x supports HFS, HFS+, UDF, ISO9660, AFS, and FAT* Windows XP supports ISO9660, NTFS, FAT*, and UDF.
I believe that MacOS and Windows both require 3rd party software to use UDF.. but I could be wrong about that.
The solutions would be FAT*, ISO9660, and UDF. ISO9660 is read-only and I've never heard of someone using UDF on a harddrive (it is for those 'direct cds' you might have seen). FAT* sucks, but it works everywhere. It might be worth the effort to see if UDF could be used at all, but a small FAT32 partition would have to be made to accomodate the utilities for using it on the target system.
Before everyone flames the story submiter for being bias against Microsoft, the issue is that FAT really does suck and it would be great if there was something else that everyone supported.
Personally, I'd like to have a 6 gigabyte external (usb/firewire) harddrive that I could boot MacOS9 from AND share it between Linux and Windows computer. I guess I'll keep dreaming for a while:)
The truth is that if GCC dropped SCO support, it would be a large enough loss that SCO would very likely continue on a fork providing support for their OS.
Gkrellm cannot, for instance, provide an OSX-like dock like gdocklets and that KDE program can.
Of course X11 is X11 so I'm using the KDE program to get an OSX-like taskbar with a gnome panel and metacity. for a desktop that looks almost too much like OSX.
It might not be a bad idea to add a toggle switch to utilize the vertical wheel for horizontal movement. The vertical wheel would be much easier to control than a horizontally placed wheel.
The best thing about such an implementation would be that it can be done with modifications to the system's drivers. It could be possible to use the second button as a toggle.
Slashdot Mirror
My argument was that media does not have to be portable for companies to standardize on it. Valve still made lots of money, even if they did neglect non-Microsoft operating systems; the BBC will, like most companies, neglect the consideration of non-Microsoft platforms due to being ignorant to the existance of those platforms.
This isn't to say that they won't take platform compatability into consideration or that the choice they make won't play on your platform.. furthermore, it doesn't mean that support on your platform won't necessarily be made.. I'm only saying that I hope they DO choose a platform-independant medium.
"Logically, since they've said they'll release it, it will be viewable."
Yeah, but Valve said they are going to release HalfLife and it still isn't playable. It is playable from Windows, but hey.. not in Linux or MacOS.
Luckily, most video codecs are playable in Unix these days.
But if the format is something unreadable and obscure like VIVO or something more evil, or locked via DRM.. why bother making it available at all if nobody can reasonably view it?
"Q: What size of QR Code can be read?
A: Readability depends on the module size and operating environment, for example, if a module size is 0.5mm (19.7 mils) square, the readable QR Code size is 105 x 105 modules (52mm (2.0") square) or less."
It seems that you can print on arbitrary module sizes, but it's readability depends on the quality of the scanner.
Checkout 2D barcodes such as QR-code, DataMatrix, and MaxiCode:
here
QR-code can store 2,953 bytes in a single code.. I'm not sure what the size of the code is, but looking at photographs of it shows that it is "damn'ed small".
There is certainly something sneakier one could do.. how about posting the content onto various free forums around the net and then pulling them from the google-cache?
Yeah, Lombard batteries are hard to find....
Actually, I just bought one of those and it is pretty shitty. The cells are physically larger than those in Apple's pack which requires them to use a very thin and flexible casing. The top and bottom of the casing are made of plastic inserts which were already peeling off, exposing the battery, when I purchased the thing.
The advantage is that I have a new battery for only $150.. disadvantage is that I'm afraid of it blowing up.
Before XFree4.0, GGI+framebuffer (KGI or FBdev)+XGGI was the only solution free solution for multihead in Linux, and the ONLY solution for what is now Xinerama (continous display).
KGI is old hat.. I used it for Linux back in the days of Linux 2.2 when I was experimenting with dual-head X11 (Xinerama didn't exist yet).
There was a nasty skirmish on the lkml about whether to include KGI into the kernel or not. Linus rejected it and the Linux framebuffer you know now was included.
Ravage's Installer for Linux.
Doing a google, there IS a free HFS utility for Windows:e r/
:)
http://gamma.nic.fi/~lpesonen/HFVExplor
This means that 2/3 operating systems (Linux and MacOS) can read the format natively, and one can do it with a free 3rd party utility.. not too shabby.
As others have said, ext2 can be read from all three but requires 3rd party utilities on MacOS X and Windows.. plus, you can't boot MacOS from ext2
Having a central fileserver is a quite obvious idea and I doubt that the original poster would've asked if he hasn't considered it already.
As stated before, I'd think that having a portable fileserver would be a great idea.. but not a central one.
I don't think it's being too unrealistic to expect that we will be able to manipulate matter at a subatomic level within a few hundred years, and when we do have that capability we can alter the waste so that it is harmless.
Assuming this is possible, and I believe it is.. I think it will happen before then, within the next 30 years... but it will require a nuclear process, and who knows what kind of waste there will be from that process.
The world trade towers were also built to withstand being hit by a plane... look how that turned out.
I wouldn't say to use removable caddy.. hotswap with that is too expensive (and risky?). I think the story submitter had the right solution with the firewire/usb2 enclosure... although..
It might make some sense if he DID use samba, netatalk, and NFS.. as part of a portable NAS device... why doesn't someone make something like that?
Oh right, they do... it is a bit large, but I could imagine worse.
Thinking about it.. why couldn't he get get a laptop with a large harddrive and connect that via USB, firewire, or ethernet to the target machines? If the laptop's harddrive isn't large enough ehe can still use the external drive on the laptop for the extra storage. Apple laptops can act as firewire harddrives out of the box without modification.
What about staying on topic? It is very likely that the network is too slow for transfering 40 gigabytes with reasonable speed. If he is at work, he likely won't get financing for such a drastic change, the machines may be physically separated, there may be security reasons why they cannot be on the same network, etc.
Anyway, as I stated before.. UDF is the way to go if he can get writing to work; otherwise, FAT32 is the only solution.
The ipod is just a firewire external harddrive. It is bootable on the Mac because it uses HFS+ as the filesystem. Windows does NOT work with *that* ipod.
Apple has two ipod versions, one for MacOS and one for Windows. The one for Windows is formated with FAT32, whilst the Mac version uses HFS+.
I don't think MacOS can boot from the FAT32 version, but I could be mistaken.
There is read-only support for UDF on Windows XP/2000, Linux, and MacOS X. You might have trouble writing though without somehow telling MacOS and Windows that your harddrive is a CDR.
"I often need to move 40GB+ database dumps"
Does that answer your question?
Linux supports ext*, fat*, iso9660 xfs, jfs, reiserfs, efs, isofs, ufs, udf (experimental), minix, VxFS, HPFS, HFS, HFS+ (limited?), QNX, ntfs (limited), BFS, Amiga FFS, ADFS, BeFS, and finally System V/Xenix/V7/Coherent FS (that is a long one!).
:)
MacOS 10.x supports HFS, HFS+, UDF, ISO9660, AFS, and FAT*
Windows XP supports ISO9660, NTFS, FAT*, and UDF.
I believe that MacOS and Windows both require 3rd party software to use UDF.. but I could be wrong about that.
The solutions would be FAT*, ISO9660, and UDF. ISO9660 is read-only and I've never heard of someone using UDF on a harddrive (it is for those 'direct cds' you might have seen). FAT* sucks, but it works everywhere. It might be worth the effort to see if UDF could be used at all, but a small FAT32 partition would have to be made to accomodate the utilities for using it on the target system.
Before everyone flames the story submiter for being bias against Microsoft, the issue is that FAT really does suck and it would be great if there was something else that everyone supported.
Personally, I'd like to have a 6 gigabyte external (usb/firewire) harddrive that I could boot MacOS9 from AND share it between Linux and Windows computer. I guess I'll keep dreaming for a while
The truth is that if GCC dropped SCO support, it would be a large enough loss that SCO would very likely continue on a fork providing support for their OS.
Gkrellm cannot, for instance, provide an OSX-like dock like gdocklets and that KDE program can.
Of course X11 is X11 so I'm using the KDE program to get an OSX-like taskbar with a gnome panel and metacity. for a desktop that looks almost too much like OSX.
Exactly. Someone mod the parent up :)
It might not be a bad idea to add a toggle switch to
utilize the vertical wheel for horizontal movement. The vertical wheel would be much easier to control than a horizontally placed wheel.
The best thing about such an implementation would be that it can be done with modifications to the system's drivers. It could be possible to use the second button as a toggle.
pseudocode:
if mouse.button2 && mouse.button4:
mouse.button6=1
elif mouse.button2 && mouse.button5:
mouse.button7=1
In the gimp, you can hold the middle button (scroll wheel) down to get a 'panning' control. Helps, but a scroll wheel would be nice.