I wrote a Type 1 MICR font (GnuMICR) by hand, as far as I know, the only freely available MICR font out there, and licensed it under the GPL. (Postscript is a language, my font is a "program", IMHO).
I had a request from a guy who wanted to do a closed-source check printing program, and wanted to use my font. I told him that I would license it to him for a fee, but that he could not use it under the GPL if he hard-coded the font into his application. i.e., his application WOULD NOT WORK without my font. If he had made a font selection dialog, and happened to distribute my font with his program as one option, then that would probably have been fine by me.
For kicks, though, I asked the GPL newsgroup, and none other than Linus responded that he thought they were in the clear if they wanted to bundle my font with their app. I didn't really pursue it much further...
In any case, this DLL linking is probably more clear cut, and I think it's most likely a violation. But whenever you get interactions between GPL and non-GPL'd code, it gets tricky.
I thought the RBL was so that you could configure your network to not accept MAIL from the offending hosts.
But the other IP blocked was www.macromedia.com, which is of course their Web address. Blocking this address, I would assume, stops no spam from reaching anyone's inbox.
That's only true if mail never comes from www.macromedia.com, which is an assumption on your part.
It seems possible that "spam" was sent out from the host "www.macromedia.com" and as such, that machine was also in the RBL.
But if you're using the RBL to block ALL traffic from those hosts, then that's your problem, right? That's not what the RBL was designed for. If "www.macromedia.com" made the list, then sysadmins who choose to use the RBL will not accept mail from www.macromedia.com.
But that shouldn't mean that HTTP traffic is shut off.
I've heard that he writes gospel music, and he likes the idea of being able to distribute it sans Mega-Corporations.
Interesting intersection between the religious right and the hackers, eh?
At the same time, while I feel that the Right (hell, the Left too) has forsaken the normal citizen for corporate interests, it's interesting to see that when a legislator is directly, adversely affected by a corporate interest, all of a sudden they sing a different tune. So to speak.:)
I mean, if you told me that Orrin Hatch was on the Napster side of the online music distribution argument, I'd think you were nuts - if I didn't know that he had personal reasons to snub the RIAA.
You would think that if your friendly Town Hall was going to hire someone to write their laws, they would AT LEAST insist that the resulting document belong to the City, and not to the legal firm.
If it's copyrighted, there are probably terms of use - I'd like to see what those are...
"Where are we going, and why are we in this handbasket?"
But do it nicely. Try not to sound like a raving lunatic.
Talking points:
Much of the data, and the interface, were at one point publicly available, so they can claim no proprietary rights.
You would be willing to support them if they offered better service than competitors, but these attacks on competitors make you have serious doubts about continuing to use their services.
I can't help but feel that that much code is going to have -some- impact on the rest of the system.
Although XFS is big, it doesn't stomp on the kernel that much.
If you're looking at it from a pure "volume of code" point of view, here's some info:
The XFS patches are split into 2 parts, one which contains kernel changes, and one which is the filesystem itself.
The "core-kernel" patch is about 190k, while the actual filesystem code patch is about 4.3M.
Bear in mind that a 190k patch to the kernel does not mean 190k of new code, either, since you have to take out the context lines, the headers, and the delete lines.
Overall, the impact on the kernel isn't as big as you might think, looking at the overall size.
Now, whether or not executing code in the filesystem slows down the rest of the system, I don't have any real data on that, although I have not noticed any detrimental effect on my system.
So one can only patch a stock Linus kernel with XFS?
You can patch whatever you want, it's a question of how many conflicts you need to resolve.:) As with any patch, you will have varying success patching source trees that differ from that which was used to generate the patch.
What about the Red Hat 7.1 kernel? Would be nice if there was a patch for that.
ftp://linux-xfs.sgi.com/projects/xfs/download/Re le ase-1.0/patches/RHlinux-2.4.2-core-xfs-1.0.patch.g z
It's certainly a priority, but I can't really give you a timeline - we're working on it.
XFS is so big and touches so much
XFS is big, no getting around that, but we're making efforts to keep our modifications in the kernel to a minimum (actually, a lot of that work is done already). The patch is also now split into 2 pieces, one for "core linux" changes and one for the filesystem itself. That was done for a couple of reasons, but a nice side effect is that it's a little easier to see how much is XFS itself, and how much is linux changes.
Re:Mime types built into the file system?
on
XFS 1.0 is Released
·
· Score: 2
XFS features extended attributes, so you could use this for mime types, I suppose. Any application would need to be aware of this, though, and would need to support it as well. Interesting idea though...
Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?
No, sorry.:) that'd be quite an undertaking. You can dump/restore between filesystems, or just copy over, but there is no magic "ext2 to xfs converter."
We have a system installer that works with Red Hat 7.1 to do exactly what you're asking about. Grab our iso, burn a cd, boot from it, and you're on your way. You'll need the Red Hat 7.1 cds as well.
The other option, of course, is to have lots of extra space, install your distro, boot an XFS capable kernel, make some XFS filesystems, and copy everything over.
A lot of people have been complaining that there is no 2.4.4 patch - but bear in mind that 2.4.4 is only 3 days old. We'd be a bit nuts to release 1.0 on a kernel as untested as that.
On the other hand, the devel cvs tree is usually updated within a few days of a new kernel release. As soon as the kinks get out of XFS+2.4.4, it'll be in the devel cvs tree.
The majority of our 1.0 testing has been done on 2.4.2, so we have the most confidence in XFS there. We also have a 2.4.3 patch which should be fine, although it has not had as much direct testing.
We realize that there are issues with 2.4.2 (loop device, anyone?) If you're concerned about fix-ups, and you run an RPM-based systems, you might take a look at the Red Hat kernel RPMs we offer - those include a ton of patches from Red Hat - essentially the same kernel as shipped with 7.1, with XFS added.
If you're concerned about netfilter, just get the patch - I would be very surprised if it conflicted in any way with an XFS-enabled kernel.
test-2, test-3, and 1.0 have been released since then, and that includes an acl fix. Without knowing for sure what your problem is, hard to say for sure if your specific problem has been resolved...
At this point, SGI has only provided an unsupported Red Hat system installer for XFS. However, there are a couple people in the Linux community who have been working on Debian packaging & installers, and also someone working on slackware. Check the xfs mailing list archives for more info...
There may be a 3rd party installer for 7.1+reiserfs, but I know for certain that there is one for SGI's XFS filesystem. See oss.sgi.com/projects/xfs, or search freshmeat for "xfs". Right now it only works with wolverine but that will change shockingly soon.:)
Probably about half of law enforcement budgets and a growing amount of the military budgets are justified by the "war on drugs".
That, and a larger and larger percentage of law enforcement budgets are funded by the war on drugs - i.e. in an era of shrinking budgets, when the sherrif says they need new cop cars, the attitude is often "go out and seize one."
Ok, maybe not that blatant, but they're expected to rely on their seizures as a major budgetary item.
So they spend all this time looking for drugs (and, by extension, property & money to seize) rather than other activities which may more directly benefit the community in terms of law, order, and safety.
Ok, so there's not THAT much you can do, but every little bit helps.
DO NOT fill out those warranty cards unless they're required for the warranty. Weber, Inc. really is not entitled to know your household family income and hobbies just because you bought a freakin' grill...
If you use those "discount" cards in supermarkets, well - first, don't, but if you do, be sure to swap them with your friends whenever you can. Otherwise they know your preference for Fat Tire over Budweiser, etc.
Use cash.
Don't participate when some yokel calls you to ask bout your radio station listening habits.
Use junkbuster to filter out the cookies.*
Etc... feel free to add to the list...
*isn't it time to make a big "cookie swap" service on the net, to essentially randomize those doubleclick cookies? I'd be happy to let them thorugh if I could swap them with somebody else out of a pool of 100,000 every hour...
Slashdot Mirror
I wrote a Type 1 MICR font (GnuMICR) by hand, as far as I know, the only freely available MICR font out there, and licensed it under the GPL. (Postscript is a language, my font is a "program", IMHO).
I had a request from a guy who wanted to do a closed-source check printing program, and wanted to use my font. I told him that I would license it to him for a fee, but that he could not use it under the GPL if he hard-coded the font into his application. i.e., his application WOULD NOT WORK without my font. If he had made a font selection dialog, and happened to distribute my font with his program as one option, then that would probably have been fine by me.
For kicks, though, I asked the GPL newsgroup, and none other than Linus responded that he thought they were in the clear if they wanted to bundle my font with their app. I didn't really pursue it much further...
In any case, this DLL linking is probably more clear cut, and I think it's most likely a violation. But whenever you get interactions between GPL and non-GPL'd code, it gets tricky.
I thought the RBL was so that you could configure your network to not accept MAIL from the offending hosts.
But the other IP blocked was www.macromedia.com, which is of course their Web address. Blocking this address, I would assume, stops no spam from reaching anyone's inbox.
That's only true if mail never comes from www.macromedia.com, which is an assumption on your part.
It seems possible that "spam" was sent out from the host "www.macromedia.com" and as such, that machine was also in the RBL.
But if you're using the RBL to block ALL traffic from those hosts, then that's your problem, right? That's not what the RBL was designed for. If "www.macromedia.com" made the list, then sysadmins who choose to use the RBL will not accept mail from www.macromedia.com.
But that shouldn't mean that HTTP traffic is shut off.
What am I missing?
Number One reason -- he's a Mormon
:)
Oh, right. My bad.
And I don't go around labeling people "religious right" for no good reason, but Orrin Hatch has given me a few good reasons. :)
I've heard that he writes gospel music, and he likes the idea of being able to distribute it sans Mega-Corporations.
:)
Interesting intersection between the religious right and the hackers, eh?
At the same time, while I feel that the Right (hell, the Left too) has forsaken the normal citizen for corporate interests, it's interesting to see that when a legislator is directly, adversely affected by a corporate interest, all of a sudden they sing a different tune. So to speak.
I mean, if you told me that Orrin Hatch was on the Napster side of the online music distribution argument, I'd think you were nuts - if I didn't know that he had personal reasons to snub the RIAA.
You would think that if your friendly Town Hall was going to hire someone to write their laws, they would AT LEAST insist that the resulting document belong to the City, and not to the legal firm.
If it's copyrighted, there are probably terms of use - I'd like to see what those are...
"Where are we going, and why are we in this handbasket?"
Gracenote contacts.
But do it nicely. Try not to sound like a raving lunatic.
Talking points:
Much of the data, and the interface, were at one point publicly available, so they can claim no proprietary rights.
You would be willing to support them if they offered better service than competitors, but these attacks on competitors make you have serious doubts about continuing to use their services.
Etc...
Just realized, CVS has a kernel/ dir and a cmds/ dir.
Any chance your tallies include the whole cmds/ tree? That's all userspace stuff...
Also, one more tidbit, the CVS tree also contains the kdb code, so that's a (small) part of the increase.
I can't help but feel that that much code is going to have -some- impact on the rest of the system.
Although XFS is big, it doesn't stomp on the kernel that much.
If you're looking at it from a pure "volume of code" point of view, here's some info:
The XFS patches are split into 2 parts, one which contains kernel changes, and one which is the filesystem itself.
The "core-kernel" patch is about 190k, while the actual filesystem code patch is about 4.3M.
Bear in mind that a 190k patch to the kernel does not mean 190k of new code, either, since you have to take out the context lines, the headers, and the delete lines.
Overall, the impact on the kernel isn't as big as you might think, looking at the overall size.
Now, whether or not executing code in the filesystem slows down the rest of the system, I don't have any real data on that, although I have not noticed any detrimental effect on my system.
You have any idea what percentage of spam has a valid return email address? My guess is somewhere in the parts per billion.
What you're doing is mail-bombing yahoo, or whomever they decide to fake the sender as, with email for a non-existant account.
So one can only patch a stock Linus kernel with XFS?
:) As with any patch, you will have varying success patching source trees that differ from that which was used to generate the patch.
e le ase-1.0/patches/RHlinux-2.4.2-core-xfs-1.0.patch.g z
You can patch whatever you want, it's a question of how many conflicts you need to resolve.
What about the Red Hat 7.1 kernel? Would be nice if there was a patch for that.
ftp://linux-xfs.sgi.com/projects/xfs/download/R
So when will you submit it to Linus?
It's certainly a priority, but I can't really give you a timeline - we're working on it.
XFS is so big and touches so much
XFS is big, no getting around that, but we're making efforts to keep our modifications in the kernel to a minimum (actually, a lot of that work is done already). The patch is also now split into 2 pieces, one for "core linux" changes and one for the filesystem itself. That was done for a couple of reasons, but a nice side effect is that it's a little easier to see how much is XFS itself, and how much is linux changes.
XFS features extended attributes, so you could use this for mime types, I suppose. Any application would need to be aware of this, though, and would need to support it as well. Interesting idea though...
Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?
:) that'd be quite an undertaking. You can dump/restore between filesystems, or just copy over, but there is no magic "ext2 to xfs converter."
No, sorry.
FWIW, GRIO and realtime subvolumes (err... partitions in the Linux case) are not yet implemented in Linux.
We have a system installer that works with Red Hat 7.1 to do exactly what you're asking about. Grab our iso, burn a cd, boot from it, and you're on your way. You'll need the Red Hat 7.1 cds as well.
The other option, of course, is to have lots of extra space, install your distro, boot an XFS capable kernel, make some XFS filesystems, and copy everything over.
A lot of people have been complaining that there is no 2.4.4 patch - but bear in mind that 2.4.4 is only 3 days old. We'd be a bit nuts to release 1.0 on a kernel as untested as that.
On the other hand, the devel cvs tree is usually updated within a few days of a new kernel release. As soon as the kinks get out of XFS+2.4.4, it'll be in the devel cvs tree.
The majority of our 1.0 testing has been done on 2.4.2, so we have the most confidence in XFS there. We also have a 2.4.3 patch which should be fine, although it has not had as much direct testing.
We realize that there are issues with 2.4.2 (loop device, anyone?) If you're concerned about fix-ups, and you run an RPM-based systems, you might take a look at the Red Hat kernel RPMs we offer - those include a ton of patches from Red Hat - essentially the same kernel as shipped with 7.1, with XFS added.
If you're concerned about netfilter, just get the patch - I would be very surprised if it conflicted in any way with an XFS-enabled kernel.
The kernel & userspace utils are packaged several different ways - cvs, patches, tarballs, rpms etc.
Go to http://oss.sgi.com/projects/xfs for the info.
test-2, test-3, and 1.0 have been released since then, and that includes an acl fix. Without knowing for sure what your problem is, hard to say for sure if your specific problem has been resolved...
At this point, SGI has only provided an unsupported Red Hat system installer for XFS. However, there are a couple people in the Linux community who have been working on Debian packaging & installers, and also someone working on slackware. Check the xfs mailing list archives for more info...
Lilo in the MBR works just fine with XFS. There are no issues, I have 3 machines that boot that way.
---
That, and a larger and larger percentage of law enforcement budgets are funded by the war on drugs - i.e. in an era of shrinking budgets, when the sherrif says they need new cop cars, the attitude is often "go out and seize one."
Ok, maybe not that blatant, but they're expected to rely on their seizures as a major budgetary item.
So they spend all this time looking for drugs (and, by extension, property & money to seize) rather than other activities which may more directly benefit the community in terms of law, order, and safety.
---
DO NOT fill out those warranty cards unless they're required for the warranty. Weber, Inc. really is not entitled to know your household family income and hobbies just because you bought a freakin' grill...
If you use those "discount" cards in supermarkets, well - first, don't, but if you do, be sure to swap them with your friends whenever you can. Otherwise they know your preference for Fat Tire over Budweiser, etc.
Use cash.
Don't participate when some yokel calls you to ask bout your radio station listening habits.
Use junkbuster to filter out the cookies.*
Etc... feel free to add to the list...
*isn't it time to make a big "cookie swap" service on the net, to essentially randomize those doubleclick cookies? I'd be happy to let them thorugh if I could swap them with somebody else out of a pool of 100,000 every hour...
---