Something like inotify doesn't cut it for a virus scanner, since it needs to intercept read / write calls to be able to scan the files before the data is read.
What do you mean? I don't know about inotify, but in my opinion it wouldn't matter that the data is read, what matters is that it isn't returned to the calling program until hooked programs have signed off on the data. The same would naturally apply to the exec*() family of functions, only that they do not return data, but rather load the data as a new executable image.
But the Linux kernel license makes it quite clear that making system calls from user space (essentially all kernel extensions like this just provide extra syscalls and ioctls) does not constitute a derivative work so far as the GPL is concerned.
I know. OTOH, the software providing those extra system calls would probably be subject to the GPL, and that might be what McAfee is afraid of. They might consider this hooking code to be a part of their competitive edge, and by using a generic framework they would lose this edge, which they might also do by opening up their hooking code.
My guess is that this warning has arisen from the use of kernel hooks to provide on-demand scanning. I read somewhere that McAfee modifies the Windows kernel to intercept among others file access calls. They might want to do the same for Linux, which would subject the code that provides those hooks to the GPL. It may be the case that McAfee thinks that this code must be secret to ensure the security of their product, and that could be why they are so afraid of the GPL.
How about creating a generic interface for such applications that multiple vendors could use to intercept e.g. file access calls? Or does it already exist?
However, if someone invents a super new solar-flare powered DRM method that doesn't rely on obfuscating and sending the decryption key with the content - then knowing how the DRM method works shouldn't make any difference.
I'd argue that this is impossible. You'd need to send the decryption key to the attacker if you want him to be able to view the content, and doing so openly without obfuscation, well, I can't see how it could be possible. I fully believe that DRM and openness are completely incompatible. To have DRM, you need obfuscation, and without obfuscation, you cannot have DRM.
If that is the case, did you consider that maybe the musicians would have to pay the composers/writers in order to use their stuff?
Of course, I just feel like the people behind the artist should get a little more recognition for their work. A very large majority of the focus is on the artist (the singer/performer), and I'm just reminding people that there are other people that needs to get paid too. I wouldn't want the performer to put the entire income into his pocket, but make sure that the other people involved get their cut. Since this function has been provided by the record company, I just hope that artists rolling their own remember to do this.
To be fair, only paying the artists wouldn't solve the problem, since many artists are not song writers and composers. I agree with the sentiment that eliminating all the middle-men would be a good thing, but the artists are not the only ones that should get paid for a song.
I laugh whenever I see on Slashdot someone saying how they use Bittorrent to just download Linux distributions. That's a great way to act like a politician. It's bullshit, and you know it.
Then laugh some more, because that's exactly what I do. I only use Bittorrent to download legal material, like Linux distributions. That said, I would pirate stuff if there wouldn't be a measurable risk of getting into trouble with the law from it, but at present, I consider it too risky, especially as I can get my music and movies for free legally anyway.
It's not fair to them to see on Digg/Slashdot/Whatever posts like "FUCK RIAA".
That sentiment is probably (hopefully) not because the RIAA is pursuing file sharers, but because of the methods used in that pursuit. A fine should sting, it shouldn't put you in debt for the rest of your life. Additionally, suing grannys without a computer shows that the RIAA is just firing at random, rather than actually pursuing the heaviest infringers first. And then we have the greedy-with-no-limits claim that ripping CDs to your portable player is copyright infringement, which isn't doing any good for the public image of the RIAA. Finally we have the "girl scouts should pay royalties for singing songs around the campfire", which surely isn't RIAA, but rather ASCAP, but it's seen as part of the same crackdown, so the RIAA get part of the blame too.
Not at all. Think of encryption algorithms - you can know all about them - the "secret" is out - but you still can't break them.
Ordinary encryption systems have pretty different use patterns than DRM systems. Ordinary encryption systems protect your data from being viewed by intruders as well as people that snoop on your communications. As long as they cannot get the secret (i.e. key/password), your data is safe.
This is rather far from how DRM is supposed to work. In DRM systems, one of the communicating parties is also the attacker, and has to be prevented from getting the key at the same time as the key is necessary to unlock the content. Can you see the (obvious) difference?
In encryption terminology: In the first case, we have Alice and Bob communicating with Charlie trying to intercept the communications. In the latter case, we have Alice trying to communicate with Charlie (the attacker) in a way that the information (the content) can only be viewed by Charlie in ways that Alice allows.
I was thinking more of the immersive environments, like the helmet systems of the early 90's, or the CAVEs of the world. At work, we had (and have) the first completely immersive CAVE (all six faces of the cube were active) in the world, and that one failed miserably. It was used for a few small art projects, but because nobody wanted to pay for it, it has fallen into disuse and is now off-line, although it hasn't been dismantled yet.
most of the most popular open source projects are of the type that starts with "I wish there was an open-source version of [closed-source] product X".
And why does that happen? I can only speak for myself, but usually it is because the software lacks some feature (or has at least one serious bug) that I would find very useful, but cannot implement due to the closed nature of the software.
Well, the guy is a virtual reality researcher. What would you expect? Since he primarily works with pie-in-the-sky projects like VR, I could understand that he would find foundation-level software dull.
Are you sure this applies to modern CFLs with electronic ballasts? Old straight-tube fluorescent lights use magnetic ballasts and flicker at mainline frequency, which is 50-60 Hz, while modern CFLs contains frequency multipliers that raise the flicker frequency to some 20 kHz.
How much more energy does it take to make a CFL? Lots of parts and a twisty little tube plus some toxic chemicals and a plastic housing seems like a lot. I Presume standard bulbs are pretty simple to make if they can sell them for next to nothing nowdays.
To be fair, you would have to compare the life-cycle cost of six incandescents with one CFL, because of the six times longer lifespan of a CFL.
And while most incandescent bulbs are wasteful in terms of heat, that energy is not actually wasted all the time. In my house in the winter, any heat the bulbs put out is heat the furnace doesn't have to put out.
Except that light placement isn't designed to optimally heat the rooms they are in. Radiators aren't placed below the windows by accident, they are placed there since this maximizes the spread of the heat into the rooms they are supposed to heat. The heat from a light bulb stays just below the ceiling and is lost through the nearest ventilation duct.
Do you heat your house with that electricity as well? If not, servicing your heating system will still save fossil fuel.
Not necessarily. I don't live in France, but like France, Sweden does not use fossil fuels for electricity production. My apartment uses central heating, but that one is neither powered by electricity nor fossil fuels, but rather biomass or more specifically wood. Thus you can have heat that is not provided by electricity or fossil fuels.
there are a few areas in which they'll never work: lamps for reptiles, lava lamps, and so forth. In these cases we use incandescent bulbs primarily for the heat they radiate and only secondarily as a source of illumination.
Wouldn't a lava lamp work with a heater and a CFL? I mean, if they actually banned incandescents, which they didn't this time.
Well of course! Didn't say it wouldn't. But you assumed I loaded 32 bit?
Well, then what is this?
Seems like only MS is having the 3.1/4GB issue.
Anyway
But I didn't buy AMD X2s to run 32 bit anything, it runs 64 bit Fedora.
That's what I run on my home desktop too (Fedora 7 x86-64), dualbooting with Windows XP 32-bit (for my Windows games). My work laptop runs Fedora 7 only (I have no use for Windows there), although only the 32-bit version (with PAE enabled though, so that I can use the NX/XD bit) since it is a Pentium M.
No, 32-bit Linux also has the 3/4 GiB issue, unless it runs in PAE mode with hardware support for PAE. With Linux though, there are much fewer problems shifting to 64-bit, since there are much fewer (if any) drivers that are independently maintained and not yet adapted to 64-bit.
Secondly, 64-bit Windows will not run 16-bit software at all. That includes both Windows 3.1-era software, and DOS mode software.
Does this problem only exist on Windows, or is it intrinsic to all x86-64 processors? The reason why I ask is because I just checked my package lists for Fedora 7, and DOSBox is available as a 64-bit package. It would seem somewhat stupid if DOSBox would refuse to run most DOS programs because it couldn't handle 16 bit programs. And DOSBox is reportedly available for Windows too.
I don't see your average joe 6-pack user benefiting from more than 2gigs.
You will always benefit from having more memory, as more memory means that a greater amount of disk blocks can be cached in RAM. Modern operating systems use the memory unused by applications to buffer disk blocks, which results in higher performance due to less disk access. Thus, you cannot really have too much RAM.
Slashdot Mirror
What do you mean? I don't know about inotify, but in my opinion it wouldn't matter that the data is read, what matters is that it isn't returned to the calling program until hooked programs have signed off on the data. The same would naturally apply to the exec*() family of functions, only that they do not return data, but rather load the data as a new executable image.
I know. OTOH, the software providing those extra system calls would probably be subject to the GPL, and that might be what McAfee is afraid of. They might consider this hooking code to be a part of their competitive edge, and by using a generic framework they would lose this edge, which they might also do by opening up their hooking code.
My guess is that this warning has arisen from the use of kernel hooks to provide on-demand scanning. I read somewhere that McAfee modifies the Windows kernel to intercept among others file access calls. They might want to do the same for Linux, which would subject the code that provides those hooks to the GPL. It may be the case that McAfee thinks that this code must be secret to ensure the security of their product, and that could be why they are so afraid of the GPL.
How about creating a generic interface for such applications that multiple vendors could use to intercept e.g. file access calls? Or does it already exist?
EULAs cover use however.
On-demand virus scanners probably do however.
I'd argue that this is impossible. You'd need to send the decryption key to the attacker if you want him to be able to view the content, and doing so openly without obfuscation, well, I can't see how it could be possible. I fully believe that DRM and openness are completely incompatible. To have DRM, you need obfuscation, and without obfuscation, you cannot have DRM.
Of course, I just feel like the people behind the artist should get a little more recognition for their work. A very large majority of the focus is on the artist (the singer/performer), and I'm just reminding people that there are other people that needs to get paid too. I wouldn't want the performer to put the entire income into his pocket, but make sure that the other people involved get their cut. Since this function has been provided by the record company, I just hope that artists rolling their own remember to do this.
To be fair, only paying the artists wouldn't solve the problem, since many artists are not song writers and composers. I agree with the sentiment that eliminating all the middle-men would be a good thing, but the artists are not the only ones that should get paid for a song.
It is also good for consumers when consumer annoyance with DRM makes the record companies drop DRM from their music.
Then laugh some more, because that's exactly what I do. I only use Bittorrent to download legal material, like Linux distributions. That said, I would pirate stuff if there wouldn't be a measurable risk of getting into trouble with the law from it, but at present, I consider it too risky, especially as I can get my music and movies for free legally anyway.
It's not fair to them to see on Digg/Slashdot/Whatever posts like "FUCK RIAA".That sentiment is probably (hopefully) not because the RIAA is pursuing file sharers, but because of the methods used in that pursuit. A fine should sting, it shouldn't put you in debt for the rest of your life. Additionally, suing grannys without a computer shows that the RIAA is just firing at random, rather than actually pursuing the heaviest infringers first. And then we have the greedy-with-no-limits claim that ripping CDs to your portable player is copyright infringement, which isn't doing any good for the public image of the RIAA. Finally we have the "girl scouts should pay royalties for singing songs around the campfire", which surely isn't RIAA, but rather ASCAP, but it's seen as part of the same crackdown, so the RIAA get part of the blame too.
Ordinary encryption systems have pretty different use patterns than DRM systems. Ordinary encryption systems protect your data from being viewed by intruders as well as people that snoop on your communications. As long as they cannot get the secret (i.e. key/password), your data is safe.
This is rather far from how DRM is supposed to work. In DRM systems, one of the communicating parties is also the attacker, and has to be prevented from getting the key at the same time as the key is necessary to unlock the content. Can you see the (obvious) difference?
In encryption terminology: In the first case, we have Alice and Bob communicating with Charlie trying to intercept the communications. In the latter case, we have Alice trying to communicate with Charlie (the attacker) in a way that the information (the content) can only be viewed by Charlie in ways that Alice allows.
I was thinking more of the immersive environments, like the helmet systems of the early 90's, or the CAVEs of the world. At work, we had (and have) the first completely immersive CAVE (all six faces of the cube were active) in the world, and that one failed miserably. It was used for a few small art projects, but because nobody wanted to pay for it, it has fallen into disuse and is now off-line, although it hasn't been dismantled yet.
And why does that happen? I can only speak for myself, but usually it is because the software lacks some feature (or has at least one serious bug) that I would find very useful, but cannot implement due to the closed nature of the software.
Well, the guy is a virtual reality researcher. What would you expect? Since he primarily works with pie-in-the-sky projects like VR, I could understand that he would find foundation-level software dull.
Are you sure this applies to modern CFLs with electronic ballasts? Old straight-tube fluorescent lights use magnetic ballasts and flicker at mainline frequency, which is 50-60 Hz, while modern CFLs contains frequency multipliers that raise the flicker frequency to some 20 kHz.
To be fair, you would have to compare the life-cycle cost of six incandescents with one CFL, because of the six times longer lifespan of a CFL.
Except that light placement isn't designed to optimally heat the rooms they are in. Radiators aren't placed below the windows by accident, they are placed there since this maximizes the spread of the heat into the rooms they are supposed to heat. The heat from a light bulb stays just below the ceiling and is lost through the nearest ventilation duct.
Not necessarily. I don't live in France, but like France, Sweden does not use fossil fuels for electricity production. My apartment uses central heating, but that one is neither powered by electricity nor fossil fuels, but rather biomass or more specifically wood. Thus you can have heat that is not provided by electricity or fossil fuels.
Wouldn't a lava lamp work with a heater and a CFL? I mean, if they actually banned incandescents, which they didn't this time.
Which is exactly what they have done. FTA:
Congress has not specifically outlawed incandescent bulbs, only inefficient ones.Well, then what is this?
Seems like only MS is having the 3.1/4GB issue.Anyway
But I didn't buy AMD X2s to run 32 bit anything, it runs 64 bit Fedora.That's what I run on my home desktop too (Fedora 7 x86-64), dualbooting with Windows XP 32-bit (for my Windows games). My work laptop runs Fedora 7 only (I have no use for Windows there), although only the 32-bit version (with PAE enabled though, so that I can use the NX/XD bit) since it is a Pentium M.
Ahh, I hadn't realized that DOSBox is actually a full CPU emulator.
No, 32-bit Linux also has the 3/4 GiB issue, unless it runs in PAE mode with hardware support for PAE. With Linux though, there are much fewer problems shifting to 64-bit, since there are much fewer (if any) drivers that are independently maintained and not yet adapted to 64-bit.
Does this problem only exist on Windows, or is it intrinsic to all x86-64 processors? The reason why I ask is because I just checked my package lists for Fedora 7, and DOSBox is available as a 64-bit package. It would seem somewhat stupid if DOSBox would refuse to run most DOS programs because it couldn't handle 16 bit programs. And DOSBox is reportedly available for Windows too.
You will always benefit from having more memory, as more memory means that a greater amount of disk blocks can be cached in RAM. Modern operating systems use the memory unused by applications to buffer disk blocks, which results in higher performance due to less disk access. Thus, you cannot really have too much RAM.