No, it's all of us. I know extremely competent people who are unemployed or seriously under-employed. Of course, they're often asking for real salaries and being picky, with the result that they stay unemployed longer than necessary.
Unfortunately, you can expect CD and DVD drives to require "trusted computing" access within 3 years, primarily to support DRM. Linux needs to look at this problem early to support video/audio/hardware access in the future.
There's no confusion. You can sign *NOTHING* without one of the expensive and tightly controlled signature keys from Microsoft or one of their tightly controlled clients, used to authorize the new keys you might want to load into the DRM. No initial signature, no new keys. It's fundamental to the key management, to prevent software from loading unauthorized keys.
The DRM basis of the "Trusted Computing" initiative is quite clear from its orign as Microsoft's "Palladium" project: it is designed to permit software and file signing, which is fine, but it's also been designed to control hardware access and the use of feature sets.
This particularly includes DVD players, graphics cards or video players, and even boot loaders so that the actual hardware functions cannot be used without appropriately authorized software keys. The actual purpose is to support DRM, and that's the business case for including it in Windows software.
I'm sorry that Linux has to deal with it in its current incarnation: almost every feature of "trusted computing" has been available for years in the software world, but has been limited by patent arguments and federal policies on the export of encryption technologies in the US, and other restrictions on encryption in other countries. Be clear on this: any robust "signature" technology can be used for encryption, and vice versa. It's only by limiting its at the hardware level and the most basic OS level that you can prevent its use for good general encryption, and that's a big feature of the planned usage of it.
Moreover, the planned key management of it is ridiculous. A small set of signed root keys, maintained by Microsoft, is fundamental to the usage model. Who trusts Microsoft to use its secret ninja powers only for the forces of good?
Or your employees are staying married too long. Overwork them and increase the divorce rate, or for even more fun hire former congressional pages and White House interns.
We already did. It's called Kerberos, it's open source despite Microsoft's extent to "embrace and extend" it to death, and it works damned well for a lot of systems.
Integrating it into corporate IT structures can be very tough, because there are often legacy services that require telnet (such as core switches) or web interfaces or proprietary clients (such as accounting software). Merging password management among those different systems is quite difficult, although we've certainly tried over the years.
This is exactly right. Most models of good password creation ignore the problem of good password handling, and security gets massively compromised.
I find that using SSH keys wherever possible, with the local accounts actually having their passwords locked and forced to use SSH keys, works quite well. The trick then is to force the user to passphrase the SSH key, which is helped by using tools like keychain that allow them to use the password once and use it anywhere.
Kerberos has a similar approach but requires a central server, and isn't as broadly implemented.
But once you have users going out into the field with on-line lists of plain-text passwords, or paper with the passwords on them, your password security has failed.
Not for server grade systems. You get quite a lot of noise from the case fans, not just the CPU fan, and you do notice a noise difference when you go to larger, more expensive fans that can move the air more quietly.
Because when he makes any change in his DNS, he wants it to show up nearly immediately. Never mind that a hand-executed "reload" command can be sent to those servers when he checks his edited DNS files into his source control system automatically.
And if you're not using source control for your DNS changes, you should go to a different line of work.
It's common among Active Directory administrators and other admins who can't spell DNS. Rather than allowing DNS to work as designed, they pull the new zone data from other local servers only when they decide that the data needs to be updated.
This can actually improve local stability and performance, since the zones do not have to be reloaded, especially for extremely large domains that have are unwilling or unable to delegate subdomains, and can allow sanity checking before the master server grabs the new zones. But it's a direct violation of the standards for DNS, and causes problems getting small additions or changes to those zones updated in an appropriate fashion.
IT's got an image attachment of any sort in the mail? Then it's spam. No problem to block, and you can notify the user so they wise up and don't send anything that auto-opens in your mailer.
Unfortunately, it doesn't block spam that includes HTML and image URL's to show the content in Windows email clients, but if you block HTML email as well, you block another format that is almost entirely spam. Yes, this is very harsh, but people should be discouraged from sending HTML email for other reasons.
My God, who bought into Microsoft's proposals seriously enough to bring down this load of bad ideas on our heads? Pleae, please, please, gentle readers, go read up at sites like www.spf.org and www.spamhaus.com and the RBL sites and the various websites on what's already been tried and what doesn't work!
You're right about the expense and effort being significant. You've also left out that the PGP keys of major sites, once stolen, will be passed around and used by the same crackers who sell access to zombied machines now to sell spam services.
In the US, at least, there is a major legal hurdle to stopping spam called the Direct Marketing Association. They are the junk mailers and sales-by-phone companies, and vaguely more legitimate advertisers who use bulk mail and bulk email. Getting clear laws in place to block spam will make legal precedents against their members' businesses: that's why they fought the junk fax laws so hard, when junk faxes got so burdensome that it was eventually outlawed.
It's deliberately designed to be confusing, to give different lobbyists different things they can point to as successful or agreeing with their beliefs. It leaves the whole mess in the hands of the bureaucrates, with wide leeway on their part to "guide policy" or buckle under to pressure from their own governments or exert pressure on each other.
It's typical bureaucratic weasel wording, much like sexual harassment policies. It looks like a lot of guidelines, but they're so flexible and masked that no action need be taken unless a company feels like it.
Re:Weren't they aware of this during implementatio
on
VLC & European Patents
·
· Score: 1
It's not the code. The code copyrights can be worked around by developing a distinct, unique implementation from the specifactions of the protocols.
The problem is patents for things like MP3, which are used extensively by music players and audio playing software and websites for the material. "Removing infringing code" doesn't help a patent violation, and the open source folks don't have the finances to implement a new protocol to replace that used by Ipods and other proprietary players.
Get over your excessively libertarian self. MAPS can cut easily 40% off your incoming traffic, all but a very rare message spam. This takes a serious load off your mail server that is better used for other purposes, like actually storing and sending and serving people's email.
That collateral damage is quite large and costs quite a lot of money and time if you don't find some way to block it from your users. The very occasional blocked legitimate email can be whitelisted by IP address on the recipient's part, or the sender can get their ISP to shape up. But failing to block it outright simply wastes everyone's time.
The spammers also purchase other netblocks or IP addresses. Most ISP's or colocation facilities will happily sell you as many IP addresses as you want to pay for, and thus the spammer need not move a thing. They remotely activate another IP address hosted by the same facility for sending their spam.
This is swatting flies with a shutdown of all roads leading to the swamp that generates them. While a victimized customer of the ISP feels hurt, it's almost invariably true that the ISP has been failing to police their own address space. The spammers will jump around the IP space of such a provider: this has been repeatedly demonstrated for years.
Blocking the whole IP space gets the ISP to sit up and take notice, and actually allocate manpower to the problem or assist them in dumping the spamming customer. Look at the old records of the "cyberpromo.com" to show how reluctant some ISP's have been to dump customers who continue in such spamming behavior, even when it's clearly illegal and abusive.
No, it's not. As long as the kernel "uname" remains the same, the source isn't too wildly, and the.config is consistent, the actual name of the RPM package or the labeling information allows inter-operability.
Trust me, I tried that stunt with a number of kernels years ago and it worked just fine.
Yes, they do. Radio exists, even satellite TV's in the village centers of very poor communities, and many of them do try hard to get their children some education. Don't underestimate the ability of the poor to see, and understand and envy, the world of the wealthy and powerful.
That resembles the problem with Sun's "YellowPages" service, that they were forced to rename "NIS" due to trademark violations with a British company. The courts take trademark violation quite seriously: given the shaky funding and support for ZetaOS, you might actually be able to take their nice venture-capital funded super-laptops away from their sales agents.
The UNIX underpinnings are really, really helping keep the open source tools available to Apple. Portiing from Linux to BSD variants and back takes work, but is feasible. Porting to Be and back would have been painful at best, especially due to the closed source.
The 10 second from power on to prompt is a flat-out lie. The BIOS screen alone on a typical motherboard takes at least 20 seconds, longer if it has SCSI and SATA or other unused boot options it needs to scan for. And you really have to count that as part of the turn-on time from power-on.
Now, Windows XP also does a lot of operations when first starting up that make it nearly useless until they complete, such as its indexing of the hard drive. So you get a login prompt, but it's a smaller lie. The system isn't really ready to operate for some noticeably longer period until those boot operations complete, but it's going on in the background. This is typical Microsoft behavior, by the way: deliver what is basically adware ASAP, deliver the usable stuff later when you get around to it and the custoomer has already bought in.
Linux, like other UNIX descendants, does its boot time setups in serial fashion. They can be heavily parrelized, which has led to some interesting optimization tools for exactly this purpose, and this cuts the heck out of boot time, but it's been left serial on the grounds that it's much easier to code for and maintain and debug.
sure, after 3 minutes wasted staring at the BIOS scanning for non-existent hardware and boot options that you don't want. SCSI device scanning, SATA, ntwork boot, floppy, all the IDE ports, and all the random memory and other hardware scans that get run add insult to injury as part of the typical boot setup.
This can be reduced wildly by using the new Linux based BIOS's, but so far vendor support for them has been grudging at best, and vendors like AMI have non-discluser-agreements signed with their major board manufacturers on both the API's used by the motherboards and the API's on the tools to reload the BIOS, so it's difficult to break into that market.
Slashdot Mirror
No, it's all of us. I know extremely competent people who are unemployed or seriously under-employed. Of course, they're often asking for real salaries and being picky, with the result that they stay unemployed longer than necessary.
Unfortunately, you can expect CD and DVD drives to require "trusted computing" access within 3 years, primarily to support DRM. Linux needs to look at this problem early to support video/audio/hardware access in the future.
It's too much. It should be called something like 2.8 or 2.6.20 to make clear the level of change.
There's no confusion. You can sign *NOTHING* without one of the expensive and tightly controlled signature keys from Microsoft or one of their tightly controlled clients, used to authorize the new keys you might want to load into the DRM. No initial signature, no new keys. It's fundamental to the key management, to prevent software from loading unauthorized keys.
The DRM basis of the "Trusted Computing" initiative is quite clear from its orign as Microsoft's "Palladium" project: it is designed to permit software and file signing, which is fine, but it's also been designed to control hardware access and the use of feature sets.
This particularly includes DVD players, graphics cards or video players, and even boot loaders so that the actual hardware functions cannot be used without appropriately authorized software keys. The actual purpose is to support DRM, and that's the business case for including it in Windows software.
I'm sorry that Linux has to deal with it in its current incarnation: almost every feature of "trusted computing" has been available for years in the software world, but has been limited by patent arguments and federal policies on the export of encryption technologies in the US, and other restrictions on encryption in other countries. Be clear on this: any robust "signature" technology can be used for encryption, and vice versa. It's only by limiting its at the hardware level and the most basic OS level that you can prevent its use for good general encryption, and that's a big feature of the planned usage of it.
Moreover, the planned key management of it is ridiculous. A small set of signed root keys, maintained by Microsoft, is fundamental to the usage model. Who trusts Microsoft to use its secret ninja powers only for the forces of good?
And not widely used by photo editing software, which they also want to control the market for.
Or your employees are staying married too long. Overwork them and increase the divorce rate, or for even more fun hire former congressional pages and White House interns.
We already did. It's called Kerberos, it's open source despite Microsoft's extent to "embrace and extend" it to death, and it works damned well for a lot of systems. Integrating it into corporate IT structures can be very tough, because there are often legacy services that require telnet (such as core switches) or web interfaces or proprietary clients (such as accounting software). Merging password management among those different systems is quite difficult, although we've certainly tried over the years.
This is exactly right. Most models of good password creation ignore the problem of good password handling, and security gets massively compromised.
I find that using SSH keys wherever possible, with the local accounts actually having their passwords locked and forced to use SSH keys, works quite well. The trick then is to force the user to passphrase the SSH key, which is helped by using tools like keychain that allow them to use the password once and use it anywhere.
Kerberos has a similar approach but requires a central server, and isn't as broadly implemented.
But once you have users going out into the field with on-line lists of plain-text passwords, or paper with the passwords on them, your password security has failed.
Not for server grade systems. You get quite a lot of noise from the case fans, not just the CPU fan, and you do notice a noise difference when you go to larger, more expensive fans that can move the air more quietly.
Because when he makes any change in his DNS, he wants it to show up nearly immediately. Never mind that a hand-executed "reload" command can be sent to those servers when he checks his edited DNS files into his source control system automatically. And if you're not using source control for your DNS changes, you should go to a different line of work.
It's common among Active Directory administrators and other admins who can't spell DNS. Rather than allowing DNS to work as designed, they pull the new zone data from other local servers only when they decide that the data needs to be updated.
This can actually improve local stability and performance, since the zones do not have to be reloaded, especially for extremely large domains that have are unwilling or unable to delegate subdomains, and can allow sanity checking before the master server grabs the new zones. But it's a direct violation of the standards for DNS, and causes problems getting small additions or changes to those zones updated in an appropriate fashion.
IT's got an image attachment of any sort in the mail? Then it's spam. No problem to block, and you can notify the user so they wise up and don't send anything that auto-opens in your mailer.
Unfortunately, it doesn't block spam that includes HTML and image URL's to show the content in Windows email clients, but if you block HTML email as well, you block another format that is almost entirely spam. Yes, this is very harsh, but people should be discouraged from sending HTML email for other reasons.
My God, who bought into Microsoft's proposals seriously enough to bring down this load of bad ideas on our heads? Pleae, please, please, gentle readers, go read up at sites like www.spf.org and www.spamhaus.com and the RBL sites and the various websites on what's already been tried and what doesn't work!
You're right about the expense and effort being significant. You've also left out that the PGP keys of major sites, once stolen, will be passed around and used by the same crackers who sell access to zombied machines now to sell spam services.
In the US, at least, there is a major legal hurdle to stopping spam called the Direct Marketing Association. They are the junk mailers and sales-by-phone companies, and vaguely more legitimate advertisers who use bulk mail and bulk email. Getting clear laws in place to block spam will make legal precedents against their members' businesses: that's why they fought the junk fax laws so hard, when junk faxes got so burdensome that it was eventually outlawed.
The task is of course inside the corporation's control. Getting the queuing software under control can be a bit of an adventure.
It's deliberately designed to be confusing, to give different lobbyists different things they can point to as successful or agreeing with their beliefs. It leaves the whole mess in the hands of the bureaucrates, with wide leeway on their part to "guide policy" or buckle under to pressure from their own governments or exert pressure on each other. It's typical bureaucratic weasel wording, much like sexual harassment policies. It looks like a lot of guidelines, but they're so flexible and masked that no action need be taken unless a company feels like it.
It's not the code. The code copyrights can be worked around by developing a distinct, unique implementation from the specifactions of the protocols.
The problem is patents for things like MP3, which are used extensively by music players and audio playing software and websites for the material. "Removing infringing code" doesn't help a patent violation, and the open source folks don't have the finances to implement a new protocol to replace that used by Ipods and other proprietary players.
Get over your excessively libertarian self. MAPS can cut easily 40% off your incoming traffic, all but a very rare message spam. This takes a serious load off your mail server that is better used for other purposes, like actually storing and sending and serving people's email. That collateral damage is quite large and costs quite a lot of money and time if you don't find some way to block it from your users. The very occasional blocked legitimate email can be whitelisted by IP address on the recipient's part, or the sender can get their ISP to shape up. But failing to block it outright simply wastes everyone's time.
The spammers also purchase other netblocks or IP addresses. Most ISP's or colocation facilities will happily sell you as many IP addresses as you want to pay for, and thus the spammer need not move a thing. They remotely activate another IP address hosted by the same facility for sending their spam.
This is swatting flies with a shutdown of all roads leading to the swamp that generates them. While a victimized customer of the ISP feels hurt, it's almost invariably true that the ISP has been failing to police their own address space. The spammers will jump around the IP space of such a provider: this has been repeatedly demonstrated for years.
Blocking the whole IP space gets the ISP to sit up and take notice, and actually allocate manpower to the problem or assist them in dumping the spamming customer. Look at the old records of the "cyberpromo.com" to show how reluctant some ISP's have been to dump customers who continue in such spamming behavior, even when it's clearly illegal and abusive.
No, it's not. As long as the kernel "uname" remains the same, the source isn't too wildly, and the .config is consistent, the actual name of the RPM package or the labeling information allows inter-operability.
Trust me, I tried that stunt with a number of kernels years ago and it worked just fine.
Yes, they do. Radio exists, even satellite TV's in the village centers of very poor communities, and many of them do try hard to get their children some education. Don't underestimate the ability of the poor to see, and understand and envy, the world of the wealthy and powerful.
That resembles the problem with Sun's "YellowPages" service, that they were forced to rename "NIS" due to trademark violations with a British company. The courts take trademark violation quite seriously: given the shaky funding and support for ZetaOS, you might actually be able to take their nice venture-capital funded super-laptops away from their sales agents.
The UNIX underpinnings are really, really helping keep the open source tools available to Apple. Portiing from Linux to BSD variants and back takes work, but is feasible. Porting to Be and back would have been painful at best, especially due to the closed source.
The 10 second from power on to prompt is a flat-out lie. The BIOS screen alone on a typical motherboard takes at least 20 seconds, longer if it has SCSI and SATA or other unused boot options it needs to scan for. And you really have to count that as part of the turn-on time from power-on. Now, Windows XP also does a lot of operations when first starting up that make it nearly useless until they complete, such as its indexing of the hard drive. So you get a login prompt, but it's a smaller lie. The system isn't really ready to operate for some noticeably longer period until those boot operations complete, but it's going on in the background. This is typical Microsoft behavior, by the way: deliver what is basically adware ASAP, deliver the usable stuff later when you get around to it and the custoomer has already bought in. Linux, like other UNIX descendants, does its boot time setups in serial fashion. They can be heavily parrelized, which has led to some interesting optimization tools for exactly this purpose, and this cuts the heck out of boot time, but it's been left serial on the grounds that it's much easier to code for and maintain and debug.
sure, after 3 minutes wasted staring at the BIOS scanning for non-existent hardware and boot options that you don't want. SCSI device scanning, SATA, ntwork boot, floppy, all the IDE ports, and all the random memory and other hardware scans that get run add insult to injury as part of the typical boot setup. This can be reduced wildly by using the new Linux based BIOS's, but so far vendor support for them has been grudging at best, and vendors like AMI have non-discluser-agreements signed with their major board manufacturers on both the API's used by the motherboards and the API's on the tools to reload the BIOS, so it's difficult to break into that market.