Creating THOMAS links in the past was ridiculously complex. You essentially had to craft a search query that would go directly to the document you wanted to like. E.G. http://thomas.loc.gov/cgi-bin/query/z?c107:H.R.3162.enr:.
Whereas if you tried to use the link from THOMAS' search results, you would get something like http://thomas.loc.gov/cgi-bin/query/D?c107:15:./temp/~c107zRB7G3::. Of course, this link is time limited and it isn't at all clear how you would construct the permanent link.
If your kids are not making passing grades then they are not learning. Lowering the bar does not lead to learning. You are doing those kids, and society, a great injustice by not allowing them to fail.
"The redundant data in the PAR files is computed using Reed-Solomon codes. These codes can take a set of equal-sized blocks of data and produce a number of same-sized recovery blocks. Then, given a subset of original data blocks and some recovery block, it is possible to reproduce the original data blocks. Reed-Solomon codes can do this recovery as long as the number of missing data blocks does not out number the recovery blocks. The design of the Reed-Solomon codes in this spec is based on James S. Plank's tech report at U. of Tennessee entitled A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems. The tech report contains an error, so the design is changed slightly to fix the problem. PAR 2.0 uses a 16-bit Reed-Solomon code and can support 32768 blocks."
No disagreement there, but it doesn't hurt to remind people that OS X is not that. People often leave Linux for OS X, claiming that it's basically an easier-to-use Linux than Linux, you still have all your stuff, etc. And you can always ssh to a Linux server to do real work.
How about some examples of "real work" that can't be done in OS X's shell? Admittedly, I don't so as much via the command line in OS X as I did when using Linux for a desktop OS, but I haven't encountered anything preventing me from doing so. I can't attest to OS X's server version; I don't use it. I, like you mentioned, moved to OS X as a desktop Unix because it is easier to maintain. Instead of spending time keeping the underlying system in order, I can work in a cohesive GUI desktop environment with the comforting option of being able to fall back on traditional Unix technologies. E.g. I can run Xmaxima, or vanilla maxima, if I so choose. In the three years I've been using OS X as my primary OS, I haven't had to "ssh to a Linux server to do real work."
Oh! if only I had mod points to mod this funny. You hit the nail right on the head, sir.
For those of you that don't get the sarcasm so think in the post: he is describing the situation of Mozilla and Phoenix (now Firefox). Except, Firefox has become just as bloated as the browser it was written to replace.
I'm not sure what sport you're talking about. All game one of the 2007 World Series was missing from your list is a cold temperature, and that is because it was unusually warm in Boston. Well, I assume it was unusually warm. I doubt Boston is normally 70 degrees on October 24.
I probably will. I have a 360 with a hard drive but no HDMI port. The price is low enough that I am considering buying the "Arcade" package, swapping it for my current base unit, and selling the old one. I figure I can get at least $100 for a brand new wireless controller, 256MB memory card, and old main unit.
I've mostly tried to do it when backing up my data. I would boot with SysRescueCD, mount a share on my Windows XP machine (NTFS there), and write a tar file to it. Every time I've tried to do that the transfer quit at 2GB. Since every file system in that scenario supports large files, I assume the problem is with the transfer protocol. Using netcat to do the same thing works just fine.
Why can't iStumbler see my network?
iStumbler scans by sending out probe packets via an Apple interface Access Points MAY respond to these probes but they might also be configured as private networks. iStumbler can now see any network you are connected to, if it's responding to probes or not. iStumbler is intended to find publicly available wireless. Making your network private is the equivalent of putting up a "No Trespassing" sign and the tool respects that.
KisMAC puts a wireless card in monitor mode to discover private networks. iStumbler only finds networks you are currently connected to and networks that announce their presence. It is not a sufficient replacement for KisMAC.
Create the NTFS partition on Windows then. You run Windows as well, right?
Yes, I could create the NTFS partition with my Windows machine. But I'm not always near that machine. I do most of my work on my Mac (a PowerBook). So most of the data to be shared amongst the machines will originate there; thus, I would much rather be able to create the file system with the Mac.
NTFS-3G is known as write safe. For a long time.
From the NTFS-3G FAQ:
Why does chkdsk report "minor inconsistency"?
The allocation size of some sparse files are sometimes incorrect.
Workaround: No need.
Status: Priority work.
That means the driver isn't 100% correct at writing to an NTFS formatted partition. Therefore, it can't be considered completely safe.
Too bad for you, then. Contribute to the NTFS-3G developers by code and/or cash and/or bounties. If you can afford a Mac...
You assume too much. My Linux and Windows machines are old, purchased several years ago. The Mac is over two years old. It was purchased with a student loan. It's main function is schoolwork. But, I do use it for many other things. Point being, it isn't paid for, I'm a student, and I don't have spare cash/time to contribute to, or start, a project. I would love to do so; it just isn't feasible for me at this time.
See above; FUD. The userspace NTFS driver via FUSE (NTFS-3G) is known to be write-safe.
See above justification. I didn't say they will cause corruption. I said they can cause corruption. You can't argue that a reverse engineered driver is as safe as the native driver. Not when the driver's own FAQ lists at least one known problem with the driver.
Ext2 drivers (the 2 most known Windows ones) are also known as write safe. For a long time as well. Ext3 is simply Ext2 + journaling. Journaling is not supported however the drivers do respect journaling logs. This means that if there are entries in your journal (ie. due to unclean unmount) the Windows driver will not support journaling however your FS will remain consistent. No big deal I'd say.
Why did you even write that paragraph? I said the ext2 driver for Windows is write safe. Ext2 is an open file system. If the person porting the driver is competent enough, there shouldn't be much of a problem.
I fail to see how creating Ext2/Ext3 on Windows or MacOSX matters. Surely you do have a Linux machine?
For the same reason I feel it is necessary to be able to create the NTFS partition from either machine. The purpose of the removable, read/write from any OS (Windows, Linux, and OS X in this case), disk is convenience.
FAT32 is no solution. Yes it is ancient and well supported, but it doesn't have journaling or softupdates. Which means you don't want to run it on a large partition or harddisk. Would you enjoy doing that on a 500 GB HDD? You argue you don't like data loss and such, wish to be pedantic about being able to create FS on any of your 3 OSes, yet you don't mind long (and not always consistent) fsck/scandisk? Strange.
Actually, I'm not currently using a removable disk in this scenario. I dislike FAT32 as much as you. The fact that it is the easiest solution negates the whole purpose for me. It's highly inconvenient, but I've been using SAMBA and FTP to transfer files between my machines.
I was unaware of UFS support for Windows. I'll certainly look into that now.
Have you tried to use NTFS in OS X? I tried to use it via MacFUSE before opting to install the ext2 driver. If I recall correctly, once I managed to get everything installed (there isn't a single "install this and go" package) I learned that actually creating the NTFS partition isn't possible. Evidently, all it can do is read and, possibly, write to an existing NTFS file system. That's no good.
Then there is the fact that third party NTFS drivers can cause corruption. FAT, despite its file size limitation, is pretty darn stable and has native support on all three platforms.
Since writing my previous post, I realized that I have looked at using UDF. Even if you manage to get the disk formatted to UDF, OS X will only read the file system; it won't write to the file system. Same for Windows XP. Thus, UDF is scratched off the list.
When I said "viable" I meant this: the file system must be easy to work with on all three platforms. It must at least be able to be read and written to without (too much) fear of corruption. Being able to create the file system, no matter which OS is being used, is also necessary. After FAT, ext2 comes closest. Clearly it is well supported in Linux. The OS X driver does all of those things, but it causes kernel panics (definitely not acceptable). I'm not sure, but I think the Ext2-IFS driver for Windows supports creation; it definitely supports reading and writing.
Because it doesn't work. The ext2 driver for OS X is _VERY_ unstable. The last time I tried it, about five months ago, the driver caused a kernel panic. After rebooting, OS X wouldn't read the drive anymore. It was unable to seek the disk. I thought it had caused a head crash until I hooked it up to a Mac without the driver installed; that one was able to see the disk and format it. Needless to say, I removed the ext2 driver.
FAT is really the only viable option at the moment. The problem there is that you will be limited to files 2GB in size. Have a DVD image you want to access from all three platforms? Forget it. You'll either have to burn it to a DVD or use FTP, because SAMBA is limited by the same 2GB limit.
Someone else posted a response about using UDF. I'll have to look into that, but I'm not sure OS X or Windows will format a hard drive to UDF. Well, at least not with OS X's "Disk Utility" application.
Agreed. There is not nearly as much quality freeware for Windows as there is for OS X. Also, I find that applications worth buying for OS X are much cheaper than similar applications for Windows.
Of course, neither operating system has as much of a selection of freeware as Linux.
There isn't a special "HD connection". The signal comes across the same coax that analog cable does. I don't have a Comcast set-top box (nor anyone else's) but I imagine it just sits between the wall and the receiving device. The box decodes the encrypted digital signals (and provides access to the higher channels) and sends them on to said receiving device. At least, that is what I assume.
Now, if you have a device that has a CableCARD, that is a different story. If you have a CableCARD device, you shouldn't have to have the intermediate set-top box.
--------------
Of course, I didn't look at the image you linked until after I wrote all that. I see what you mean now. The box seems to only offer component or DVI out. That does make things a bit tricky. I guess you would have to have a CableCARD device if you want to be able to record the HD feed from Comcast. That really sucks. Maybe you're right, though. Maybe the firewire connection would make it possible to export the stream to a PC. But, I doubt it.
I would rather have a box like I was assuming before the break. I wouldn't want that TiVo impersonation box.
I imagine you could use a HD-5500 to do it. It supports unencrypted QAM signals. If you put the box behind your Comcast box, I assume it would get the QAM signals unencrypted (the set-top box should be decrypting the channels based on your subscription level).
According to http://www.hdtvprimer.com/ISSUES/hints.html, that isn't entirely true. The analog signal doesn't necessarily give you any indication as to how well you receive the digital signal.:
Picture quality
The image quality is not affected at all by a low to moderate level of noise in the signal. This is true for both satellite and OTA DTV. Yet some people can't resist wondering "could I improve the image by improving the signal strength?" The answer is NO!
When the signal becomes too weak, you will see "macro-block errors" (parts of the screen that are shifted or obviously wrong), sound dropouts lasting a few seconds, or image freezes lasting a few seconds. All of these errors are crude, unsubtle errors. If these are not present, your image is perfect.
If your image is perfect, there is still one reason you might want to improve the signal: It would make dropouts less likely in bad conditions, such as heavy rain. Rain can affect DBS and UHF reception, but not VHF. In some places, wind can affect UHF.
(If you get sound dropouts but not image dropouts, or visa versa, then the fault is not a reception problem. Usually the station is at fault, but occasionally it is the STB.)
If you would like to figure out what DT signals are available in your area, a good starting point is AntennaWeb. You can enter your street address and it will return a list of OTA signals you should be able to receive (analog and DT).
Slashdot Mirror
Creating THOMAS links in the past was ridiculously complex. You essentially had to craft a search query that would go directly to the document you wanted to like. E.G. http://thomas.loc.gov/cgi-bin/query/z?c107:H.R.3162.enr:.
Whereas if you tried to use the link from THOMAS' search results, you would get something like http://thomas.loc.gov/cgi-bin/query/D?c107:15:./temp/~c107zRB7G3::. Of course, this link is time limited and it isn't at all clear how you would construct the permanent link.
http://hdl.loc.gov/loc.uscongress/legislation.107hr3162 is much easier to construct and is somewhat clear. Now if only they would provide the link in the THOMAS search results.
If your kids are not making passing grades then they are not learning. Lowering the bar does not lead to learning. You are doing those kids, and society, a great injustice by not allowing them to fail.
I hope you are joking. PAR2 is nothing more than an implementation of RS codes. So how can RS codes be ancient compared to PAR2?
From the PAR2 specification introduction:
"The redundant data in the PAR files is computed using Reed-Solomon codes. These codes can take a set of equal-sized blocks of data and produce a number of same-sized recovery blocks. Then, given a subset of original data blocks and some recovery block, it is possible to reproduce the original data blocks. Reed-Solomon codes can do this recovery as long as the number of missing data blocks does not out number the recovery blocks. The design of the Reed-Solomon codes in this spec is based on James S. Plank's tech report at U. of Tennessee entitled A tutorial on Reed-Solomon coding for fault-tolerance in RAID-like systems. The tech report contains an error, so the design is changed slightly to fix the problem. PAR 2.0 uses a 16-bit Reed-Solomon code and can support 32768 blocks."
How about some examples of "real work" that can't be done in OS X's shell? Admittedly, I don't so as much via the command line in OS X as I did when using Linux for a desktop OS, but I haven't encountered anything preventing me from doing so. I can't attest to OS X's server version; I don't use it. I, like you mentioned, moved to OS X as a desktop Unix because it is easier to maintain. Instead of spending time keeping the underlying system in order, I can work in a cohesive GUI desktop environment with the comforting option of being able to fall back on traditional Unix technologies. E.g. I can run Xmaxima, or vanilla maxima, if I so choose. In the three years I've been using OS X as my primary OS, I haven't had to "ssh to a Linux server to do real work."
Damn it. "so think" = "so thick"
Proofreading? pffff!
Oh! if only I had mod points to mod this funny. You hit the nail right on the head, sir.
For those of you that don't get the sarcasm so think in the post: he is describing the situation of Mozilla and Phoenix (now Firefox). Except, Firefox has become just as bloated as the browser it was written to replace.
I'm not sure what sport you're talking about. All game one of the 2007 World Series was missing from your list is a cold temperature, and that is because it was unusually warm in Boston. Well, I assume it was unusually warm. I doubt Boston is normally 70 degrees on October 24.
I probably will. I have a 360 with a hard drive but no HDMI port. The price is low enough that I am considering buying the "Arcade" package, swapping it for my current base unit, and selling the old one. I figure I can get at least $100 for a brand new wireless controller, 256MB memory card, and old main unit.
I've mostly tried to do it when backing up my data. I would boot with SysRescueCD, mount a share on my Windows XP machine (NTFS there), and write a tar file to it. Every time I've tried to do that the transfer quit at 2GB. Since every file system in that scenario supports large files, I assume the problem is with the transfer protocol. Using netcat to do the same thing works just fine.
I have never been able to transfer a file via samba that exceeds 2GB.
The only thing I can figure is that I didn't read your second sentence before replying.
No. From iStumbler's FAQ:
KisMAC puts a wireless card in monitor mode to discover private networks. iStumbler only finds networks you are currently connected to and networks that announce their presence. It is not a sufficient replacement for KisMAC.
Ext3 is merely ext2 with journaling support. Any ext2 implementation can read and write to an ext3 formatted partition. See http://en.wikipedia.org/wiki/Ext3#Advantages .
I wasn't aware of it. LuSiDe mentioned it in a second reply. I will be looking into using it.
Yes, I could create the NTFS partition with my Windows machine. But I'm not always near that machine. I do most of my work on my Mac (a PowerBook). So most of the data to be shared amongst the machines will originate there; thus, I would much rather be able to create the file system with the Mac.
NTFS-3G is known as write safe. For a long time.From the NTFS-3G FAQ:
That means the driver isn't 100% correct at writing to an NTFS formatted partition. Therefore, it can't be considered completely safe.
Too bad for you, then. Contribute to the NTFS-3G developers by code and/or cash and/or bounties. If you can afford a Mac...You assume too much. My Linux and Windows machines are old, purchased several years ago. The Mac is over two years old. It was purchased with a student loan. It's main function is schoolwork. But, I do use it for many other things. Point being, it isn't paid for, I'm a student, and I don't have spare cash/time to contribute to, or start, a project. I would love to do so; it just isn't feasible for me at this time.
See above; FUD. The userspace NTFS driver via FUSE (NTFS-3G) is known to be write-safe.See above justification. I didn't say they will cause corruption. I said they can cause corruption. You can't argue that a reverse engineered driver is as safe as the native driver. Not when the driver's own FAQ lists at least one known problem with the driver.
Ext2 drivers (the 2 most known Windows ones) are also known as write safe. For a long time as well. Ext3 is simply Ext2 + journaling. Journaling is not supported however the drivers do respect journaling logs. This means that if there are entries in your journal (ie. due to unclean unmount) the Windows driver will not support journaling however your FS will remain consistent. No big deal I'd say.Why did you even write that paragraph? I said the ext2 driver for Windows is write safe. Ext2 is an open file system. If the person porting the driver is competent enough, there shouldn't be much of a problem.
I fail to see how creating Ext2/Ext3 on Windows or MacOSX matters. Surely you do have a Linux machine?For the same reason I feel it is necessary to be able to create the NTFS partition from either machine. The purpose of the removable, read/write from any OS (Windows, Linux, and OS X in this case), disk is convenience.
FAT32 is no solution. Yes it is ancient and well supported, but it doesn't have journaling or softupdates. Which means you don't want to run it on a large partition or harddisk. Would you enjoy doing that on a 500 GB HDD? You argue you don't like data loss and such, wish to be pedantic about being able to create FS on any of your 3 OSes, yet you don't mind long (and not always consistent) fsck/scandisk? Strange.Actually, I'm not currently using a removable disk in this scenario. I dislike FAT32 as much as you. The fact that it is the easiest solution negates the whole purpose for me. It's highly inconvenient, but I've been using SAMBA and FTP to transfer files between my machines.
I was unaware of UFS support for Windows. I'll certainly look into that now.
Have you tried to use NTFS in OS X? I tried to use it via MacFUSE before opting to install the ext2 driver. If I recall correctly, once I managed to get everything installed (there isn't a single "install this and go" package) I learned that actually creating the NTFS partition isn't possible. Evidently, all it can do is read and, possibly, write to an existing NTFS file system. That's no good.
Then there is the fact that third party NTFS drivers can cause corruption. FAT, despite its file size limitation, is pretty darn stable and has native support on all three platforms.
Since writing my previous post, I realized that I have looked at using UDF. Even if you manage to get the disk formatted to UDF, OS X will only read the file system; it won't write to the file system. Same for Windows XP. Thus, UDF is scratched off the list.
When I said "viable" I meant this: the file system must be easy to work with on all three platforms. It must at least be able to be read and written to without (too much) fear of corruption. Being able to create the file system, no matter which OS is being used, is also necessary. After FAT, ext2 comes closest. Clearly it is well supported in Linux. The OS X driver does all of those things, but it causes kernel panics (definitely not acceptable). I'm not sure, but I think the Ext2-IFS driver for Windows supports creation; it definitely supports reading and writing.
Because it doesn't work. The ext2 driver for OS X is _VERY_ unstable. The last time I tried it, about five months ago, the driver caused a kernel panic. After rebooting, OS X wouldn't read the drive anymore. It was unable to seek the disk. I thought it had caused a head crash until I hooked it up to a Mac without the driver installed; that one was able to see the disk and format it. Needless to say, I removed the ext2 driver.
FAT is really the only viable option at the moment. The problem there is that you will be limited to files 2GB in size. Have a DVD image you want to access from all three platforms? Forget it. You'll either have to burn it to a DVD or use FTP, because SAMBA is limited by the same 2GB limit.
Someone else posted a response about using UDF. I'll have to look into that, but I'm not sure OS X or Windows will format a hard drive to UDF. Well, at least not with OS X's "Disk Utility" application.
Precedent: an earlier event or action that is regarded as an example or guide to be considered in subsequent similar circumstances.
In this case, see:
http://en.wikipedia.org/wiki/American_Civil_War
Agreed. There is not nearly as much quality freeware for Windows as there is for OS X. Also, I find that applications worth buying for OS X are much cheaper than similar applications for Windows.
Of course, neither operating system has as much of a selection of freeware as Linux.
Thank you. I was going to post this if someone else had not already.
http://games.slashdot.org/games/03/05/28/2329209.s html?tid=127&tid=186
"Windows users".
There isn't a special "HD connection". The signal comes across the same coax that analog cable does. I don't have a Comcast set-top box (nor anyone else's) but I imagine it just sits between the wall and the receiving device. The box decodes the encrypted digital signals (and provides access to the higher channels) and sends them on to said receiving device. At least, that is what I assume.
Now, if you have a device that has a CableCARD, that is a different story. If you have a CableCARD device, you shouldn't have to have the intermediate set-top box.
--------------
Of course, I didn't look at the image you linked until after I wrote all that. I see what you mean now. The box seems to only offer component or DVI out. That does make things a bit tricky. I guess you would have to have a CableCARD device if you want to be able to record the HD feed from Comcast. That really sucks. Maybe you're right, though. Maybe the firewire connection would make it possible to export the stream to a PC. But, I doubt it.
I would rather have a box like I was assuming before the break. I wouldn't want that TiVo impersonation box.
I imagine you could use a HD-5500 to do it. It supports unencrypted QAM signals. If you put the box behind your Comcast box, I assume it would get the QAM signals unencrypted (the set-top box should be decrypting the channels based on your subscription level).
According to http://www.hdtvprimer.com/ISSUES/hints.html, that isn't entirely true. The analog signal doesn't necessarily give you any indication as to how well you receive the digital signal.:
If you would like to figure out what DT signals are available in your area, a good starting point is AntennaWeb. You can enter your street address and it will return a list of OTA signals you should be able to receive (analog and DT).