Why break them? Just to please the Linux crowd? If you need GNU tools, hey most of them are bundled with Solaris 10. Others can be downloaded and installed a la carte.
Perhaps because they want to stop acting selfish & acknowledge that the rest of the industry has standardized on something they didn't write?
You have no idea how frustrating it is to try to move tar files (for example) from any other *nix to a Sun system (Sun's tar has a path length limit, and will declare tar files invalid if it has paths it has problems). It's also a pain to try to move scripts between systems: grep is different, ar is different, sed is different.
Better yet, have you tried to configure && make an app that's expecting the GNU toolset (things like sed or grep) in its makefile? I'll often have to play path games to keep GNU-expecting tools from breaking on compile....then I have to play the opposite game because SUN's tools won't work with the GNU ones. This bites, and it has me moving off of Solaris. I should not have to play path-games (or binary renaming games) to be able to have a system that can compile common software and still be able to patch.
In case it wasn't blindingly obvious, moving around in space is hard. Your decision matrix is *far* larger than 2x2...there is no given that the application itself won't cause further problems.
Imagine doing something that requires fine motor control (like, smoothly filling a space with fairly sticky stuff) under the following conditions:
Your entire body is encased in a bulky 100-lb suit.
Your hands are encased in enormous gloves that are effectively oven mitts.
Any force you exert against the surface you're trying to fix results from you getting pushed away from it (Yay, Newton), and then pushed back by the shuttle arm you're standing on. Since this force isn't drowned out by a large constant force (they're in free-fall, after all), you end up bouncing around every time you touch anything.
If you fall (ie, come dis-connected from the shuttle), you're going to die a slow, horrible death.
If you screw up and do more damage, you just killed yourself and everyone with you.
If you screw up and just slightly mis-apply the goo, you might kill yourself, and everyone with you...we don't know because we've never tried it.
There's only so many procedures you're going to get under those conditions, and none of them are something you want to do unless there is no other choice. This isn't simple matrix management...this is fairly complex risk analysis. Naive criticism that they need to "rethink the repair procedures" conveniently leaves out the whole bit where this is hard.
While I'm not a fan of T-Mobile (their handling of the Sidekick compromise while I had one was a major factor in my leaving them), I'd at least consider the iPhone if it were on T-Mobile. AT&T? Never.
Just for fun, try running SIP or H323 through a stateless firewall sometime. Since you're advocating stateless firewalls, I can tell you've never tried....it doesn't work.
SIP, H323, and a bunch of other protocols that are starting to be used regularly as business needs, dynamically allocate ports. You won't know what ports you'll need to allow through the firewall, since they'll be different for every connection. The only way this works is if your stateful firewall understands enough of the protocol to learn which ports it's expecting to see a response on. (In the case of H323, the response may even come from a totally different IP.)
This is precisely the problem that will continue to be the case in IPv6.
You really don't understand what SoundScan is. It's not RIAA music that's covered by SoundScan. It's *ALL* music. SoundScan is being set up to handle the royalties from a *compulsory* license for music. It doesn't matter if you don't want to be covered by SoundScan. It doesn't matter if you signed up to a major label deal. Your music, if it's covered by copyright in the US, will have its royalties handled by SoundScan.
That's why I find all the complaining about the RIAA in these threads kinda silly: it'll make no difference if you listen to indie music only. It'll make no difference in the prices the stations play if they shift to entirely indie music. *Everything* is covered by SoundScan for US businesses (or companies doing business in the US).
Copyright does not depend on publication. Once you write something, it's automatically copyrighted. These days, there's no such thing as an original work that "should not have copyright assigned" to it.
But it's still using specific parts of US law, which makes the license questionable at best elsewhere in the world. That's was the gist of my point: they reduced the US law dependence by mentioning the WIPO treaty, rather than the DMCA, but then undid their work by using US law for the User Product part again.
The license should rely on specific parts of US law as little as possible, to make it as usable as possible internationally.
Section 3 doesn't say that at all. Section 3 only covers the DMCA-like situation (now generalized to the WIPO to make it more international). It does not say manufacturers/distributors have to allow users to break the system, just that the manufacturers/distributors are not allowed to sue if you do, and they're not allowed to use DMCA-style laws to make it illegal.
Burning an encryption key into ROM and requiring binaries to be signed by it would not violate section 3, as long as the manufacturer never claimed it was a DMCA-style control. Suing someone (or asking the Justice Dept to prosecute them) for removing that ROM would violate section 3, but that's not the problem here.
On the US law front, they have made this draft better than the previous one by referencing a WIPO treaty rather than the DMCA. However, they backtracked a bit by calling out US law for the "User Product" part, which is disappointing.
That may be the intent, but I'm not sure that comes across in the wording. The wording just says:
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
There isn't any wording covering what happens for Installation Information (and Installation Information is very specifically defined to include encryption keys and the like) when this isn't a "User Product."
The rationale PDF says that this was done intentionally because some government groups specifically did not want the ability to modify the source code of some of thier devices...to me that sounds like they are intentionally saying exactly that you get to tivo-ize non-user products.
1) I think you're missing my point: I'm not concerned about companies being able to go after home devices used in the corporation. I'm concerned about manufacturers using the "it's not for the home" exemption to avoid those terms of the license alltogether.
2) So Novell signing a MS-style patent deal with a patent shop (ie, only Novell customers won't get sued) is okay? I really doubt that's the intent.
A few thoughts from a *very* quick read of it:
* They mention you need to supply "Corresponding Source" (eg, signing keys for Tivo-ization) to all "User Products" but defined "user Products" to basically mean anything that goes in the home. So business-style rack appliances that are not designed for the home can Tivo-ize at their leisure. This is apparently intentional, according to the rationale pdf. This seems....messy, and a huge potential hole.
* Moving away from calling out specific parts of the US code for the anti-DMCA parts and over to calling out the WIPO is a bit better for international users of the GPL, but they then call out US code again in the definition of a home device. This is problematic. Defining a for-the-home product in other countries will be difficult. (What do we do for this license in countries that have no such distinction?) They seem to acknowledge this in the rationale PDF, and say that they're evaluating it.
(Personally, I think these two issues are just the beginning of the uglyness with the anti-tivo-ization stuff, and they'll eventually be forced to drop these clauses in the name of sanity, but that's just me.)
* The anti-Novell portion is *incredibly* confusing. There has to be a better way to say that. It seems to be written just to target Novell and the specific thing Novell is doing, which I think invites problems. For example, what if the third party you make a deal with isn't in the business of distributing software? (such as the patent/IP houses that exist all over the place) Is a "we won't sue your customers" deal okay then? This section needs a *lot* more thought.
Honestly, I'm more productive with Debian than I am with other Linuxes (at least with Deb as a server). I don't want to have to go through the testing cycle every couple months to upgrade. I've got stuff to do, and babysitting a constant upgrade cycle is not one of them. Debian's policy of not changing software versions inside stable means I know that APIs will remain stable and fixed until I do a full upgrade, which is a good thing for me.
I like that Debian is slow to update things. My job is not to babysit servers...it's to make s*&t work. If I don't have to mess with a server, and can count on it working reliably for long periods of time...yay.
You know, I used to be one of the very people you're talking about: I was running gentoo on a Powermac 7200 (PowerPC 600-series arch, 120Mhz CPU, 64MB RAM) and using it as a DNS, mail, and web server.
I bailed on Gentoo years ago due to problems with the distribution. Examples: Bind 9 was masked in portage for a year and a half after it's release due to a conflict with another package...which was trivially fixable, but no one would accept the patch; bugs in the builds for my arch were ignored since it was a rare setup; and compile & install times were insane (the initial install took 4 days to finish compiling).
It's nice to say that Gentoo's the place to be for rare architectures, but my experience was that it was more trouble that it was worth. For rare architectures, I think Debian's a better bet.
The constitution does not exist to protect you from the hatred of others. You are free to speak your mind. So are the people who disagree with you. This is how it should be.
Whistleblowers and informants are a case where the privacy of a source should be protected by the government officials that they are working with, but that is not a constitutional right. Again, this is how it should be. Whistleblower's treatment need to be balanced against the rights of the accused. An incredibly important right in the constitution is the right of an accused person to face their accuser. Anonymous whistleblowers risk violating that right of the accused, which is a terrible thing and ripe for abuse.
The BlackHat speaker isn't presenting it as new...what he *is* doing, though, is giving away schematics to build devices to do the reading and cloning. That's what's getting HID's attention. Lots of people knew you could do this...not so many had a clear schematic & parts list to actually go *do* it.
You have approximately 1500 servers, and you're not automating patches and server management...exactly...why?
Applying the patch to systems in batches is totally reasonable (if something goes wrong, you limit the number of explosions you're dealing with at any one time). Doing them all by hand, one by one, is totally insane.
NAC isn't really about preventive security, no matter how it's billed...it's sold as a security tool because that's the only way to get the bosses to understand that real security comes from being *organized* and consistent all the way down to the patch levels on *every* *host*. NAC doesn't fix broken machines...it does help you keep organized about what your non-broken machines look like, so that you minimize the number of broken ones.
Slashdot Mirror
Why break them? Just to please the Linux crowd? If you need GNU tools, hey most of them are bundled with Solaris 10. Others can be downloaded and installed a la carte.
Perhaps because they want to stop acting selfish & acknowledge that the rest of the industry has standardized on something they didn't write?
You have no idea how frustrating it is to try to move tar files (for example) from any other *nix to a Sun system (Sun's tar has a path length limit, and will declare tar files invalid if it has paths it has problems). It's also a pain to try to move scripts between systems: grep is different, ar is different, sed is different.
Better yet, have you tried to configure && make an app that's expecting the GNU toolset (things like sed or grep) in its makefile? I'll often have to play path games to keep GNU-expecting tools from breaking on compile....then I have to play the opposite game because SUN's tools won't work with the GNU ones. This bites, and it has me moving off of Solaris. I should not have to play path-games (or binary renaming games) to be able to have a system that can compile common software and still be able to patch.
It went here. Now, don't come complaining to me about hairy palms or blindness...in fact, don't even tell me what you did at all.
Imagine doing something that requires fine motor control (like, smoothly filling a space with fairly sticky stuff) under the following conditions:
- Your entire body is encased in a bulky 100-lb suit.
- Your hands are encased in enormous gloves that are effectively oven mitts.
- Any force you exert against the surface you're trying to fix results from you getting pushed away from it (Yay, Newton), and then pushed back by the shuttle arm you're standing on. Since this force isn't drowned out by a large constant force (they're in free-fall, after all), you end up bouncing around every time you touch anything.
- If you fall (ie, come dis-connected from the shuttle), you're going to die a slow, horrible death.
- If you screw up and do more damage, you just killed yourself and everyone with you.
- If you screw up and just slightly mis-apply the goo, you might kill yourself, and everyone with you...we don't know because we've never tried it.
There's only so many procedures you're going to get under those conditions, and none of them are something you want to do unless there is no other choice. This isn't simple matrix management...this is fairly complex risk analysis. Naive criticism that they need to "rethink the repair procedures" conveniently leaves out the whole bit where this is hard.AT&T's service sucks in every area.
While I'm not a fan of T-Mobile (their handling of the Sidekick compromise while I had one was a major factor in my leaving them), I'd at least consider the iPhone if it were on T-Mobile. AT&T? Never.
Translation:
"I didn't know that Steve Jobs was going to call me and scream at me like a diseased monkey when I said that. I'm sorry Steve. Please don't kill me."
Right...so, a VoIP phone (running SIP or H323, which do this sort of dynamic port-allocation) is not something useful for work?
Just for fun, try running SIP or H323 through a stateless firewall sometime. Since you're advocating stateless firewalls, I can tell you've never tried....it doesn't work.
SIP, H323, and a bunch of other protocols that are starting to be used regularly as business needs, dynamically allocate ports. You won't know what ports you'll need to allow through the firewall, since they'll be different for every connection. The only way this works is if your stateful firewall understands enough of the protocol to learn which ports it's expecting to see a response on. (In the case of H323, the response may even come from a totally different IP.)
This is precisely the problem that will continue to be the case in IPv6.
s/SoundScan/SoundExchange/g;
sorry. typing too fast.
You really don't understand what SoundScan is. It's not RIAA music that's covered by SoundScan. It's *ALL* music. SoundScan is being set up to handle the royalties from a *compulsory* license for music. It doesn't matter if you don't want to be covered by SoundScan. It doesn't matter if you signed up to a major label deal. Your music, if it's covered by copyright in the US, will have its royalties handled by SoundScan.
That's why I find all the complaining about the RIAA in these threads kinda silly: it'll make no difference if you listen to indie music only. It'll make no difference in the prices the stations play if they shift to entirely indie music. *Everything* is covered by SoundScan for US businesses (or companies doing business in the US).
Copyright does not depend on publication. Once you write something, it's automatically copyrighted. These days, there's no such thing as an original work that "should not have copyright assigned" to it.
But it's still using specific parts of US law, which makes the license questionable at best elsewhere in the world. That's was the gist of my point: they reduced the US law dependence by mentioning the WIPO treaty, rather than the DMCA, but then undid their work by using US law for the User Product part again.
The license should rely on specific parts of US law as little as possible, to make it as usable as possible internationally.
Sorry for the delay in replying...
Section 3 doesn't say that at all. Section 3 only covers the DMCA-like situation (now generalized to the WIPO to make it more international). It does not say manufacturers/distributors have to allow users to break the system, just that the manufacturers/distributors are not allowed to sue if you do, and they're not allowed to use DMCA-style laws to make it illegal.
Burning an encryption key into ROM and requiring binaries to be signed by it would not violate section 3, as long as the manufacturer never claimed it was a DMCA-style control. Suing someone (or asking the Justice Dept to prosecute them) for removing that ROM would violate section 3, but that's not the problem here.
On the US law front, they have made this draft better than the previous one by referencing a WIPO treaty rather than the DMCA. However, they backtracked a bit by calling out US law for the "User Product" part, which is disappointing.
There isn't any wording covering what happens for Installation Information (and Installation Information is very specifically defined to include encryption keys and the like) when this isn't a "User Product."
The rationale PDF says that this was done intentionally because some government groups specifically did not want the ability to modify the source code of some of thier devices...to me that sounds like they are intentionally saying exactly that you get to tivo-ize non-user products.
1) I think you're missing my point: I'm not concerned about companies being able to go after home devices used in the corporation. I'm concerned about manufacturers using the "it's not for the home" exemption to avoid those terms of the license alltogether.
2) So Novell signing a MS-style patent deal with a patent shop (ie, only Novell customers won't get sued) is okay? I really doubt that's the intent.
A few thoughts from a *very* quick read of it:
* They mention you need to supply "Corresponding Source" (eg, signing keys for Tivo-ization) to all "User Products" but defined "user Products" to basically mean anything that goes in the home. So business-style rack appliances that are not designed for the home can Tivo-ize at their leisure. This is apparently intentional, according to the rationale pdf. This seems....messy, and a huge potential hole.
* Moving away from calling out specific parts of the US code for the anti-DMCA parts and over to calling out the WIPO is a bit better for international users of the GPL, but they then call out US code again in the definition of a home device. This is problematic. Defining a for-the-home product in other countries will be difficult. (What do we do for this license in countries that have no such distinction?) They seem to acknowledge this in the rationale PDF, and say that they're evaluating it.
(Personally, I think these two issues are just the beginning of the uglyness with the anti-tivo-ization stuff, and they'll eventually be forced to drop these clauses in the name of sanity, but that's just me.)
* The anti-Novell portion is *incredibly* confusing. There has to be a better way to say that. It seems to be written just to target Novell and the specific thing Novell is doing, which I think invites problems. For example, what if the third party you make a deal with isn't in the business of distributing software? (such as the patent/IP houses that exist all over the place) Is a "we won't sue your customers" deal okay then? This section needs a *lot* more thought.
Honestly, I'm more productive with Debian than I am with other Linuxes (at least with Deb as a server). I don't want to have to go through the testing cycle every couple months to upgrade. I've got stuff to do, and babysitting a constant upgrade cycle is not one of them. Debian's policy of not changing software versions inside stable means I know that APIs will remain stable and fixed until I do a full upgrade, which is a good thing for me.
I like that Debian is slow to update things. My job is not to babysit servers...it's to make s*&t work. If I don't have to mess with a server, and can count on it working reliably for long periods of time...yay.
You know, I used to be one of the very people you're talking about: I was running gentoo on a Powermac 7200 (PowerPC 600-series arch, 120Mhz CPU, 64MB RAM) and using it as a DNS, mail, and web server.
I bailed on Gentoo years ago due to problems with the distribution. Examples: Bind 9 was masked in portage for a year and a half after it's release due to a conflict with another package...which was trivially fixable, but no one would accept the patch; bugs in the builds for my arch were ignored since it was a rare setup; and compile & install times were insane (the initial install took 4 days to finish compiling).
It's nice to say that Gentoo's the place to be for rare architectures, but my experience was that it was more trouble that it was worth. For rare architectures, I think Debian's a better bet.
The constitution does not exist to protect you from the hatred of others. You are free to speak your mind. So are the people who disagree with you. This is how it should be.
Whistleblowers and informants are a case where the privacy of a source should be protected by the government officials that they are working with, but that is not a constitutional right. Again, this is how it should be. Whistleblower's treatment need to be balanced against the rights of the accused. An incredibly important right in the constitution is the right of an accused person to face their accuser. Anonymous whistleblowers risk violating that right of the accused, which is a terrible thing and ripe for abuse.
The BlackHat speaker isn't presenting it as new...what he *is* doing, though, is giving away schematics to build devices to do the reading and cloning. That's what's getting HID's attention. Lots of people knew you could do this...not so many had a clear schematic & parts list to actually go *do* it.
I've got to ask, since I was pondering downloading OpenQRM: what don't you like, and what other projects are there out there that do the same thing?
That sound you may have heard was the joke flying over your head.
You have approximately 1500 servers, and you're not automating patches and server management...exactly...why?
Applying the patch to systems in batches is totally reasonable (if something goes wrong, you limit the number of explosions you're dealing with at any one time). Doing them all by hand, one by one, is totally insane.
NAC isn't really about preventive security, no matter how it's billed...it's sold as a security tool because that's the only way to get the bosses to understand that real security comes from being *organized* and consistent all the way down to the patch levels on *every* *host*. NAC doesn't fix broken machines...it does help you keep organized about what your non-broken machines look like, so that you minimize the number of broken ones.