In fact, I think that we need to go further, and insert a clause saying that you lose the right to even USE any software licensed under an OSI license with this clause in it if you file a patent, trademark, or copyright lawsuite
That's not feasable. The liscence gives you extra rights, essentially to right to make copies, if you agree to certain terms. Copyright permission is not required to use something you have. It is agreed that one does not need to agree to the GPL to use GPL'd software. However, you do not have the right to distribute the software unless you do agree.
Now, a rights management engine, given legal status through the DMCA, is quite another item. But no source code would ever be distributed with such a mechanism in place (it's technological infeasable, and certinally pointless for open source software).
Therefore, the termination clause above is as strong as it gets, in terms of penelty.
In terms of application: To terminate on fileing of a copyright filling would bne very dubious ground indeed. The liscence relies on copyright law to exist, and have any effect. If you prevent anyone else from actually claiming copyright infringment, then you are denying them any chance to use the same rights you are. Consider a case where two different groups both release open source, and a copyright violation between them. It gets very complex, very fast, if there have been external patches included in those software packages.
Note that the license comtains the qualifier 'essential to use'. Is SMP code 'essential to use' Linux? I'd argue not (I don't use it, on any of my machines). Therefore would the clause come into play?
Further more, SCO have not filed any claims that and open source softare is in copyright violation (as far as I'm aware). They claim IBM breached contract, and that's none of the things you mentioned.
Trademark protection has many good points - it stops someone else from pretending to be IBM. If you remove that (which, preventing people from fileing a cliam would effectivly do), do you really want the situation where you have no idea if the Apache webserver you are using is nothing to do with the Apaches we are all familiar with? I do not think that that would be a good thing. It can be abused, granted, but on the whole, it's core intent remains a good one. I cannot say that about the majority of software patents
Absent NDA, I don't think that SCO could stop you copying thier code, that you legally had in your possesion, for the purposing of judging your own exposure. Note that it is always legal to have GPL liscenced code in your possession, whether or not you agree to the liscence. This situation does not apply to most commercial liscences.
Obtaining a copy of the code by industrial espionage really pollutes the 'good faith' fair use claim. Note that in your second paragraph, your talking about distributing the code, rather than for direct risk management - again, further complicating the situation.
Also, SCO are claiming trade secret violation, not copyright violation. That's a significant asymetry in the legal standings between the two sides. There are no fair use exceptions in trade secret law, as far as I am aware.
I think [0] if you were to obtain SCO's 'evidence' by espionage that they would be able to slap you with a preliminary injunction against spreading the information about, on the grounds that they have minimised distribution pre-discovery. Judges are quite keen to let the courts work the way they were intended, and, coupled with a trade secrets case, I can't see any reason for the judge not to grant an injunction. Note that SCO can claim that the NDA also protects the Linux code - they are minimising thier breach of copyright, which is useful to support a fair use claim.
In short - what you are talking about would fall foul of more than just copyright issues, and there is a fair use exception only for copyright.
[0] Disclaimer: I'm not lisceced to practice law in the USA. This is not legal advice, blah blah blah
Re:GPL question
on
Settling SCOres
·
· Score: 2, Interesting
In general, you are correct.
However, three matters apply here. Firstly, SCO claim that it is thier code, which means that if they are correct, it is not GPL. This complicates things, and I don't know USA law well enough to say what that means.
Secondly, SCO are not distributing the Linux code, but rather pointing to parts of that that have special relevence. They did not give out copies, but rather pointed to a single printout. Thus, no distribution was taking place.
Thirdly, and I think, strongest - Fair use rights. SCO cannot make a claim without replicating those parts of the code. The fair use exception applies, allowing them to quote 'reasonable parts' of the Linux code, to illustrate thier claim.
Note that the latter cut's both ways - if you were in possesion of SCO's source, you could calim fair use over quoting parts, specifically for the purpose of backing up or refuting thier claims.
I'm not liscenced to practice law in your juristriction - this is not legal advice. For legal advice, consult a local lawyer.
Oh, dont' get me wrong, I know there were lots of technical reasons why this one took so long (the new IDE layer in prep for more IDE drivers, particularly for the new chipsets).
The fact is that 'a few weeks' is substansialy shorter than the norm for a stable kernel at this point.
The random political philosophising was just me pushing some thoughts around, and seing what fell out.
Marcello (and Linus) are probably some of the least politically motivated engineers I'm aware of.
Now, what's particularly interesting is that it's arrived right at the dead time between SCO treatening to do something, and actually doing it.
If I wanted to thumb my nose at SCO, I'd release a kernel right now (probably call it the "recumbant bicycle" release, or something). Of course, the dev time for the stable series is so long, that it's just coincidence - right?
So why did Marcelo say he was planning 2.4.22 in a few weeks?
If SCO's aim is to hurt linux, I think that they just got a good demonstration that the engineers (who, in terms of OSS, are the only ones who count) don't care about them.
Sepcifficaly, given the dearth of informatiuon so far, I'm assuming it's a block decomposition style, so what seperates it from all the other block based codecs?
Namely, by removing the neutron source, the evidence for the breed isotopes would have declined. Return the neutron source, and the evidence would have returned.
Now, I can't claim that this occured, as I wasn't there. However, I can recall that a member of staff from the nuclear physics group was called in, and was convinced that they had a working breader reactor going. Given how simple it is to prove that the reactor was having an effect, and that a breed isotope was observed, I think that I must go with the reacotr team.
Nota Bena: Recall that a breeder reactor is one that manufcatures fissionable material from aterial that is not fissionable, generaly taken to mean that the reactor makes fuel for itself, but not nessecerilly (a pair of coupled reactors are still breeder reactors). They did not produce plutonium. They breed U-233 (A fisionable material), from thorium. Essentially, they noted that bombarding thorium with neutrons would result in manufacture of U-233, and that U-233 is theoretially fissionable (Not actually used anywhere). This is falsifiable - you could disprove this (theoretical) step. Next, they made a neutron generator from an alpha source, and put the two in sequence. Then they borrowed some gear (I forget what) to detect the emission from U-233 decay.
In short, no one claims they made Pu, except you. Therefore assertations that they could not have made Pu is a straw man argument.
Aside: The reason that this reaction is not exploited commercially is down (to a large extent) to raw materials. There is a large, cheap source of pure (as in, isotopically pure) U-238, as a result of U-235 programs (weapons and reactors). Thus breeder research was focused on using up that U-238 as much as the principle of breeder reactors.
Yes you could do this for other hardware plaforms.
However... most other CPU's have had the ability to use writable but not executable and executable but not writable heaps for a while. x86 does not. This is why you get a whole bundle of problems with it, as buffer overruns write code in the heap, then get it executed. The patch is an atempt to mitigate the adverse effects of that hardware weakness.
It's not perfect (nor is the better hardware solution). However, it will make many exploits an order of magnitude more complex, making writing and utilising them a much more complex task.
The part about locating code inside the ASCII armour is, however, zero overhead, and will, I think, get wrapped into mainline on all archtectures (although possbily not till 2.7)
... assuming that the stack memory is marked as executable in the binary - which will have the net effect of turning off the Exec-shield.
In other words, ELF format has flags to indicate if the stack should be readable and/or executable. If your doing that sort of thing, make sure that the flag is set, and you'll have no problems [0].
It your doing those sort of tricks, your probably being very careful with what goes where, and buffer lengths and such. The problems come in when people don't realise that there could be a problem, and don't audit the buffer handling code properly.
So, don't worry, just use the ELF flags.
[0] Well, you could set the feature to ignore what the binary says, and implement the security anyway. But that's not a good idea, and very much not default.
It's a well understood mathematical principle, and is used in networking. Actually, FEC is a little broader than what I mean.
What I am talking about is algorithms for spliting a data packet up into m parts, and allowing recovery of the whole with any n of those m (n < m). For example, one such algorithm is the Tornado code, used by Digital Fountain for multicast file distribution.
Here, the application would be somwhat different. You'd take your private key, and split it into m semi-redundant sections, by, well, any of the FEC algorithms you like. Encrypt each part with the individuals public key, and there you have it.
I'll go back to my information theory stuff, and patch together something.
Thank's for the heads up. It's one of those things that once it's pointed out, it's so clear, I can't believe that I didn't see it before.
Note that this would require m+1 encryptions (1 main key, split over m encrypted sections), and n+1 decryptions (n parts brought together, and the manin key). That's a hefty price, but you want to ensure that no person can see part of the private key. This is because (if you want an n from m stratagy in the first place) you do not completly trust the private key holders, so you do not want to give them part of the major key directly.
Hmm. Come to think of it, most FEC codes currently do not have that as a design criteria (but I reckon that one like that could be found). From memory, however, most of the more sophisticated codes have that as a side effect, which results from the even distribution of data between the m packets.
The only other alternative scheme I thought of... well wasn't really. I think that there might be something clever that you can do with RSA, by playing around with products of exponents in Fermats Little Theorum. But I've not got round to pusing the algebra around yet.
Forward error correction - damn, but that's so obviously correct.
If I get a fully working algorithm (or, rather, protocol for utilising the algorithms) I'll stick it in my journal.
Sort of, but the security gained can be gained in other ways, for less cost (in terms of operator time and computer time).
In general, assuming a rock solid algorithm, you will not gain anything by using two 1024 bit keys, over a 2048 bit key.
In practice, I suspect that with any actual algorithm, the 2048 bit key would be more secure. This is becuase there entropy in the key is not evenly distributed, but is concentrated in the higher order bits. So by having two sets of low order bits, you have less entroy than you think in the key - which translates directly into less time to crack. [0]
So, it won't improve the algorithmic security over a twice as large key. There are, I think, just two other reasons for considering this.
If you use two different algorithms, then you might be able to cover a weakness in one algorithm by wrapping it in another. Frankly, just use a better, single, algorithm. There are plenty that have been shown to be secure, and there's not advantage to faffing around like that, unless you believe that the NSA have s00p3r s3kret decrypters for a particular algorithm. In which case, grab a tinfoil hat, and hack PGP so that it does not ouput any framing information on the encrypted data at all (to prevent algorithm identification). I think all your achieve is to make it difficult for people to send encrypted information to you.
However, there is, I think, a reasonable algorithm for using two different keys. If you store them differently, and access them differently, then you can make it twice as hard for someone to steal your private key. So, for example, you might have a private key on a USB keychain, and the other on hard disk. If only one of them has a pass phrase, then it can be very difficult for, e.g. a keyboard sniffer, to identify that there are two keys.
There are other solutions to this, which would not require double encryption though. Primarily, you could encrypt one key with the other, achieving a similar degree of operator level security, without the overhead [1] on others, making it far more likely to be sucessful. If it's too complex for others, then they may well just skip the encryption altogether.
Encrpting one key with another is also how I would implement a 'need both people to decrypt' schema.
(Aside: Anyone know of a method that would allow for a 'any n of m keyholders needed to decrypt' schema? It's something that has advantages, but I've no idea how to go about it)
So, unless there is some purpose to the double encryption that I've missed (i.e. you ment something by 'secure' other than what I covered above), it nets you nothing over simpler methods.
[0] Note that this applies only to asymetric (public key) encryption schemes, such as RSA, DSA etc (key lengths around 1024 bits), not to symetric ciphers, such ad blowfish or 3DES, with key lengths of around 128 bits.
[1] And remember that this overhead is not so much for yourself, who can cope with it - but for those who wish to send you messages. If you are just encrypting files for your own use, then alternative solutions (a symetric cypher, or one time pad) have advantages.
It's a fairly simple system. You stick an oscillator of known frequency (32.768 kHz in this case) on the chip, and then use that to count the inputed clock rate.
If you count too many clock pules to each refference pulse, then you can modify behaviour on the basis of that. I's interesting to note that the patent talks about CPU's going as fast as 500 MHz, and talks about 1995 as recent. So all the talk about dodgy resellers was probably topical way back when it was written, when, if I recall, there were a few resellers overclocking chips on the quiet. I think that this is a patent whose time has come and gone.
More worrying, it talks about under-clocking detection, as if it's a symptom of faulty hardware. Well, my recent brush with a failed fan ment I underclocked my CPU, to alow it to function without overheating - I sincearly hope that Intel doesn't intend to prevent that.
According to BBC radio 2, Amazon have decided not to honour any orders placed.
Unfortuantly, no web link yet, and the radio was somewhat lacking on detail, but they implied that no-one was going to get one at that price.
This wouldn't be the first time that a retailer has renaged on an online deal, offereed in error. A couple of years ago (Sept 1999), Argos offered a £300 TV for £3. They refused to honour it, and I'm not aware of any legal rammifications for Argos.
So, looks like this will be just another one of those curiosity stories.
A remote exploitation means that if your are connected to the internet, (And, in the case of a server deamon, running the affected daemon), then a remote attacker (== only using net acesses) can obtain root privs.
A local exploit menas that the attacker must be first logged in as a local user (i.e. have a valid account, or have exploited a server daemon to obtain local, unprivildiged access).
Attacks that require you to have physical acess to the box are generally not classified, as these will always exist (through boot disks, etc), and as thus not audited for.
It is a common practice to use an insecure deamon to first get local acess, then to use a local root hole, such as this one.
Hope that helps - the jargon is dense, but useful.
Over the past year or so, we (meaning my academic group) has purchased around 20 000 UKpounds (around $26 000 dollars) of computing equiptment.
A 16% tax would mean 16% less computing power available. It would mean that 16% less work could get done. It would mean 16% of each grant gets wasted (from the POV of the group funding the reasearch).
Thank goodness the UK's fighting this one.
Also, they'd have to define computer. However they do it, I'm quite sure that there's at least one of the boxes I use would fall outside the definition. If it's x86 / PPC only, then looks like everyone will be buying Sun Blade 100's. If it's per CPU, then do we get taxed 4 times for our Alpha? What about if we install one of the cute PC-on-a-PCI card in one of the Suns? Is that a new computer, or not? It's an ASMP box, two CPU (USparcIIe and Celeron), two OS, one hard disc machine.
And just consider what it would do for a $1 million supercomputer. Or for a 32 node beowulf.
I don't know if fermenting wood would be sustainable. I don't think that it would be ultimatly.
Methanol is as "clean" in use as hydrogen would be, in a fuel cell environment. Ok, you still get CO2 produvtion, but that's being recirculated, not realeased from fossil fuels, so it's not making global warming worse. In an internal combustion engine, you potentially get nitrous oxides, ozone etc (as with any internal combustion engine).
With methanol it's slightly more complex to manufacture. Which you do in four or five places. It's significantly easier to transport and store, which you do in millions of locations. That's the pay off. You centalise the complexity, and keep the interface to it as simple, and familer, as possible.
Methanol is currently manufactured in significantly larger volumes than hydrogen is. I can't quote exact figures, but in our building the best guess is that we go through 1-2 moles of H2 a month, and 30-40 moles of methanol a day, in various uses. That is, the extra complexity in manufacture is marginal, and the gains in transport and use are great. I don't have the numbers to hand, but I'd bet the current cost's make methanol cheaper, per joule of stored energy, than hydrogen. Certinally, I know the bean counters worry over hydrogen costs, but not over methanol costs.
It's not about being the best - its about trade-off and good enough. The biomass fuel sources of methanol are a side benefit - the reason to transition is cost.
Also, methanol can be poured into a very nearly standard desil engine, and just work. I belive than changes are mostly tuning related, so aught to be able to be done by any mechanic. That's one in the eye for hydrogen, which _doesn't yet_ have a working engine in mass production.
Or, more or less, the ease of use and transportation would, in my opinion, more than make up for a slightly increased complexity of manufacture.
You can't supply all of the fuel for everyone from agricultural land. Well, you might be able to, but it's definitly well into the "probably not even theortically possible" territory.
That aside, I proposed it as a supplement to large plant production of methanol. This approach is well suited to small, local production of fuel - something that's not possible under either gasoline or hydrogen fuels.
Don't look at it as the sole production method. If you do, it looses (see Brazil's ethanol powered cars - oil was so much cheaper, they gave it up). No, it's an arguement why methanol is better than hydrogen. If your going to replace your principle portable fuel, might as well go for the best.
That said, you wouldn't grow corn for methanol as a fuel. I'd be growing pine trees (quick growing, low maintinance. You plant them, thin them a few years later, and then harvest). This grows on quite different land to corn, so nets you slightly higher overall land utilisation. Also, the straw that's not used from the corn can get chucked into the fermenter as well. But eat the corn - that's what its for.
If fermenting the straw cuts your fuel bills in half for growing it that's a win.
Let me break down the 5 areas that they say need R&D. I accept that these are the main problem areas. However, consider the alternative, of methanol powered fuel cells.
1. Solve the hydrogen fuel-tank problem.
However you do it, it's more difficult than storing gasoline. With methanol, it's eactly the same problem. Bush should devote $0 to this problem, and instead point to the current solutions for oil.
2. Encourage mass production of fuel cell vehicles.
This one is the same for methanol fuel cell vehicles. But wait! With methonal, the internal combustion engine is also a viable alternative. It's less efficent than a petrol IC engine, at current standard, but that's migigatable (I think petrol IC will probably slightly excel methanol IC). So, you can get methanol into vehicles sooner, meaning the total cost is spread over a longer time. The dual engine technology will assist adoption.
Additionally, methonal fuel cells, all solid state, are working in lab prototypes. This is about the same state as hydrogen fuel cells, so you'd not lose anything by going to methanol over hydrogen, and you'd gain a lot.
3. Convert the nation's fueling infrastructure to hydrogen.
Easier with methanol - it's the same type of problem as gasoline, so use the same type of solution - no real R&D needed here. That's a significant win over hydrogen, and equal with gasoline. The problem of supplying dual fuels is the same w.r.t. hydrogen or methanol.
4. Ramp up hydrogen production.
Methanol is more difficult to manufacture than hydrogen. But... there are two options. The first one, diret chemical synthesis from CO and H2 is very slightly more complex than direct hydrogen production. The other option, ferment it from celulose. All the waste wood / straw can be fermented into methanol. I don't know which would be cheaper - but I do know that it's not possible for one man to manufacture hydrogen on his ranch. A methanol still, on the other hand, is perfectly feasable. Spin that correctly, and there's capital there.
On the whole, however, it's 50/50 methanol / hydrogen.
5. Mount a public campaign to sell the hydrogen economy.
Hindenberg. Doesn't matter what actually happened, the helium industry spun it so well, that it's embeded in peoples minds that hydrogen is unsafe.
Methanol is methylated sprits. I don't think anyone thinks that's more dangerous than gasoline.
So, slight win for methanol, on the safty front.
Overall, I make that two noticable wins for methanol, two slight advantages, and one where it's 50/50.
Postscript: I use methanol, rather than ethanol because ethanol fuel cells are noticalby more difficult (== expensive), and producing methonal from biomass uses wood and other indigestable matter. Generating ethanol requires sugars, i.e. food.
They are specifically advocated as warning signs - if these come up then further examination is required.
* [The discoverer pitches the claim directly to the media.] And those cases where it was valid, scientifically, the literature bore this out fairly soon after. Remember the target of these rules are judges. If your deciding a court case on yesterdays lab results, then there's a problem.
# [The discoverer says that a powerful establishment is trying to suppress his or her work.] I think that this would trigger a second look to most reasonable people, both at his principle claim, and this claim.
# [Evidence for a discovery is anecdotal.]
From the OED:
Anecdote: The narrative of a detached incident, or of a single event, told as being in itself interesting or striking. (At first, an item of gossip.)
Pages of dull tables are not an anecdote. They are a record of events. Yes, you still have to trust the researcher, but that's _not_ what this one is warning against. It's warning against delivery over content.
# [The discoverer says a belief is credible because it has endured for centuries.]
You said: Of course, such knowledge isn't "scientific knowledge".
But that's the point - this is a guide to seperate true scientific evidence from not scientific knowledge.
# [The discoverer has worked in isolation.] You said: Einstein worked in isolation--does that make relativity "junk science"?
And how long did it take from his publication till relativity was accepted generally? (NB: The Nobel prize was for his more collaborative work on QM).
Although it's worth noting that Einstiens lone wark was, essentially, mathematics, by making a co-ordinate transformation Lorentz invarient under the constraint of a fixed speed of light. The actual physics, and proof came much later, with many teams.
* [The discoverer must propose new laws of nature to explain an observation.] You said: Again, like a lot of astrophysics.
But you missed the important part of the rule: If they make other laws of nautre wrong, then it's probably not the other laws of nature that are the ones that are incorrect.
If you're reffering to the situation with particle physics, then well, yes. That's an exceptional area. How much time with this rule's inclusion cost, in terms of re-evaluating and researching particle physics, over the time it will save, by getting pseudo-science rejected in a court.
This is not for the average man to tell truth from fiction. This is intended to assist judges in telling a well proven fact from junk science.
I think that they do the latter very well. For my line of work, (Research science), if I used these as gospel, I'd get nowhere.
Your correct, bandwidth is fixed. This is about better bandwidth utilisation.
The article is/.ed but the gist is that if you consider a full duplex conection, and you max out one side of that, say uploads, then the ACK packets get swamped, so your downstrem bandwidth is spent re-transmitting, or empty whilst the other end is waiting for ACKs.
The bandwidth is there, it;s just under utilised. By prioritisng the ACK's, so that they get boosted through, it becomes possible to saturate both upstream and downstream pipes at once, at peak efficency, rather than one of the coasting along, waithing for the other.
Note that this only applies for TCP/IP and similar, reliable, protocols. If you had a UDP app (e.g. media streaming done properly), then this trick won't affect it at all, as it doesn't wait for an ACK.
In space, energy is cheap (solar panels), and mass is expensive (very expensive).
An ion thruster is essentially a partical accelerator pointing out to space. This accelerates a very small quantity of mass to very high velocities, using electrostatic methods.
It's the best (currently known) method for converting all that cheap solar energy into thrust, for a minimum of mass.
... the Linux
community just can't hack it and make it without feeding off of the proprietary companies that it so despises.
Proproetary companies are not despised. Most proprietary software is. Hardware companies that refuse to release driver level documentation are. Companies are not (unless everything that they do falls into the above catagories).
Thus: Proprietry hardware companies that give open documentation are not 'despised'. Companies that write GPL code are not 'despised'. They are valuable members of the linux comunity.
If your development model and community are so wonderful why do you accept handouts from proprietary companies?
Because if it's GPL, and good, it gets in. It's not any more a handout than if you wrote some code, and submited it. There is nothing special about corporate ownership. If you have a problem with corporate submissions, you can modifiy the kernel, to remove their work. It's not a problem for me, or for the vast majority of the linux using comunity. I think that you seem to percive (or hold) an anti-corporate stance that is not representative of the comunity at large.
Slashdot Mirror
That's not feasable. The liscence gives you extra rights, essentially to right to make copies, if you agree to certain terms. Copyright permission is not required to use something you have. It is agreed that one does not need to agree to the GPL to use GPL'd software. However, you do not have the right to distribute the software unless you do agree.
Now, a rights management engine, given legal status through the DMCA, is quite another item. But no source code would ever be distributed with such a mechanism in place (it's technological infeasable, and certinally pointless for open source software).
Therefore, the termination clause above is as strong as it gets, in terms of penelty.
In terms of application: To terminate on fileing of a copyright filling would bne very dubious ground indeed. The liscence relies on copyright law to exist, and have any effect. If you prevent anyone else from actually claiming copyright infringment, then you are denying them any chance to use the same rights you are. Consider a case where two different groups both release open source, and a copyright violation between them. It gets very complex, very fast, if there have been external patches included in those software packages.
Note that the license comtains the qualifier 'essential to use'. Is SMP code 'essential to use' Linux? I'd argue not (I don't use it, on any of my machines). Therefore would the clause come into play?
Further more, SCO have not filed any claims that and open source softare is in copyright violation (as far as I'm aware). They claim IBM breached contract, and that's none of the things you mentioned.
Trademark protection has many good points - it stops someone else from pretending to be IBM. If you remove that (which, preventing people from fileing a cliam would effectivly do), do you really want the situation where you have no idea if the Apache webserver you are using is nothing to do with the Apaches we are all familiar with? I do not think that that would be a good thing. It can be abused, granted, but on the whole, it's core intent remains a good one. I cannot say that about the majority of software patents
Um, well - probably not.
Absent NDA, I don't think that SCO could stop you copying thier code, that you legally had in your possesion, for the purposing of judging your own exposure. Note that it is always legal to have GPL liscenced code in your possession, whether or not you agree to the liscence. This situation does not apply to most commercial liscences.
Obtaining a copy of the code by industrial espionage really pollutes the 'good faith' fair use claim. Note that in your second paragraph, your talking about distributing the code, rather than for direct risk management - again, further complicating the situation.
Also, SCO are claiming trade secret violation, not copyright violation. That's a significant asymetry in the legal standings between the two sides. There are no fair use exceptions in trade secret law, as far as I am aware.
I think [0] if you were to obtain SCO's 'evidence' by espionage that they would be able to slap you with a preliminary injunction against spreading the information about, on the grounds that they have minimised distribution pre-discovery. Judges are quite keen to let the courts work the way they were intended, and, coupled with a trade secrets case, I can't see any reason for the judge not to grant an injunction. Note that SCO can claim that the NDA also protects the Linux code - they are minimising thier breach of copyright, which is useful to support a fair use claim.
In short - what you are talking about would fall foul of more than just copyright issues, and there is a fair use exception only for copyright.
[0] Disclaimer: I'm not lisceced to practice law in the USA. This is not legal advice, blah blah blah
In general, you are correct.
However, three matters apply here. Firstly, SCO claim that it is thier code, which means that if they are correct, it is not GPL. This complicates things, and I don't know USA law well enough to say what that means.
Secondly, SCO are not distributing the Linux code, but rather pointing to parts of that that have special relevence. They did not give out copies, but rather pointed to a single printout. Thus, no distribution was taking place.
Thirdly, and I think, strongest - Fair use rights. SCO cannot make a claim without replicating those parts of the code. The fair use exception applies, allowing them to quote 'reasonable parts' of the Linux code, to illustrate thier claim.
Note that the latter cut's both ways - if you were in possesion of SCO's source, you could calim fair use over quoting parts, specifically for the purpose of backing up or refuting thier claims.
I'm not liscenced to practice law in your juristriction - this is not legal advice. For legal advice, consult a local lawyer.
Oh, dont' get me wrong, I know there were lots of technical reasons why this one took so long (the new IDE layer in prep for more IDE drivers, particularly for the new chipsets).
The fact is that 'a few weeks' is substansialy shorter than the norm for a stable kernel at this point.
The random political philosophising was just me pushing some thoughts around, and seing what fell out.
Marcello (and Linus) are probably some of the least politically motivated engineers I'm aware of.
2.4.21 is out.
Now, what's particularly interesting is that it's arrived right at the dead time between SCO treatening to do something, and actually doing it.
If I wanted to thumb my nose at SCO, I'd release a kernel right now (probably call it the "recumbant bicycle" release, or something). Of course, the dev time for the stable series is so long, that it's just coincidence - right?
So why did Marcelo say he was planning 2.4.22 in a few weeks?
If SCO's aim is to hurt linux, I think that they just got a good demonstration that the engineers (who, in terms of OSS, are the only ones who count) don't care about them.
Anyone got an overview of how Theora/VP3 works?
Sepcifficaly, given the dearth of informatiuon so far, I'm assuming it's a block decomposition style, so what seperates it from all the other block based codecs?
Your argument is highly fasifiable.
Namely, by removing the neutron source, the evidence for the breed isotopes would have declined. Return the neutron source, and the evidence would have returned.
Now, I can't claim that this occured, as I wasn't there. However, I can recall that a member of staff from the nuclear physics group was called in, and was convinced that they had a working breader reactor going. Given how simple it is to prove that the reactor was having an effect, and that a breed isotope was observed, I think that I must go with the reacotr team.
Nota Bena: Recall that a breeder reactor is one that manufcatures fissionable material from aterial that is not fissionable, generaly taken to mean that the reactor makes fuel for itself, but not nessecerilly (a pair of coupled reactors are still breeder reactors). They did not produce plutonium. They breed U-233 (A fisionable material), from thorium. Essentially, they noted that bombarding thorium with neutrons would result in manufacture of U-233, and that U-233 is theoretially fissionable (Not actually used anywhere). This is falsifiable - you could disprove this (theoretical) step. Next, they made a neutron generator from an alpha source, and put the two in sequence. Then they borrowed some gear (I forget what) to detect the emission from U-233 decay.
In short, no one claims they made Pu, except you. Therefore assertations that they could not have made Pu is a straw man argument.
Aside: The reason that this reaction is not exploited commercially is down (to a large extent) to raw materials. There is a large, cheap source of pure (as in, isotopically pure) U-238, as a result of U-235 programs (weapons and reactors). Thus breeder research was focused on using up that U-238 as much as the principle of breeder reactors.
Yes you could do this for other hardware plaforms.
... most other CPU's have had the ability to use writable but not executable and executable but not writable heaps for a while. x86 does not. This is why you get a whole bundle of problems with it, as buffer overruns write code in the heap, then get it executed. The patch is an atempt to mitigate the adverse effects of that hardware weakness.
However
It's not perfect (nor is the better hardware solution). However, it will make many exploits an order of magnitude more complex, making writing and utilising them a much more complex task.
The part about locating code inside the ASCII armour is, however, zero overhead, and will, I think, get wrapped into mainline on all archtectures (although possbily not till 2.7)
... assuming that the stack memory is marked as executable in the binary - which will have the net effect of turning off the Exec-shield.
In other words, ELF format has flags to indicate if the stack should be readable and/or executable. If your doing that sort of thing, make sure that the flag is set, and you'll have no problems [0].
It your doing those sort of tricks, your probably being very careful with what goes where, and buffer lengths and such. The problems come in when people don't realise that there could be a problem, and don't audit the buffer handling code properly.
So, don't worry, just use the ELF flags.
[0] Well, you could set the feature to ignore what the binary says, and implement the security anyway. But that's not a good idea, and very much not default.
Ah! Of course. Forward Error Correction.
... well wasn't really. I think that there might be something clever that you can do with RSA, by playing around with products of exponents in Fermats Little Theorum. But I've not got round to pusing the algebra around yet.
It's a well understood mathematical principle, and is used in networking. Actually, FEC is a little broader than what I mean.
What I am talking about is algorithms for spliting a data packet up into m parts, and allowing recovery of the whole with any n of those m (n < m). For example, one such algorithm is the Tornado code, used by Digital Fountain for multicast file distribution.
Here, the application would be somwhat different. You'd take your private key, and split it into m semi-redundant sections, by, well, any of the FEC algorithms you like. Encrypt each part with the individuals public key, and there you have it.
I'll go back to my information theory stuff, and patch together something.
Thank's for the heads up. It's one of those things that once it's pointed out, it's so clear, I can't believe that I didn't see it before.
Note that this would require m+1 encryptions (1 main key, split over m encrypted sections), and n+1 decryptions (n parts brought together, and the manin key). That's a hefty price, but you want to ensure that no person can see part of the private key. This is because (if you want an n from m stratagy in the first place) you do not completly trust the private key holders, so you do not want to give them part of the major key directly.
Hmm. Come to think of it, most FEC codes currently do not have that as a design criteria (but I reckon that one like that could be found). From memory, however, most of the more sophisticated codes have that as a side effect, which results from the even distribution of data between the m packets.
The only other alternative scheme I thought of
Forward error correction - damn, but that's so obviously correct.
If I get a fully working algorithm (or, rather, protocol for utilising the algorithms) I'll stick it in my journal.
Sort of, but the security gained can be gained in other ways, for less cost (in terms of operator time and computer time).
.
In general, assuming a rock solid algorithm, you will not gain anything by using two 1024 bit keys, over a 2048 bit key.
In practice, I suspect that with any actual algorithm, the 2048 bit key would be more secure. This is becuase there entropy in the key is not evenly distributed, but is concentrated in the higher order bits. So by having two sets of low order bits, you have less entroy than you think in the key - which translates directly into less time to crack. [0]
So, it won't improve the algorithmic security over a twice as large key. There are, I think, just two other reasons for considering this.
If you use two different algorithms, then you might be able to cover a weakness in one algorithm by wrapping it in another. Frankly, just use a better, single, algorithm. There are plenty that have been shown to be secure, and there's not advantage to faffing around like that, unless you believe that the NSA have s00p3r s3kret decrypters for a particular algorithm. In which case, grab a tinfoil hat, and hack PGP so that it does not ouput any framing information on the encrypted data at all (to prevent algorithm identification). I think all your achieve is to make it difficult for people to send encrypted information to you.
However, there is, I think, a reasonable algorithm for using two different keys. If you store them differently, and access them differently, then you can make it twice as hard for someone to steal your private key. So, for example, you might have a private key on a USB keychain, and the other on hard disk. If only one of them has a pass phrase, then it can be very difficult for, e.g. a keyboard sniffer, to identify that there are two keys.
There are other solutions to this, which would not require double encryption though. Primarily, you could encrypt one key with the other, achieving a similar degree of operator level security, without the overhead [1] on others, making it far more likely to be sucessful. If it's too complex for others, then they may well just skip the encryption altogether.
Encrpting one key with another is also how I would implement a 'need both people to decrypt' schema.
(Aside: Anyone know of a method that would allow for a 'any n of m keyholders needed to decrypt' schema? It's something that has advantages, but I've no idea how to go about it)
So, unless there is some purpose to the double encryption that I've missed (i.e. you ment something by 'secure' other than what I covered above), it nets you nothing over simpler methods.
[0] Note that this applies only to asymetric (public key) encryption schemes, such as RSA, DSA etc (key lengths around 1024 bits), not to symetric ciphers, such ad blowfish or 3DES, with key lengths of around 128 bits
[1] And remember that this overhead is not so much for yourself, who can cope with it - but for those who wish to send you messages. If you are just encrypting files for your own use, then alternative solutions (a symetric cypher, or one time pad) have advantages.
and, at first thought it was a piece about how the herion chic was out in silicon valley, and an actual womanly shape was in.
Then, of course, I realised that it would be about pr0n firms locating in Silicon valley.
I think I need time off, away from a computer screen.
Not quite.
I liked running it slow, till I got a new fan, rather than not running it at all.
Pretty clear advantage there.
It's a fairly simple system. You stick an oscillator of known frequency (32.768 kHz in this case) on the chip, and then use that to count the inputed clock rate.
If you count too many clock pules to each refference pulse, then you can modify behaviour on the basis of that. I's interesting to note that the patent talks about CPU's going as fast as 500 MHz, and talks about 1995 as recent. So all the talk about dodgy resellers was probably topical way back when it was written, when, if I recall, there were a few resellers overclocking chips on the quiet. I think that this is a patent whose time has come and gone.
More worrying, it talks about under-clocking detection, as if it's a symptom of faulty hardware. Well, my recent brush with a failed fan ment I underclocked my CPU, to alow it to function without overheating - I sincearly hope that Intel doesn't intend to prevent that.
According to BBC radio 2, Amazon have decided not to honour any orders placed.
Unfortuantly, no web link yet, and the radio was somewhat lacking on detail, but they implied that no-one was going to get one at that price.
This wouldn't be the first time that a retailer has renaged on an online deal, offereed in error. A couple of years ago (Sept 1999), Argos offered a £300 TV for £3. They refused to honour it, and I'm not aware of any legal rammifications for Argos.
So, looks like this will be just another one of those curiosity stories.
A remote exploitation means that if your are connected to the internet, (And, in the case of a server deamon, running the affected daemon), then a remote attacker (== only using net acesses) can obtain root privs.
A local exploit menas that the attacker must be first logged in as a local user (i.e. have a valid account, or have exploited a server daemon to obtain local, unprivildiged access).
Attacks that require you to have physical acess to the box are generally not classified, as these will always exist (through boot disks, etc), and as thus not audited for.
It is a common practice to use an insecure deamon to first get local acess, then to use a local root hole, such as this one.
Hope that helps - the jargon is dense, but useful.
Over the past year or so, we (meaning my academic group) has purchased around 20 000 UKpounds (around $26 000 dollars) of computing equiptment.
A 16% tax would mean 16% less computing power available. It would mean that 16% less work could get done. It would mean 16% of each grant gets wasted (from the POV of the group funding the reasearch).
Thank goodness the UK's fighting this one.
Also, they'd have to define computer. However they do it, I'm quite sure that there's at least one of the boxes I use would fall outside the definition. If it's x86 / PPC only, then looks like everyone will be buying Sun Blade 100's. If it's per CPU, then do we get taxed 4 times for our Alpha? What about if we install one of the cute PC-on-a-PCI card in one of the Suns? Is that a new computer, or not? It's an ASMP box, two CPU (USparcIIe and Celeron), two OS, one hard disc machine.
And just consider what it would do for a $1 million supercomputer. Or for a 32 node beowulf.
I don't know if fermenting wood would be sustainable. I don't think that it would be ultimatly.
Methanol is as "clean" in use as hydrogen would be, in a fuel cell environment. Ok, you still get CO2 produvtion, but that's being recirculated, not realeased from fossil fuels, so it's not making global warming worse. In an internal combustion engine, you potentially get nitrous oxides, ozone etc (as with any internal combustion engine).
With methanol it's slightly more complex to manufacture. Which you do in four or five places. It's significantly easier to transport and store, which you do in millions of locations. That's the pay off. You centalise the complexity, and keep the interface to it as simple, and familer, as possible.
Methanol is currently manufactured in significantly larger volumes than hydrogen is. I can't quote exact figures, but in our building the best guess is that we go through 1-2 moles of H2 a month, and 30-40 moles of methanol a day, in various uses. That is, the extra complexity in manufacture is marginal, and the gains in transport and use are great. I don't have the numbers to hand, but I'd bet the current cost's make methanol cheaper, per joule of stored energy, than hydrogen. Certinally, I know the bean counters worry over hydrogen costs, but not over methanol costs.
It's not about being the best - its about trade-off and good enough. The biomass fuel sources of methanol are a side benefit - the reason to transition is cost.
Also, methanol can be poured into a very nearly standard desil engine, and just work. I belive than changes are mostly tuning related, so aught to be able to be done by any mechanic. That's one in the eye for hydrogen, which _doesn't yet_ have a working engine in mass production.
Or, more or less, the ease of use and transportation would, in my opinion, more than make up for a slightly increased complexity of manufacture.
Ah, right.
You can't supply all of the fuel for everyone from agricultural land. Well, you might be able to, but it's definitly well into the "probably not even theortically possible" territory.
That aside, I proposed it as a supplement to large plant production of methanol. This approach is well suited to small, local production of fuel - something that's not possible under either gasoline or hydrogen fuels.
Don't look at it as the sole production method. If you do, it looses (see Brazil's ethanol powered cars - oil was so much cheaper, they gave it up). No, it's an arguement why methanol is better than hydrogen. If your going to replace your principle portable fuel, might as well go for the best.
That said, you wouldn't grow corn for methanol as a fuel. I'd be growing pine trees (quick growing, low maintinance. You plant them, thin them a few years later, and then harvest). This grows on quite different land to corn, so nets you slightly higher overall land utilisation. Also, the straw that's not used from the corn can get chucked into the fermenter as well. But eat the corn - that's what its for.
If fermenting the straw cuts your fuel bills in half for growing it that's a win.
Hydrogen powered cars?
Dream on!
Let me break down the 5 areas that they say need R&D. I accept that these are the main problem areas. However, consider the alternative, of methanol powered fuel cells.
1. Solve the hydrogen fuel-tank problem.
However you do it, it's more difficult than storing gasoline. With methanol, it's eactly the same problem. Bush should devote $0 to this problem, and instead point to the current solutions for oil.
2. Encourage mass production of fuel cell vehicles.
This one is the same for methanol fuel cell vehicles. But wait! With methonal, the internal combustion engine is also a viable alternative. It's less efficent than a petrol IC engine, at current standard, but that's migigatable (I think petrol IC will probably slightly excel methanol IC). So, you can get methanol into vehicles sooner, meaning the total cost is spread over a longer time. The dual engine technology will assist adoption.
Additionally, methonal fuel cells, all solid state, are working in lab prototypes. This is about the same state as hydrogen fuel cells, so you'd not lose anything by going to methanol over hydrogen, and you'd gain a lot.
3. Convert the nation's fueling infrastructure to hydrogen.
Easier with methanol - it's the same type of problem as gasoline, so use the same type of solution - no real R&D needed here. That's a significant win over hydrogen, and equal with gasoline. The problem of supplying dual fuels is the same w.r.t. hydrogen or methanol.
4. Ramp up hydrogen production.
Methanol is more difficult to manufacture than hydrogen. But... there are two options. The first one, diret chemical synthesis from CO and H2 is very slightly more complex than direct hydrogen production. The other option, ferment it from celulose. All the waste wood / straw can be fermented into methanol. I don't know which would be cheaper - but I do know that it's not possible for one man to manufacture hydrogen on his ranch. A methanol still, on the other hand, is perfectly feasable. Spin that correctly, and there's capital there.
On the whole, however, it's 50/50 methanol / hydrogen.
5. Mount a public campaign to sell the hydrogen economy.
Hindenberg. Doesn't matter what actually happened, the helium industry spun it so well, that it's embeded in peoples minds that hydrogen is unsafe.
Methanol is methylated sprits. I don't think anyone thinks that's more dangerous than gasoline.
So, slight win for methanol, on the safty front.
Overall, I make that two noticable wins for methanol, two slight advantages, and one where it's 50/50.
Postscript: I use methanol, rather than ethanol because ethanol fuel cells are noticalby more difficult (== expensive), and producing methonal from biomass uses wood and other indigestable matter. Generating ethanol requires sugars, i.e. food.
I'm at this point where I'm finding i'm doing everything in C, Fortran or shell.
I'm reckoning that I aught to learn a language that sits in the middle.
Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).
They are specifically advocated as warning signs - if these come up then further examination is required.
* [The discoverer pitches the claim directly to the media.]
And those cases where it was valid, scientifically, the literature bore this out fairly soon after. Remember the target of these rules are judges. If your deciding a court case on yesterdays lab results, then there's a problem.
# [The discoverer says that a powerful establishment is trying to suppress his or her work.]
I think that this would trigger a second look to most reasonable people, both at his principle claim, and this claim.
# [Evidence for a discovery is anecdotal.]
From the OED:
Anecdote: The narrative of a detached incident, or of a single event, told as being in itself interesting or striking. (At first, an item of gossip.)
Pages of dull tables are not an anecdote. They are a record of events. Yes, you still have to trust the researcher, but that's _not_ what this one is warning against. It's warning against delivery over content.
# [The discoverer says a belief is credible because it has endured for centuries.]
You said: Of course, such knowledge isn't "scientific knowledge".
But that's the point - this is a guide to seperate true scientific evidence from not scientific knowledge.
# [The discoverer has worked in isolation.]
You said: Einstein worked in isolation--does that make relativity "junk science"?
And how long did it take from his publication till relativity was accepted generally? (NB: The Nobel prize was for his more collaborative work on QM).
Although it's worth noting that Einstiens lone wark was, essentially, mathematics, by making a co-ordinate transformation Lorentz invarient under the constraint of a fixed speed of light. The actual physics, and proof came much later, with many teams.
* [The discoverer must propose new laws of nature to explain an observation.]
You said: Again, like a lot of astrophysics.
But you missed the important part of the rule: If they make other laws of nautre wrong, then it's probably not the other laws of nature that are the ones that are incorrect.
If you're reffering to the situation with particle physics, then well, yes. That's an exceptional area. How much time with this rule's inclusion cost, in terms of re-evaluating and researching particle physics, over the time it will save, by getting pseudo-science rejected in a court.
This is not for the average man to tell truth from fiction. This is intended to assist judges in telling a well proven fact from junk science.
I think that they do the latter very well. For my line of work, (Research science), if I used these as gospel, I'd get nowhere.
Your correct, bandwidth is fixed. This is about better bandwidth utilisation.
/.ed but the gist is that if you consider a full duplex conection, and you max out one side of that, say uploads, then the ACK packets get swamped, so your downstrem bandwidth is spent re-transmitting, or empty whilst the other end is waiting for ACKs.
The article is
The bandwidth is there, it;s just under utilised. By prioritisng the ACK's, so that they get boosted through, it becomes possible to saturate both upstream and downstream pipes at once, at peak efficency, rather than one of the coasting along, waithing for the other.
Note that this only applies for TCP/IP and similar, reliable, protocols. If you had a UDP app (e.g. media streaming done properly), then this trick won't affect it at all, as it doesn't wait for an ACK.
Just another perspective on the above.
In space, energy is cheap (solar panels), and mass is expensive (very expensive).
An ion thruster is essentially a partical accelerator pointing out to space. This accelerates a very small quantity of mass to very high velocities, using electrostatic methods.
It's the best (currently known) method for converting all that cheap solar energy into thrust, for a minimum of mass.
Proproetary companies are not despised. Most proprietary software is. Hardware companies that refuse to release driver level documentation are. Companies are not (unless everything that they do falls into the above catagories).
Thus: Proprietry hardware companies that give open documentation are not 'despised'. Companies that write GPL code are not 'despised'. They are valuable members of the linux comunity.
Because if it's GPL, and good, it gets in. It's not any more a handout than if you wrote some code, and submited it. There is nothing special about corporate ownership. If you have a problem with corporate submissions, you can modifiy the kernel, to remove their work. It's not a problem for me, or for the vast majority of the linux using comunity. I think that you seem to percive (or hold) an anti-corporate stance that is not representative of the comunity at large.