I think you need to read the GPL again. As yet, SpecOps Labs have not distributed their product, and as such the GPL does not yet affect them. There is no clause that insists that they make the authors aware of any modification to their code; it's polite to do so, but so long as you comply with the GPL, you don't have to.
I did. This didn't stop Paypal charging it, and trying to pass the charges onto me.
If it had stopped being an issue once I'd got a new card and cancelled the old one, I'd not be so upset. However, Paypal insisted, right up until the police got involved with them, that I had authorised the charges, and that they could continue to charge my account via my old card, which had been cancelled 3 months earlier, and that I should pay those charges.
I've had trouble with Paypal, despite not using them; someone managed to convince them to put my credit card onto their account, thus forcing me to keep charging back via my card company. After 3 months of arguing with Paypal, my card issuer and I took things to the police. Suddenly, Paypal had a human being who could call me, and who had read all the e-mail I'd sent, and who realised that they were doing something wrong. Amazing!
If FOSS is good enough, people aren't going to pay at all for software. MS needs to avoid the situation where something that can be obtained free as in beer is considered as good as their software for the uses people have for it.
So, it comes down to a business decision: keep pirates, and hope that this stops people worrying about interoperability with FOSS, or crack down on pirates, and hope that people don't start seeing FOSS as "good enough".
The danger of FOSS being good enough is that MS can't sell Office against it. Why pay $10 per computer for MS Office, when you can buy an OpenOffice.org CD for $10 and install it on every machine you have? Bear in mind that OpenOffice.org doesn't need to be as good as Office, just good enough that the extras in Office are worth nothing to your business.
Don't forget that currently, MS does not need to worry about interoperating with FOSS; FOSS has to interoperate nicely with MS to avoid being dismissed. If pirates switch in droves to FOSS, MS faces the risk of having to interoperate with FOSS, which will cost money. Further, once FOSS is established as "good enough", there's the danger that businesses will switch wholesale, cutting off large revenue streams.
They're no longer encrypted; the BBC has moved to Astra 2D, which is very difficult to receive in Europe, so they are now happy to leave them unscrambled (hence no need for a smartcard).
Depends on how the movie is made; it's widely held in the industry that you need 4000 lines of resolution to get down to the point where film grain is noticeable; given that high-end HDTV is still only 1080 lines of resolution, all it takes to get movies looking better in HD than SD is the owner of the film rescanning it at HD resolution.
An important package is one where if you remove it, you can't reinstall the removed package. This includes things like the C library and compiler on Gentoo. For these packages, I want an extra warning, because there's good reasons not to do it, and I should be extra-certain I want to do that. This does not mean stop me, since I may have an externality that gets me out of trouble (e.g. a second system), but it does mean that I need to be certain I know what I'm doing.
For other packages, a good version of emerge would do reverse dependency analysis, and list the packages that I'm going to break when I remove a package; I'd be happy if I have to do "emerge --pretend unmerge qt" to get a list of packages I'll break when I remove Qt; the point is to remove silent breakage when I uninstall something. This one's not so important on a single-user machine, but when I can break your programs and not mine, I should know that I'm going to do so.
The point here is that every admin has an off day; a good tool warns you before you do something silly, then lets you do it anyway. Debian's apt and dpkg are a good tool in this field; both warn me if I'm about to remove something I shouldn't, let me know what I'll break by removing them, and allow me to do it anyway if I really want to.
A bad tool like emerge lets you do something very stupid without trying to warn you; this is not to say that the admin who types "emerge unmerge gcc" is not at fault, rather that if emerge were even better, it would warn the admin that they're about to have trouble. After all, said admin might be intending to remove ghc, having lost interest in Haskell
Plus, I want to introduce new people to Linux who aren't computer types; that way, if they end up in management, they're more likely to accept that Linux can be good enough. This involves setting up their computer, having ssh access in case it breaks, and introducing them to admin tools bit by bit. I would be happier if I could trust emerge to warn people when they do something stupid.
In the current portage tree (last updated 16 hours ago), there are no rescue tarballs for portage on x86; further, when you've lost glibc for whatever reason, you can't run bunzip2, and thus you are limited to the capabilities of sash. This means that only tar.gz is useful.
I'm personally not bothered about this; I had access to a second box, so I was able to save myself, but I'll go file a bug report against portage in case I ever need the rescue tarballs.
I'm well aware of the importance of glibc. Try "apt-get remove libc6" on a Debian box some day; instead of doing what my Gentoo box does, and calmly offering to remove just glibc, it lists all the packages I've got installed, and warns me that it'll remove them. It also warns me that I'll be removing essential packages, and that I shouldn't continue unless I know what I'm doing.
OK, glibc is an extreme example. However, a user might well believe that (for example), they didn't need that Qt thingy, because they use KDE; a good package manager would warn them that removing Qt will break KDE. A dangerous one (like portage currently is) leaves you to find out the hard way that you've broken it.
Try "emerge --unmerge glibc"; this is dangerous, and it will kill your box to the point where emerge doesn't work (at least, it'll remove libc.so.6, and when I've lost that file due to a HDD fault, it's impossible to emerge anything).
Gentoo doesn't even warn you that it's risky, just lets you do it.
A better version of emerge would detect that glibc is depended on, and warn you that you're about to break almost everything; at a minimum, a better version of emerge would prevent you from getting into a state where you can't emerge new stuff.
If you excuse is, oh its everywhere, then hell, GET A DAMN CDRW with everything GOOD, or USB key.
I'll bite on this one. There's no guarantee that when you come to tackle a machine at crisis point, you'll be able to read a CD or a USB key. Granted, it's rare that you'll get into this state, but when it happens, being able to use vi effectively is helpful.
Two examples I've had in the last 5 years:
Breaking root on an SGI Origin when the admin left and "forgot" to give us the password. We'd checked that we had the firmware password and the NIS+ root password, so it was possible to boot into single user mode via a serial terminal; however, the machine ignored NIS+ for root logins. The machine didn't have a CD drive or a USB port; adding a SCSI CD could have worked, had we had time and tools to create an EFS or XFS format disc for it to read (ISO9660 support had been disabled for security reasons by the previous admin). We'd also have to have obtained a binary for joe or pico compiled for n32 or n64 MIPS. However, knowing just enough vanilla vi (HJKL and x keys), it was possible to get in and delete the local root password.
Second, fixing someone's colo box where we had no physical access. In this case, the system had vi and all libraries on/./usr had failed to mount (kernel miscompile), so all other editors were inaccessible, together with useful things like wget and lynx. The owner had been bright enough to copy their old kernel to one side, but had forgotten to add a LILO entry, so it couldn't be booted unless we edited lilo.conf. In this case, we could have coped by using cp to replace the new kernel image, then booting safely; however, with vi available, we edited lilo.conf to allow booting into the known good kernel, thus ensuring that we didn't forget to do this once we were back in.
Granted, in one of these cases, vi was a bonus, not a necessity. Even so, it's about the only editor that's almost certain to be available, and if you're likely to ever need to rescue a badly killed machine, it's a skill worth acquiring.
I have a car. I don't go out of town that often either; the only reason I don't get rid of the car is that carrying myself and a Uni holiday's worth of stuff back to the south of London from Durham is next to impossible by train. I can get to King's Cross station (north London), but getting across London with all my belongings is impossible by public transport.
"Doug Balog, an IBM vice president, noted that 70 percent of the world's datum are still housed in mainframe computers."
I have been correcting people over this for decades and still nobody corrects their usage
Perhaps because you're wrong. Datum is a Latin 2nd declension neuter singular, while data is the plural form. So, data is the plural, while datum is the singular. However, since we speak English, not Latin, using data for the singular is perfectly acceptable.
After you're forced to stare at and click the link to continue, you get a requested pop-up window (you know, like the ones you don't block) with advertising content.
I can't be the only person who blocks all pop-ups, can I? My browsers of choice all let me enable pop-ups for sites that matter to me that require pop-ups (currently none), so if I've never visited your site before, when I click the link to continue, the pop-up is silently blocked.
Of course, there's a tradeoff between the value of your content and the cost of visiting your site; too much advertising, or too much intrusiveness, and I'll not visit. Depends what you use your sites for, but it may not be what you intended.
A question for you: if a similar lawsuit was brought against Microsoft, would you abandon Windows 2003? If not, why not?
I'm asking, because it seems to me that Microsoft is at least as at risk of this type of lawsuit as IBM and other Linux companies. It's harder to peek inside Microsoft Windows and see what's inside than it is to peek inside Linux and see what's inside; Microsoft are also the world's most cash rich target, and if you're looking for a big payout, they're far more tempting than (say) IBM.
In the UK, we had a pay TV service, originally called On Digital, and later called ITV Digital, that used standard TV broadcast frequencies for their pay service. It failed for a number of reasons including poor encryption.
We've now got FreeView, a free to air replacement. Same technology sans encryption. There's also a group called Top Up TV, who are looking to add some pay channels to Freeview, but they look likely to fail due to lack of new equipment to receive pay channels on, and a poor selection of channels (limited due to lack of UHF bandwidth).
The specs say that the MTBF is 1 in 10E14. I suspect that the reason why it suggests low I/O applications is that the amount of data stored is huge per disk, and if you need to shift 400GB regularly, a RAID of smaller drives would work better.
Note the "big"; if I were after a few TB of storage, then the cost difference between (say) 22 100GB drives (to make a 2TB RAID-6) and around 7 400GB drives may be made up in the costs of extra casing and power for the 100GB drives.
It looks like a nice drive for putting in a big RAID, but I'm not sure I'd like to put that much data in one place; the MTBF is about right for a modern drive, and I've had the 2 of my last 8 drives fail.
Slashdot Mirror
I think you need to read the GPL again. As yet, SpecOps Labs have not distributed their product, and as such the GPL does not yet affect them. There is no clause that insists that they make the authors aware of any modification to their code; it's polite to do so, but so long as you comply with the GPL, you don't have to.
If it had stopped being an issue once I'd got a new card and cancelled the old one, I'd not be so upset. However, Paypal insisted, right up until the police got involved with them, that I had authorised the charges, and that they could continue to charge my account via my old card, which had been cancelled 3 months earlier, and that I should pay those charges.
I've had trouble with Paypal, despite not using them; someone managed to convince them to put my credit card onto their account, thus forcing me to keep charging back via my card company. After 3 months of arguing with Paypal, my card issuer and I took things to the police. Suddenly, Paypal had a human being who could call me, and who had read all the e-mail I'd sent, and who realised that they were doing something wrong. Amazing!
So, it comes down to a business decision: keep pirates, and hope that this stops people worrying about interoperability with FOSS, or crack down on pirates, and hope that people don't start seeing FOSS as "good enough".
The danger of FOSS being good enough is that MS can't sell Office against it. Why pay $10 per computer for MS Office, when you can buy an OpenOffice.org CD for $10 and install it on every machine you have? Bear in mind that OpenOffice.org doesn't need to be as good as Office, just good enough that the extras in Office are worth nothing to your business.
Don't forget that currently, MS does not need to worry about interoperating with FOSS; FOSS has to interoperate nicely with MS to avoid being dismissed. If pirates switch in droves to FOSS, MS faces the risk of having to interoperate with FOSS, which will cost money. Further, once FOSS is established as "good enough", there's the danger that businesses will switch wholesale, cutting off large revenue streams.
They're no longer encrypted; the BBC has moved to Astra 2D, which is very difficult to receive in Europe, so they are now happy to leave them unscrambled (hence no need for a smartcard).
Depends on how the movie is made; it's widely held in the industry that you need 4000 lines of resolution to get down to the point where film grain is noticeable; given that high-end HDTV is still only 1080 lines of resolution, all it takes to get movies looking better in HD than SD is the owner of the film rescanning it at HD resolution.
For other packages, a good version of emerge would do reverse dependency analysis, and list the packages that I'm going to break when I remove a package; I'd be happy if I have to do "emerge --pretend unmerge qt" to get a list of packages I'll break when I remove Qt; the point is to remove silent breakage when I uninstall something. This one's not so important on a single-user machine, but when I can break your programs and not mine, I should know that I'm going to do so.
A bad tool like emerge lets you do something very stupid without trying to warn you; this is not to say that the admin who types "emerge unmerge gcc" is not at fault, rather that if emerge were even better, it would warn the admin that they're about to have trouble. After all, said admin might be intending to remove ghc, having lost interest in Haskell
Plus, I want to introduce new people to Linux who aren't computer types; that way, if they end up in management, they're more likely to accept that Linux can be good enough. This involves setting up their computer, having ssh access in case it breaks, and introducing them to admin tools bit by bit. I would be happier if I could trust emerge to warn people when they do something stupid.
I'm personally not bothered about this; I had access to a second box, so I was able to save myself, but I'll go file a bug report against portage in case I ever need the rescue tarballs.
OK, glibc is an extreme example. However, a user might well believe that (for example), they didn't need that Qt thingy, because they use KDE; a good package manager would warn them that removing Qt will break KDE. A dangerous one (like portage currently is) leaves you to find out the hard way that you've broken it.
A better version of emerge would detect that glibc is depended on, and warn you that you're about to break almost everything; at a minimum, a better version of emerge would prevent you from getting into a state where you can't emerge new stuff.
Try this PC. It looks like it'll be available in stores too, but as I'm not in the US, I can't go and look.
I'll bite on this one. There's no guarantee that when you come to tackle a machine at crisis point, you'll be able to read a CD or a USB key. Granted, it's rare that you'll get into this state, but when it happens, being able to use vi effectively is helpful.
Two examples I've had in the last 5 years:
- Breaking root on an SGI Origin when the admin left and "forgot" to give us the password. We'd checked that we had the firmware password and the NIS+ root password, so it was possible to boot into single user mode via a serial terminal; however, the machine ignored NIS+ for root logins. The machine didn't have a CD drive or a USB port; adding a SCSI CD could have worked, had we had time and tools to create an EFS or XFS format disc for it to read (ISO9660 support had been disabled for security reasons by the previous admin). We'd also have to have obtained a binary for joe or pico compiled for n32 or n64 MIPS. However, knowing just enough vanilla vi (HJKL and x keys), it was possible to get in and delete the local root password.
- Second, fixing someone's colo box where we had no physical access. In this case, the system had vi and all libraries on
/. /usr had failed to mount (kernel miscompile), so all other editors were inaccessible, together with useful things like wget and lynx. The owner had been bright enough to copy their old kernel to one side, but had forgotten to add a LILO entry, so it couldn't be booted unless we edited lilo.conf. In this case, we could have coped by using cp to replace the new kernel image, then booting safely; however, with vi available, we edited lilo.conf to allow booting into the known good kernel, thus ensuring that we didn't forget to do this once we were back in.
Granted, in one of these cases, vi was a bonus, not a necessity. Even so, it's about the only editor that's almost certain to be available, and if you're likely to ever need to rescue a badly killed machine, it's a skill worth acquiring.I have a car. I don't go out of town that often either; the only reason I don't get rid of the car is that carrying myself and a Uni holiday's worth of stuff back to the south of London from Durham is next to impossible by train. I can get to King's Cross station (north London), but getting across London with all my belongings is impossible by public transport.
No, forum is singular, fora is plural. Both datum and forum are 2nd declension neuter in Latin, so -um is singular, and -a is plural.
So, how do I get a beasty that big from Folkestone to County Durham? It's over 300 miles to travel by road, and I'm not sure it's an easy trip...
I can't be the only person who blocks all pop-ups, can I? My browsers of choice all let me enable pop-ups for sites that matter to me that require pop-ups (currently none), so if I've never visited your site before, when I click the link to continue, the pop-up is silently blocked.
Of course, there's a tradeoff between the value of your content and the cost of visiting your site; too much advertising, or too much intrusiveness, and I'll not visit. Depends what you use your sites for, but it may not be what you intended.
I'm asking, because it seems to me that Microsoft is at least as at risk of this type of lawsuit as IBM and other Linux companies. It's harder to peek inside Microsoft Windows and see what's inside than it is to peek inside Linux and see what's inside; Microsoft are also the world's most cash rich target, and if you're looking for a big payout, they're far more tempting than (say) IBM.
We've now got FreeView, a free to air replacement. Same technology sans encryption. There's also a group called Top Up TV, who are looking to add some pay channels to Freeview, but they look likely to fail due to lack of new equipment to receive pay channels on, and a poor selection of channels (limited due to lack of UHF bandwidth).
The specs say that the MTBF is 1 in 10E14. I suspect that the reason why it suggests low I/O applications is that the amount of data stored is huge per disk, and if you need to shift 400GB regularly, a RAID of smaller drives would work better.
Note the "big"; if I were after a few TB of storage, then the cost difference between (say) 22 100GB drives (to make a 2TB RAID-6) and around 7 400GB drives may be made up in the costs of extra casing and power for the 100GB drives.
It looks like a nice drive for putting in a big RAID, but I'm not sure I'd like to put that much data in one place; the MTBF is about right for a modern drive, and I've had the 2 of my last 8 drives fail.