It boils too easily. I don't mean 'rolling boil' I just mean that it will evaporate very easily at room temperature even, let alone at 40degC. Once evaporated into a normal oxygen atmosphere, it is highly flammable (not that it isn't already).
Clearly you have never used OpenDirectory with non-Macintosh infrastructure components. It's no walk in the park, especially given all of the extensions they tend to do.
a) Since when do you have uid=foo,cn=users,cn=company,cn=com, and not cn=foo,ou=users,cn=company,cn=com. Albeit that's minor and not a big problem.
b) Groups are a pain, especially as you cannot (with the Workgroup Manager anyway) produce groups that are not also UNIX groups (no application/functional groups??).
c) The Workgroup Manager does not allow changing of a user's [primary] uid, and if you do it with OpenLDAP tools you may desync the group memberhips due to the apple-member-guid.
d) Many fields are obfuscated behind xml inside base64, like apple-user-mailattribute. This makes use of non-macintosh tools like postfix rather difficult. True, Apple modified their postfix (among many other tools) to understand how to use this, but using it with a standard postfix install on UNIX is a pain in the ass.
Eventually what you come back with is that OpenDirectory is great, as long as all of your servers are Macs. Otherwise, it's not worth the trouble.
This is oversimplifying the situation. the Cell is actually an asymmetrical multi processer solution, in that not all of the cores are identical. the Cell architecture consists of one central POWER (PPC?) core, and then 7 (physically 8, one disabled) SPEs. The SPEs are basically a minimal processor able to handle primarily SIMD math, and very limited logic. No branch prediction either.
That has to be one of the craziest theories I've heard yet!
To try to dispel this nutty theory, let's bring some truth to the table.
They rather have the tarball contain several compiled versions of the combined module (specific to your platform/version), and a copy of a) a source shim b) a binary blob.
If they don't have an appropriate combined module for your platform/version, they will instead attempt to compile the shim and link the binary blob into it.
By no means would they put in encrypted source, as some smartass would just figure out how to intercept the files while they're decrypted.
It depends in large part on how large the caches would have to be (and where they'd have to be located), and the hit-rate. I think that the cache hit-rate would be high on maybe a state-by-state basis, but might be less so on a per-neighborhood basis (the 'last mile').
There is more bandwidth at the 'last mile' (as a sum total) than the total bandwidth of the core.
To try to hedge my bets a little, I'm going to try to define the above statement more effectively: There is more bandwidth at the cable local-loop than there is at the uplink from the loop to the internet at large. There is more [non-burstable] bandwidth on the 'premises side' of the DSLAM than there is on the uplink side.
The last mile might need more work, but what we need even more of is increased uplink capacity between the 'last mile' and the greater cloud. Light up all of that fiber that was laid by the telcos in the last 15 years.
Inaccurate. It does require shell access, but it does not require it to be physically local.
A 'local root exploit' only means that you have to have a shell of some kind first. This can include an SSH shell account. This can also include any kind of non-root shell exploit.
Say that you can exploit some webapp to get a shell as wwwrun/apache/www. That combined with a local root exploit to get root. It doesn't even need to be a DIRECT shell exploit. Perhaps your hack/program opens up a port with telnet listening.
Thus all 'local root exploits' are potential remote exploits, if we allow for chaining. Chaining can be used by anyone who isn't just a script kiddie. Hell, you could probably make an auto-rooter that will chain the exploits.
Wondershaper can be a wonder, tho I have found that it can be improved somewhat by rewriting the concept in perl (Python should work too), rather than bash. Makes it more flexible. Use your language of choice of course, so that you understand it.
IPtables cannot do shaping, although you can use it alongside iproute2/tc with MARK.
The idea I get is this, and this only applies to the OEM versions of Microsoft Software (where they provide a discount to the OEM).
The judge says that businesses that have not used the Software Licenses, and thus aparrently not agreed to the license, cannot transfer the license. Only upon acceptance of the license terms does the ownership of the license begin.
Further, the license terms forbid the transfer of the license w/o being attached to a piece of hardware (some businesses have gotten around this by attaching an IDE cable or network card).
Thus, w/o acceptance of the terms one does not own, and the terms disallow transfer. This does assume that those terms are enforceable and legal, but that may not have been at issue here.
Improbable. Did you forget all about web vhosting? Big porn sites are spread across multiple boxes and IPs. Small porn sites are multiple sites per IP. http://www.sportsillustrated.com/ 64.236.55.99 64.236.55.185 http://64.236.55.185/http://64.236.55.99/ Further, many links may end up being absolute with domains.
Unfortunately, they asked what is effectively a biased question, due to the phrasing. I'm not an expert (geez, who is on/. ), but that looks like a biased phrasing in order to try to get a certain response.
In Linux you don't (need)/use iptables. However, for resources, http://www.lartc.org/ Their Wondershaper is a good start, but can be improved upon, or extended.
Since it's all handled by the software, the 8th SPE will never be used (unless some guy decides to do that with the Linux port... but each application has to be able to know if it has an 8th, and then use it). So not disabling it wouldn't really mean enabling it, if you get my drift.
Plus there was Corel Office 2000, tho I'm not sure that they ever _finished_ that project. Meanwhile, Corel made a lot of contributions to WINE during that timeframe.
Slashdot Mirror
It boils too easily. I don't mean 'rolling boil' I just mean that it will evaporate very easily at room temperature even, let alone at 40degC. Once evaporated into a normal oxygen atmosphere, it is highly flammable (not that it isn't already).
I dunno, the old spec did allow for repeaters on a thinnet network.
That and GPL isn't a use-license, but rather a distribution-license.
Oops, I messed up the DN. should be uid=foo,cn=users,dc=company,dc=com and cn=foo,ou=users,dc=company,dc=com
Clearly you have never used OpenDirectory with non-Macintosh infrastructure components. It's no walk in the park, especially given all of the extensions they tend to do.
a) Since when do you have uid=foo,cn=users,cn=company,cn=com, and not cn=foo,ou=users,cn=company,cn=com. Albeit that's minor and not a big problem.
b) Groups are a pain, especially as you cannot (with the Workgroup Manager anyway) produce groups that are not also UNIX groups (no application/functional groups??).
c) The Workgroup Manager does not allow changing of a user's [primary] uid, and if you do it with OpenLDAP tools you may desync the group memberhips due to the apple-member-guid.
d) Many fields are obfuscated behind xml inside base64, like apple-user-mailattribute. This makes use of non-macintosh tools like postfix rather difficult. True, Apple modified their postfix (among many other tools) to understand how to use this, but using it with a standard postfix install on UNIX is a pain in the ass.
Eventually what you come back with is that OpenDirectory is great, as long as all of your servers are Macs. Otherwise, it's not worth the trouble.
This is oversimplifying the situation. the Cell is actually an asymmetrical multi processer solution, in that not all of the cores are identical. the Cell architecture consists of one central POWER (PPC?) core, and then 7 (physically 8, one disabled) SPEs. The SPEs are basically a minimal processor able to handle primarily SIMD math, and very limited logic. No branch prediction either.
That has to be one of the craziest theories I've heard yet!
To try to dispel this nutty theory, let's bring some truth to the table.
They rather have the tarball contain several compiled versions of the combined module (specific to your platform/version), and a copy of a) a source shim b) a binary blob.
If they don't have an appropriate combined module for your platform/version, they will instead attempt to compile the shim and link the binary blob into it.
By no means would they put in encrypted source, as some smartass would just figure out how to intercept the files while they're decrypted.
It depends in large part on how large the caches would have to be (and where they'd have to be located), and the hit-rate. I think that the cache hit-rate would be high on maybe a state-by-state basis, but might be less so on a per-neighborhood basis (the 'last mile').
There is more bandwidth at the 'last mile' (as a sum total) than the total bandwidth of the core.
To try to hedge my bets a little, I'm going to try to define the above statement more effectively: There is more bandwidth at the cable local-loop than there is at the uplink from the loop to the internet at large. There is more [non-burstable] bandwidth on the 'premises side' of the DSLAM than there is on the uplink side.
The last mile might need more work, but what we need even more of is increased uplink capacity between the 'last mile' and the greater cloud. Light up all of that fiber that was laid by the telcos in the last 15 years.
Inaccurate. It does require shell access, but it does not require it to be physically local.
A 'local root exploit' only means that you have to have a shell of some kind first. This can include an SSH shell account. This can also include any kind of non-root shell exploit.
Say that you can exploit some webapp to get a shell as wwwrun/apache/www. That combined with a local root exploit to get root. It doesn't even need to be a DIRECT shell exploit. Perhaps your hack/program opens up a port with telnet listening.
Thus all 'local root exploits' are potential remote exploits, if we allow for chaining. Chaining can be used by anyone who isn't just a script kiddie. Hell, you could probably make an auto-rooter that will chain the exploits.
Stupid idea. Flash has a limited number of write-cycles. Swap would burn through them in no-time flat, even if only in isolated spots.
Lookup Huffman Encoding. It's been done.
Feel free to do the math. the short answer however ((2**36)/(2**30)) = 2**6 = 64. Either that table is wrong, or they're using some other technique.
Also feel free to check that PSE/PAE is 36bits.
Prescient, not precient
From answers.com
Just wait. Somebody will patent this procedure being performed on the INTERNET!
not iptables so much as iproute2/tc.
http://www.lartc.org/Wondershaper can be a wonder, tho I have found that it can be improved somewhat by rewriting the concept in perl (Python should work too), rather than bash. Makes it more flexible. Use your language of choice of course, so that you understand it.
IPtables cannot do shaping, although you can use it alongside iproute2/tc with MARK.
That's obvious if you read the URI. It's a mailing-list archive, and it keeps copies of attachments.
No wrongdoing involved by GNU, tho perhaps they should delete that message.
Recommend SVN. Should be much more subversive.
Also consider git.
The idea I get is this, and this only applies to the OEM versions of Microsoft Software (where they provide a discount to the OEM).
The judge says that businesses that have not used the Software Licenses, and thus aparrently not agreed to the license, cannot transfer the license. Only upon acceptance of the license terms does the ownership of the license begin.
Further, the license terms forbid the transfer of the license w/o being attached to a piece of hardware (some businesses have gotten around this by attaching an IDE cable or network card).
Thus, w/o acceptance of the terms one does not own, and the terms disallow transfer. This does assume that those terms are enforceable and legal, but that may not have been at issue here.
Improbable. Did you forget all about web vhosting? Big porn sites are spread across multiple boxes and IPs. Small porn sites are multiple sites per IP.
http://www.sportsillustrated.com/
64.236.55.99 64.236.55.185
http://64.236.55.185/ http://64.236.55.99/
Further, many links may end up being absolute with domains.
Unfortunately, they asked what is effectively a biased question, due to the phrasing. I'm not an expert (geez, who is on /. ), but that looks like a biased phrasing in order to try to get a certain response.
Still works with GNU tools (I did say above 'no text'. Damned /. anti-lameness filter).
Tested OpenSuSE 10.0, debian sarge.
In Linux you don't (need)/use iptables. However, for resources, http://www.lartc.org/
Their Wondershaper is a good start, but can be improved upon, or extended.
Since it's all handled by the software, the 8th SPE will never be used (unless some guy decides to do that with the Linux port... but each application has to be able to know if it has an 8th, and then use it).
So not disabling it wouldn't really mean enabling it, if you get my drift.
That's cellulite, not cellulose.
Plus there was Corel Office 2000, tho I'm not sure that they ever _finished_ that project. Meanwhile, Corel made a lot of contributions to WINE during that timeframe.