I've got a quitea bit of experience with SiC abrasives, what with the materials engineering and being a bit of a lapidary.
First off, it's nowhere near diamond in terms of hardness. The Mohs scale is semi-arbitary in assignement, and not even vaugely linear. On proper hardness scale (in this case Vickers), diamond has a hardness of around 90 GPa, compared to about 25 GPa for SiC. That's the reason I've got a box full of diamond abrasives, despite the cost (about 30 times more expensive), they are much faster, and last almost indefinitly. More later on this.
Secondly, SiC needs to be rough. If you don't belive me, try grinding a carrot into shape on a window. The glass is very much harder then the carrot, but is nearly perfectly smooth, and as such, the carrot just sides about. Compare with rubbing the carrot on something like a concrete paving slab, which grinds it much better. The reative hardnesses are wrong here, but show the need for surface roughness.
As an aside, if you think that paper cuts are bad from standard office paper, then try getting one from fine SiC abrasive paper. Stiffer paper, cuts deeper, and the abrasive roughs up one side of the cut, so it takes about four times as long to heal. It's a mistake I've made exactly once.
A processor is not a single pure material - if it was, it wouldn't do anything. They are a complex layered system, with layers of copper and SiO. Trying to grind anything with a processor die will just succed in scraping off all that important stuff. The hardness of SiO is Mohs 7, well below that of anything actually used as an abrasive for metals. (It's the same as ground glass, near enough, sometimes used for abrading wood or plastics).
For comparison silicon has a hardness of 12 GPa Vickers. SiC is only around twice as hard as that.
So, no, you can't really use it as an abrasive. If you really want to be very careful, you might be able to use the edge of the die as a scraper, but you'd probably just remove the important stuff.
That's alla moot point, however. I strongly supect that you'll never see the actuall die, it will be under a metal heat spreader. Because they can cope with higher temperatures [0], there is even less need to take the risk of mishandling breaking the die.
And lest you think that SiC would be less likely to break then silicon, I'm afraid not. Aside from the fact that many broken Athlons are due to the top few layers of SiO and metal breaking, SiC is not that tougher than silicon. As any lapidary will tell you, it's perfectly possible to chip saphire and diamond, if you're not careful.
Still, I can't deny that facts aside, it's a wonderfuly evocative metaphor.
[0] And how much higher! Silicon tops out at 350 C, SiC could operatate at 600 C, where is it glowing red hot!sourced from Nasa
The very murky situation of differing copyright laws rears it's head.
In the UK, the type of work dictates the duration of copyright. See, for example, here
In the USA, the type of authorship dictates the duration of copyright. See, for example, here
The fact that the performers tend to produce works for hire, and composers tend not to is a side distraction here. There are composers who produce works for hire, and performers who own thier own recordings - which really clouds things in the USA.
Oh, and the copyright terms in the USA are determined by authorship, not ownership. Thus, just because it's currently owned by a corporation doesn't make it a corporate authorship.
At least the justification for differening terms for personal or corporate authorship has some merit.
As it stands in the UK, making a film is clearly considered worth two and a half times as much as makeing a sound recording, and 5 times as much as writing a book (assuming that one of the director, authors or composer lives 50 years after making the film). Why? Well, I can find no good reason for it.
The fact that the BPI is lobbying for extension of the performer copyright duration is not the sum total of the issue.
There is a difference in duration between performer and composer copyright. This is _not_ the case with the US.
Thus, when people talk about the Beatles catalogue falling into public domain, what they mean is that the recordings they made do. The copyright on the lyrics and music lasts longer, but is liscecable under mechanical terms.
So, if there is no change in the law, come 2013, if you disribute the Beatles playing 'Love me do', then you will still need to pay the songwriter royalties. Thus, the argument the parent poster gives at the end is slightly off base, as it refers to songwriter copyright, not performance.
Quite frankly, I can see no benefit in different durations between performance and songwriting copyrights. Mind you, I'd lean to the lower limit rather than the higher, but the issue of what to set the duration at is a different point to whether there are differential terms for composers and performers.
... and whatever the equivelent is in other bootloaders.
I.e. with physical acess to the box (which, in the case of this software, you will), you can always recover a lost root password, by booting single user, and then changing it.
In the event that you've locked up your bootloader with a password, this util doesn't change that.
If you've really locked it up the wazoo with crypto all over the place, I think it's recoverable with a boot disc (as you'll have the bios password, or be able to wipe it, to re-enable booting from CD). Mind you, if you've done that then you're not likely to be the sort of person who needs this util.
Frankly, I'd agree with you about self-discipline - there are very few cases where an externally imposed discipline is useful as anything other than a tempory measure. This is not one of those cases, in my opinion.
It is, however, always worth knowing how to recover from any problem, where it is possible. Backups not needed in this case.
The solubility doesn't go down again till the freezing point. My bad. For some reason, I was thinking of the density of water, which is just plain bizarre to get confused with.
The 'not freezing' requirement can be relaxed a little - a small (maybe 7-10 percent) ice crystals isn't a perceptable issue (from experience, with a -12 centigrade freezer). You're not going to be able to do cryogenic cooling without some ice being produced, in any real world sense, unless you stir it lots, which de-gasses the thing anyway.
Interesting result with freezing fizzy pop, by the way. I once left a bottle (plastic, 500ml) of soda in the freezer too long (by a couple of days), so that it was frozen solid. Opening the bottle (which is a pressure vessel), had the solid inside expand, and start to expand, until it was about 2 centimetres about the top of the bottle. I think that was the CO2 that was forced out of solution that expanded, with sufficent force to cause to ice to change shape. Very bizzare, if perfectly predicatable.
Warning: Bored physcist ahead. Reading the following may result in loss of eyebrow, and the opinion that a factor of ten is 'close enough'. Note that cryogenic material has risks associated with it. The level of risk with LN2 is similar, prehaps a little less, than for boiling water. Treat arrodingly.
The end result was drinkable, but a bit wasteful and really messy. Perhaps next time I'll just try the dry ice, but I really don't think the heat transfer rate is going to be enough.
The problem with rapid cooling of carbonated drinks is that the solubility of CO2 in water decreases at low temperatures. And at high temperatures, the rate of de-sorption increases, just for kicks. It's a wonder any stays in the water at all.
Anyway, the ideal aim for speed cooling is to drop the temperature down to 'cold but drinkable' as rapidly as possible. Going below that temperature is as bad as not going cold enough.
As you noted, you need to get a rate of cooling such that the rate that gas is forced out of the drink is sufficently low.
What, then, is the rate of cooling? Well, it turns out (insert handwave here) that the rate of heat flow is determined by the difference in temperature. To a first approximation *handwave*, then, we can asses the rate of cooling by the temperature difference between drink and cooling medium.
Liquid nitrogen (LN2) is at 77 K. Room temperature is 298 K, giving a temperature difference of 220 K [0]. For comparison, the temperature difference between ice and room temperature (the annoyingly warm temperature soft drinks tend to be at) is 25 K. Thus we can consider that the rate of cooling from liquid nitrogen is about 10 times faster than from ice [1].
How long does it take to cool a soft drink with ice? Well, in my experience, about 20 seconds for around 330ml, with gentle agitation (i.e. a quick stir, or pouring over the ice). Thus the 'few seconds' the poster give for LN2 to hit freezing point is qualitativly correct [2].
The temperature of dry ice is 195 K, which gives around 125 K difference [3], thus an initial cooling rate around 5 times the heat transfer rate of ice, and half that of LN2. It's not quite, because thermal contact is better with the other two cases (liquid - solid interface, versus solid - solid for the dry ice [4]).
You could put the dry ice in the drink, or the LN2 in the drink. The problem with that is that if you drop the cold material in the drink, it might sink under the surface, flash freeze the surrounding liquid, and then turn to gas. This risks the ice exploding (and is more of an issue for dry ice than LN2).
The simplest way to avoid these problems is use enough coolant to get your drink down to ideal temperature, so that the whole mass of liquid will not freeze, always leaving a path for gas escape.
How much is that? Well, an estimate may be made as follows: If we assume that the coolant material are at the temperature of boiling/sublimation as appopriate, then the total energy absorbed per unit mass will be equal to the apporiate latent heat [5]. This allows a calculation of the mass required, if the total energy tobe removed from the drink is known.
If we assume [6] that the specific heat capacity (amount of heat energy taken to change the temperature of a substance) of the drink is equal to that of water, that gives a value of 4.2 kJ K-1 kg-1. Further, we assume that it's density is also equal to that of water, so that 1ml equals 1 g.
The appropriate specific latent heats for our coolants are: 199 kJ kg-1 for nitrogen and, surprisingly, 199 kJ kg-1 for CO2. I think that that great cosmic coincidence is proof that this sort of calculation is intended to occur.
Thus, to remove 25 K from 330ml of water, we need to remove 20 * 330 * 4.2 J = 27.7 kJ, if we take the desirable temperature of the drink to be 5 degrees centigrade. That's about 140 grammes of coolant.
The Oxford English dictionary list trial as a varb, and cites the word in use in 1981. Thus, it's been a verb longer than this web site has existed.
Oh, and "Period." is not a sentance. It's missing a verb. Unless your verbing [0] period, in which case there's a whole mess involving objects and subjects that you've missed out, assuming you're sticking to formal rules of grammar.
Alas, much as I would have liked OED not to list period as a verb, it's cited from back in 1595.
Oh, and for those who are interested, verb has been verbed for a while. The earlist citatation is 1936, from a poem, thus:
1936 F. CLUNE
Roaming round Darling vii. 62 The Poet accused me of verbing a noun, but I soon fixed him. I threatened to noun a verb
which seemed oddly appropriate, and a bit of a special case. After that the first verbing of verb was 1978.
Now, if you read the label carefully, it claims it's "hypo-allergenic" lanolin.
That's a bunch of crap.
If you have an allergy related dermatitis, do _not_ use E45, or other lanolin based emollient. You end up with exposure to lanolin, and it is liklely that you will develop an allergic reacion to the lanolin.
That's what happend to me. Atopic dermatisis (aka eczema), and after about 8 months, I'd developed an allergy to lanolin so severe that I'd rather pour sulphuric acid over my skin, than put lanolin near it.
Now, you (the grandparent) may be lucky, and not become sensised to lanolin. It's not worth the risk - I can't handle most new woolen goods, because the traces of lanolin are there.
E45 is fine if you have unbroken, but dry, skin. That's not the case for people with chronic dermatitis.
What you actually want is aqueaus cream, or emulsifying ointment. Ask your pharmacist, they're about 1/3 the price for 4 times the volume, more effective, and not going to bite you in the ass later on.
Unisys would be prohibited from distributing any GPL code that contained patents not licenced for royalty-freedistribution by all
Not quite. Unisys would be unable to distribute GPL code that implemented the ideas covered by a patent, that they were aware of, and that the patent holder had denied the use of said patent.
That is, if you don't know it's patented, you still distribute. 'Cos, like, otherwise we'd all be paralysed.
If they own the patent, and then distribute GPL'd code, that's implicitly that the patent is liscenced under a liscence that allows the downloader a patent liscence suitible to fufil the GPL.
Thing is, that's a liscence to distribute the code. Not use.
See, funny thing about the GPL is that you don't have to agree to it to use the code covered by it. Actually, it's not funny at all, it's the norm, just years of (very porbably bogus) EULA's make that less clear. So all the GPL covers is distribution of the code.
But, a patent requires a liscence to 'use' the patented invention.
So, Unisys could do the following:
1) Patent an idea. 2) Impement the idea in code. 3) Release the code under GPL, and not mention the patent. 4) Let it grow. 5) Point out that they only gave a patent liscence to re-distributed the code, not use it, and charge for it's use. Once it's popular. 6) Profit!
Any explicit mention of the patent would make the situation clear - either by explict licence, estoppel, or clear that you don't have that. No mention of the patent makes it really, really, hard. That's the first patent/copyright GPL hack.
Now, consider what happens if they add a patented algorithm to a GPL'd codebase. The only liscence they can put the implentation under is GPL. But they can stick a patent liscence on top of thier implemention, that effectivly prohibits re-disribution by parties other than themselves. What happens then?
Section 7 does not apply, becuase the condition is not _imposed_ on them - they have chosen that patent liscence. (Semantic's, perhaps. Still, that's one to be settled by the courts).
So, they can offer it for download, and then anyone who does get the patented implementation from them can't redistribute. That's a second hack.
Or, another option - offer a royalty-free liscence to use and redistribute the patented implemention (in effect, giving the implemention all the GPL-type conditions). Great, you think, and grab a copy, and modifiy and resdistribute.
They then change the patent liscence. What?! Well, it's an explict liscence, and if it doens't say that it's irrevokable, or if it has a clause that lets them change it a bit, then tough. Estoppel doesn't apply - the terms were explicit, and clear.
There are probably other hacks that can be applied in a situation with patents, but that's more than plenty to be getting on with.
That's it, really. Patents are out of the scope of the GPL. The only way they interact is that if you don't have the rights to disribute the source (e.g. by patent liscence), you can't distribute the the binary.
It's oft talked about that patent might be a method of getting an end run around the GPL, and maintining restrictions on GPL'd code.
Either they will have to give up on their socio-political HR poilicies and start basing promotion, hiring and firing on applicable indicators like skill or die by their own hand.
Yup.
There is, however, an interesting side effect to this. You slack, so that the system rots, so that slacking will be punished.
Except, the only way that this will work, is if slacking is punished (duh!), and we note that you are slacking. So, the slacker will suffer if it succeds.
Therefore, the ideal situation is if _everyone else_ slacks off, in a serious manner, and you don't, thereby accuring the benefit of the change in system.
My philosophy is rusty, but isn't this a prisoners dilemma? The ideal situation is for everyone else to cooperate with your plan, but for you to compete with them.
To clarify, I ment a reference to a single object within the loop, that being the only object within the loop that you still want. This can occur, for example, in a (not terribly great) implementation of a circularly linked list.
Hence, rather than being able to reclaim 14 or thereabouts objects worth of storage, the GC holds on to them. That's a programmer error, and wherein circular references can lead into memory 'leaks'.
The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.
Note that a manually managed memory model wouldn't nessecerily help in that situation - if you free() the objects you no longer need, not noticing that there is a cirular reference, you can end up with a particularly painful to sort out segmentation fault if you later acess that ciruclar reference (probably in a call to free() itself).
Computer science is not programming, though programming is a skill that most computer scientists need to ahve.
Let me draw an analogy here. Consider chemical lab monkey. Their job is mixing things to make stuff, and performing any one of a batch of analysis techniques.
The most important skill for them to have is good lab procedure - keeping thing clean, labeled, and not spilling things. Also, knowing what to do if one of the above is not true.
This does not need a degree in chemistry (and I say that as a chamietry graduate). The depth of understanding required isn't that great - once you know how to do a titration, you look up the precise set of reagents to use to perform a specifc test. Compare this to a programmer, whose is much the same situation - know the basic principles for a set of techniques, and then looks up the specifics if needed.
Chemistry is very slightly older than programing / computer science. So, if you look at how the split between laboratry workers and the hardline theorists worked out, that might give some insight into how the programming field might develop, right?
Well, there are no seperate qualifications for laboratory work. The nearest thing is stopping the path to a degree before graduauation - be it after highschool, or with something that's equivelent to the first year or two of a bachelors.
Most places, however, when they want some to work thats mostly turning the handle reactions or analysis look for a degree.
For good or ill, then, I suspect that trying to split off programming and CS will come to nothing.
Density Functional theory owes a lot to Kohn. He didn't come upwith the idea (that the properties of a system can be defined by the location and density of electrons), but he was involved with almost everything to turn it from an interesting idea into a useful theory.
Because he (along with Sham) provided the Kohn-Sham equations, pretty much every paper that does anything to DFT (as oposed to things with DFT, but even then, many do) cite one or two of his papers.
The reason DFT kicks arse as a calculation scheme is that it is proven to be able to be as good as any other method. It's also cheap to calculate, because it is localised (you only need to examing the vicinty of an area to calulate, as opposed to QM theories which require youto compare a spot with everything. Repeat (for both DFT and QM) for all points).
It, like all such methods, has it's foibles, but a good DFT schema (it's actually a class of methods, rather than a specific single one), can be as good in computational chemistry as things that take 2 to 5 times as long.
The Fortran code solved a particular eigenvalue problem in a few manners, to get different bits of information. Main workhog, used parrallel algorithms.
The C code generated the set of input matrices for a spefic problem geometry. These were output into a text stream, passed to the Fortran routine. This means that the C code took input of number of atoms, orientation, interaction coefficents, and output some giant matrices.
The Fortran output was several sets of output from the various methods. Perl chunk, for the most part, selected the output chunk desired, and pretified it. For one particular type, it output Postscript.
So, the gist is that each indivdual part was seperate conceptually, and performed distinct roles. It would be feasable to run a specific job by piping the output of one stage to the input of the next. In practice, the runtimes of the Fortran stage was such that it was saved to disk, so the same output could be parsed in multiple ways.
I wrote the code, ran some stuff, forgot about it, and had to go back to it 2 years later. Despite a serious lack of comments, it took around 5 minutes to get familar with it enough to extend it for a totally different crystal system.
First of all, if you look at sourceforge stats, the top languages are C, C++, and Java,...
If you look at what a good joiner uses, you'll note that he has a large set of tools, and picks the right one. There is no advantage in trying to turn wood on a lathe with a screwdriver - that's the job of a chisel.
A similar thing applies with computational work. If you truely know what you are doing, you'll use the right tool for the job. If your wanting to accumulate a large set of facts, and then do some comparisons across that set of facts, that's a job for Prolog. No matter that C, or Java, or Perl, or whatever, is more popular. They are just a poor fit to the task, which would mean you'd need to write a predicate logic packeage in them, to get them to work.
Look at tools like FFTW. It's written in OCaml, and C. Two different languages, each used seperatly, to play to thier strengths. OCaml does tree parsing, and optimising of an abstract syntax tree. C code does the numerical heavy lifing. That's choosing the right (rather, a good, there is a pluraity of good tools for that) tool for the job. Trying to do the abstract syntax tree parsing in C, or the numerical heavy lifting in OCaml is just stupid - you'll end up with something that's nowhere near as good.
Try writing an OS kernel in Perl.
'Favourite language' is something that's not a good metric. I've solved problems (and that's what it's all about) using 50 lines of C feeding 100 lines of Fortran feeding 50 lines of Perl producing Postscript that compiled to the desired diagrams, because that's what suited the problem domains best.
Claiming that 'good hackers like language X' misses the whole point. Good hackers will use the best tool for the job.
Also, Graham seems to be conviently ignoring the 'can this be understood three years down the line' aspect. There is no point in having code that you can't maintain. That's where Java comes in - it's got a blend of power and syntactic salt help keep things maintainable. Asserting that maintainabilty isn't relevant just strikes me as something that's, well, immature.
Uh, Cray have a backlog of orders. A backlog to the tune of $153 million, if I recall correctly.
That's not the sign of a dying buisness model. If they are having problems, it's down to the mangement, not lack of demand.
There are problems that don't work well on clusters, but rocket on a proper supercomputer. These include a lot of interesting areas, there will always be demand for a few pieces of big iron. At the risk of echoing the ghost of IBM CEO's past, I think somewhere around 20-30 serious top end supercomputers in the world [0]. Most of the rest of the jobs will do just fine on high end clusters.
If you read the article, there are no quotes from Cray people. What there are quotes from is the people who used to get to play with special hardware, who now admin those clusters.
It's toys for the boys, not a buggy whip issue.
[0] That's informed by being someone who uses high perfromance computing, both cluster and supercomputer.
dtrace, due with Solaris 10 does that. So it's not quite a top equivelent, but it does laet you answear your questions ("What processes are kicking the shit out of the disk", and "By how much"), and long with the also useful "In what way" i.e. many small writes, hugh seek to read ratio, or what have you.
It is, however, expert driven, unlike top, which is simple to use. Still, I think that dtrace shows the furture of performance monitoring apps.
Note that dtrace lives partially in the kernel - it's not portable to Linux.
Not really. Computer magazines use 'off self' dating. That is, when the date listed on the magazine comes around, it should be removed from the newsagents shelf.
Most magazines use 'on date' dating, where they get put on the shelf when the date listed on them comes up.
Why the difference? Tradition mostly. The argument is that computer magazines need to seem as new as possible (cos the tech changes), moreso than most other magazines. Thus once one magazine went with 'off date' naming, the rest followed, rather than seem a month or so out of date.
Typically the magazine is on the shelves for a month, so a subscriber would be getting the magazine intended for same during August about now. That magazine will have September as the date written on it.
So, it's bizzare, counter intuative, but perfectly possible to quote a 'September' issue now.
He runs a web hosting firm. I forget what it's called, but that's also how he's able to donate all the bandwidth for Wikipedia, and where all the servers are located.
Gotta admit, saying that you host Wikipedia is a serious selling point, in terms of proving you can cope with a big site.
To be fair to the UK parliment, they knew that. As did the police. Some forces were for a new law, some were against.
In principle, the offence was covered under 'driving without due care and attention'. In practice, most people felt that they were in full control of the vehicle, whilst chatting on the phone (in spite of studies to the contrary) [0]. Mobile phone use was endemic, so the legistlative decided to make it perfectly clear that is was not accpetable, by a specific and clear new law.
I understand that, although there have been very few prosecutions, there has been a marked decrease in mobile phone use whilst driving. This may be considered a sucessful law, in that it has reduced the dangerous behaviour significantly.
In short, the aim of the law was to educate the driving public, rather that create a new offense. It has a achieved that aim.
[0] I'll note that techincally driving whilst intoxicated falls into exactly the same catagory. Sepcific laws allow for specific limits and additional penalties, but that is, in principle, all they add.
In that regard, van Allen is right -- there's no good political or economic justification for manned flight right now...
In a word, wrong. Maintinance.
It's cheaper repair a satelite than to put a new one in orbit. There are plenty one-off statelites up there that once they go, that's it. See, for example, the Hubble space telescope. It can do a lot of science, but it'll need some help soon, or it's a gonner. Is that worth sending a man up for? I think so.
Note that that doesn't require a continued presencein space, just send a crew of mechanics up every so often to keep things working. I accept that most manned space flights are redundant, but that doesn't mean that all of them are.
Slashdot Mirror
Not quite.
I've got a quitea bit of experience with SiC abrasives, what with the materials engineering and being a bit of a lapidary.
First off, it's nowhere near diamond in terms of hardness. The Mohs scale is semi-arbitary in assignement, and not even vaugely linear. On proper hardness scale (in this case Vickers), diamond has a hardness of around 90 GPa, compared to about 25 GPa for SiC. That's the reason I've got a box full of diamond abrasives, despite the cost (about 30 times more expensive), they are much faster, and last almost indefinitly. More later on this.
Secondly, SiC needs to be rough. If you don't belive me, try grinding a carrot into shape on a window. The glass is very much harder then the carrot, but is nearly perfectly smooth, and as such, the carrot just sides about. Compare with rubbing the carrot on something like a concrete paving slab, which grinds it much better. The reative hardnesses are wrong here, but show the need for surface roughness.
As an aside, if you think that paper cuts are bad from standard office paper, then try getting one from fine SiC abrasive paper. Stiffer paper, cuts deeper, and the abrasive roughs up one side of the cut, so it takes about four times as long to heal. It's a mistake I've made exactly once.
A processor is not a single pure material - if it was, it wouldn't do anything. They are a complex layered system, with layers of copper and SiO. Trying to grind anything with a processor die will just succed in scraping off all that important stuff. The hardness of SiO is Mohs 7, well below that of anything actually used as an abrasive for metals. (It's the same as ground glass, near enough, sometimes used for abrading wood or plastics).
For comparison silicon has a hardness of 12 GPa Vickers. SiC is only around twice as hard as that.
So, no, you can't really use it as an abrasive. If you really want to be very careful, you might be able to use the edge of the die as a scraper, but you'd probably just remove the important stuff.
That's alla moot point, however. I strongly supect that you'll never see the actuall die, it will be under a metal heat spreader. Because they can cope with higher temperatures [0], there is even less need to take the risk of mishandling breaking the die.
And lest you think that SiC would be less likely to break then silicon, I'm afraid not. Aside from the fact that many broken Athlons are due to the top few layers of SiO and metal breaking, SiC is not that tougher than silicon. As any lapidary will tell you, it's perfectly possible to chip saphire and diamond, if you're not careful.
Still, I can't deny that facts aside, it's a wonderfuly evocative metaphor.
[0] And how much higher! Silicon tops out at 350 C, SiC could operatate at 600 C, where is it glowing red hot! sourced from Nasa
The very murky situation of differing copyright laws rears it's head.
In the UK, the type of work dictates the duration of copyright. See, for example, here
In the USA, the type of authorship dictates the duration of copyright. See, for example, here
The fact that the performers tend to produce works for hire, and composers tend not to is a side distraction here. There are composers who produce works for hire, and performers who own thier own recordings - which really clouds things in the USA.
Oh, and the copyright terms in the USA are determined by authorship, not ownership. Thus, just because it's currently owned by a corporation doesn't make it a corporate authorship.
At least the justification for differening terms for personal or corporate authorship has some merit.
As it stands in the UK, making a film is clearly considered worth two and a half times as much as makeing a sound recording, and 5 times as much as writing a book (assuming that one of the director, authors or composer lives 50 years after making the film). Why? Well, I can find no good reason for it.
The fact that the BPI is lobbying for extension of the performer copyright duration is not the sum total of the issue.
There is a difference in duration between performer and composer copyright. This is _not_ the case with the US.
Thus, when people talk about the Beatles catalogue falling into public domain, what they mean is that the recordings they made do. The copyright on the lyrics and music lasts longer, but is liscecable under mechanical terms.
So, if there is no change in the law, come 2013, if you disribute the Beatles playing 'Love me do', then you will still need to pay the songwriter royalties. Thus, the argument the parent poster gives at the end is slightly off base, as it refers to songwriter copyright, not performance.
Quite frankly, I can see no benefit in different durations between performance and songwriting copyrights. Mind you, I'd lean to the lower limit rather than the higher, but the issue of what to set the duration at is a different point to whether there are differential terms for composers and performers.
... and whatever the equivelent is in other bootloaders.
I.e. with physical acess to the box (which, in the case of this software, you will), you can always recover a lost root password, by booting single user, and then changing it.
In the event that you've locked up your bootloader with a password, this util doesn't change that.
If you've really locked it up the wazoo with crypto all over the place, I think it's recoverable with a boot disc (as you'll have the bios password, or be able to wipe it, to re-enable booting from CD). Mind you, if you've done that then you're not likely to be the sort of person who needs this util.
Frankly, I'd agree with you about self-discipline - there are very few cases where an externally imposed discipline is useful as anything other than a tempory measure. This is not one of those cases, in my opinion.
It is, however, always worth knowing how to recover from any problem, where it is possible. Backups not needed in this case.
You are, indeed, quite correct.
The solubility doesn't go down again till the freezing point. My bad. For some reason, I was thinking of the density of water, which is just plain bizarre to get confused with.
The 'not freezing' requirement can be relaxed a little - a small (maybe 7-10 percent) ice crystals isn't a perceptable issue (from experience, with a -12 centigrade freezer). You're not going to be able to do cryogenic cooling without some ice being produced, in any real world sense, unless you stir it lots, which de-gasses the thing anyway.
Interesting result with freezing fizzy pop, by the way. I once left a bottle (plastic, 500ml) of soda in the freezer too long (by a couple of days), so that it was frozen solid. Opening the bottle (which is a pressure vessel), had the solid inside expand, and start to expand, until it was about 2 centimetres about the top of the bottle. I think that was the CO2 that was forced out of solution that expanded, with sufficent force to cause to ice to change shape. Very bizzare, if perfectly predicatable.
The problem with rapid cooling of carbonated drinks is that the solubility of CO2 in water decreases at low temperatures. And at high temperatures, the rate of de-sorption increases, just for kicks. It's a wonder any stays in the water at all.
Anyway, the ideal aim for speed cooling is to drop the temperature down to 'cold but drinkable' as rapidly as possible. Going below that temperature is as bad as not going cold enough.
As you noted, you need to get a rate of cooling such that the rate that gas is forced out of the drink is sufficently low.
What, then, is the rate of cooling? Well, it turns out (insert handwave here) that the rate of heat flow is determined by the difference in temperature. To a first approximation *handwave*, then, we can asses the rate of cooling by the temperature difference between drink and cooling medium.
Liquid nitrogen (LN2) is at 77 K. Room temperature is 298 K, giving a temperature difference of 220 K [0]. For comparison, the temperature difference between ice and room temperature (the annoyingly warm temperature soft drinks tend to be at) is 25 K. Thus we can consider that the rate of cooling from liquid nitrogen is about 10 times faster than from ice [1].
How long does it take to cool a soft drink with ice? Well, in my experience, about 20 seconds for around 330ml, with gentle agitation (i.e. a quick stir, or pouring over the ice). Thus the 'few seconds' the poster give for LN2 to hit freezing point is qualitativly correct [2].
The temperature of dry ice is 195 K, which gives around 125 K difference [3], thus an initial cooling rate around 5 times the heat transfer rate of ice, and half that of LN2. It's not quite, because thermal contact is better with the other two cases (liquid - solid interface, versus solid - solid for the dry ice [4]).
You could put the dry ice in the drink, or the LN2 in the drink. The problem with that is that if you drop the cold material in the drink, it might sink under the surface, flash freeze the surrounding liquid, and then turn to gas. This risks the ice exploding (and is more of an issue for dry ice than LN2).
The simplest way to avoid these problems is use enough coolant to get your drink down to ideal temperature, so that the whole mass of liquid will not freeze, always leaving a path for gas escape.
How much is that? Well, an estimate may be made as follows: If we assume that the coolant material are at the temperature of boiling/sublimation as appopriate, then the total energy absorbed per unit mass will be equal to the apporiate latent heat [5]. This allows a calculation of the mass required, if the total energy tobe removed from the drink is known.
If we assume [6] that the specific heat capacity (amount of heat energy taken to change the temperature of a substance) of the drink is equal to that of water, that gives a value of 4.2 kJ K-1 kg-1. Further, we assume that it's density is also equal to that of water, so that 1ml equals 1 g.
The appropriate specific latent heats for our coolants are: 199 kJ kg-1 for nitrogen and, surprisingly, 199 kJ kg-1 for CO2. I think that that great cosmic coincidence is proof that this sort of calculation is intended to occur.
Thus, to remove 25 K from 330ml of water, we need to remove 20 * 330 * 4.2 J = 27.7 kJ, if we take the desirable temperature of the drink to be 5 degrees centigrade. That's about 140 grammes of coolant.
The density of solid CO2: 1562 kg/
Oh, and "Period." is not a sentance. It's missing a verb. Unless your verbing [0] period, in which case there's a whole mess involving objects and subjects that you've missed out, assuming you're sticking to formal rules of grammar.
Alas, much as I would have liked OED not to list period as a verb, it's cited from back in 1595.
Oh, and for those who are interested, verb has been verbed for a while. The earlist citatation is 1936, from a poem, thus:
which seemed oddly appropriate, and a bit of a special case. After that the first verbing of verb was 1978.
[0] Do excuse. I verbed verb there.
Really, really don't.
E45 is made from Lanolin.
Now, if you read the label carefully, it claims it's "hypo-allergenic" lanolin.
That's a bunch of crap.
If you have an allergy related dermatitis, do _not_ use E45, or other lanolin based emollient. You end up with exposure to lanolin, and it is liklely that you will develop an allergic reacion to the lanolin.
That's what happend to me. Atopic dermatisis (aka eczema), and after about 8 months, I'd developed an allergy to lanolin so severe that I'd rather pour sulphuric acid over my skin, than put lanolin near it.
Now, you (the grandparent) may be lucky, and not become sensised to lanolin. It's not worth the risk - I can't handle most new woolen goods, because the traces of lanolin are there.
E45 is fine if you have unbroken, but dry, skin. That's not the case for people with chronic dermatitis.
What you actually want is aqueaus cream, or emulsifying ointment. Ask your pharmacist, they're about 1/3 the price for 4 times the volume, more effective, and not going to bite you in the ass later on.
Not quite. Unisys would be unable to distribute GPL code that implemented the ideas covered by a patent, that they were aware of, and that the patent holder had denied the use of said patent.
That is, if you don't know it's patented, you still distribute. 'Cos, like, otherwise we'd all be paralysed.
If they own the patent, and then distribute GPL'd code, that's implicitly that the patent is liscenced under a liscence that allows the downloader a patent liscence suitible to fufil the GPL.
Thing is, that's a liscence to distribute the code. Not use.
See, funny thing about the GPL is that you don't have to agree to it to use the code covered by it. Actually, it's not funny at all, it's the norm, just years of (very porbably bogus) EULA's make that less clear. So all the GPL covers is distribution of the code.
But, a patent requires a liscence to 'use' the patented invention.
So, Unisys could do the following:
1) Patent an idea.
2) Impement the idea in code.
3) Release the code under GPL, and not mention the patent.
4) Let it grow.
5) Point out that they only gave a patent liscence to re-distributed the code, not use it, and charge for it's use. Once it's popular.
6) Profit!
Any explicit mention of the patent would make the situation clear - either by explict licence, estoppel, or clear that you don't have that. No mention of the patent makes it really, really, hard. That's the first patent/copyright GPL hack.
Now, consider what happens if they add a patented algorithm to a GPL'd codebase. The only liscence they can put the implentation under is GPL. But they can stick a patent liscence on top of thier implemention, that effectivly prohibits re-disribution by parties other than themselves. What happens then?
Section 7 does not apply, becuase the condition is not _imposed_ on them - they have chosen that patent liscence. (Semantic's, perhaps. Still, that's one to be settled by the courts).
So, they can offer it for download, and then anyone who does get the patented implementation from them can't redistribute. That's a second hack.
Or, another option - offer a royalty-free liscence to use and redistribute the patented implemention (in effect, giving the implemention all the GPL-type conditions). Great, you think, and grab a copy, and modifiy and resdistribute.
They then change the patent liscence. What?! Well, it's an explict liscence, and if it doens't say that it's irrevokable, or if it has a clause that lets them change it a bit, then tough. Estoppel doesn't apply - the terms were explicit, and clear.
There are probably other hacks that can be applied in a situation with patents, but that's more than plenty to be getting on with.
No.
That's it, really. Patents are out of the scope of the GPL. The only way they interact is that if you don't have the rights to disribute the source (e.g. by patent liscence), you can't distribute the the binary.
It's oft talked about that patent might be a method of getting an end run around the GPL, and maintining restrictions on GPL'd code.
Yup.
There is, however, an interesting side effect to this. You slack, so that the system rots, so that slacking will be punished.
Except, the only way that this will work, is if slacking is punished (duh!), and we note that you are slacking. So, the slacker will suffer if it succeds.
Therefore, the ideal situation is if _everyone else_ slacks off, in a serious manner, and you don't, thereby accuring the benefit of the change in system.
My philosophy is rusty, but isn't this a prisoners dilemma? The ideal situation is for everyone else to cooperate with your plan, but for you to compete with them.
Hey, if you want that sort of service, may I suggest signingup with Free iKicks
Get enough people to signup, and it's free!
To clarify, I ment a reference to a single object within the loop, that being the only object within the loop that you still want. This can occur, for example, in a (not terribly great) implementation of a circularly linked list.
Hence, rather than being able to reclaim 14 or thereabouts objects worth of storage, the GC holds on to them. That's a programmer error, and wherein circular references can lead into memory 'leaks'.
It handles them fine.
The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.
Note that a manually managed memory model wouldn't nessecerily help in that situation - if you free() the objects you no longer need, not noticing that there is a cirular reference, you can end up with a particularly painful to sort out segmentation fault if you later acess that ciruclar reference (probably in a call to free() itself).
Let me draw an analogy here. Consider chemical lab monkey. Their job is mixing things to make stuff, and performing any one of a batch of analysis techniques.
The most important skill for them to have is good lab procedure - keeping thing clean, labeled, and not spilling things. Also, knowing what to do if one of the above is not true.
This does not need a degree in chemistry (and I say that as a chamietry graduate). The depth of understanding required isn't that great - once you know how to do a titration, you look up the precise set of reagents to use to perform a specifc test. Compare this to a programmer, whose is much the same situation - know the basic principles for a set of techniques, and then looks up the specifics if needed.
Chemistry is very slightly older than programing / computer science. So, if you look at how the split between laboratry workers and the hardline theorists worked out, that might give some insight into how the programming field might develop, right?
Well, there are no seperate qualifications for laboratory work. The nearest thing is stopping the path to a degree before graduauation - be it after highschool, or with something that's equivelent to the first year or two of a bachelors.
Most places, however, when they want some to work thats mostly turning the handle reactions or analysis look for a degree.
For good or ill, then, I suspect that trying to split off programming and CS will come to nothing.
Density Functional theory owes a lot to Kohn. He didn't come upwith the idea (that the properties of a system can be defined by the location and density of electrons), but he was involved with almost everything to turn it from an interesting idea into a useful theory.
Because he (along with Sham) provided the Kohn-Sham equations, pretty much every paper that does anything to DFT (as oposed to things with DFT, but even then, many do) cite one or two of his papers.
The reason DFT kicks arse as a calculation scheme is that it is proven to be able to be as good as any other method. It's also cheap to calculate, because it is localised (you only need to examing the vicinty of an area to calulate, as opposed to QM theories which require youto compare a spot with everything. Repeat (for both DFT and QM) for all points).
It, like all such methods, has it's foibles, but a good DFT schema (it's actually a class of methods, rather than a specific single one), can be as good in computational chemistry as things that take 2 to 5 times as long.
Heh, it's not as bad as it might sound.
The Fortran code solved a particular eigenvalue problem in a few manners, to get different bits of information. Main workhog, used parrallel algorithms.
The C code generated the set of input matrices for a spefic problem geometry. These were output into a text stream, passed to the Fortran routine. This means that the C code took input of number of atoms, orientation, interaction coefficents, and output some giant matrices.
The Fortran output was several sets of output from the various methods. Perl chunk, for the most part, selected the output chunk desired, and pretified it. For one particular type, it output Postscript.
So, the gist is that each indivdual part was seperate conceptually, and performed distinct roles. It would be feasable to run a specific job by piping the output of one stage to the input of the next. In practice, the runtimes of the Fortran stage was such that it was saved to disk, so the same output could be parsed in multiple ways.
I wrote the code, ran some stuff, forgot about it, and had to go back to it 2 years later. Despite a serious lack of comments, it took around 5 minutes to get familar with it enough to extend it for a totally different crystal system.
I fully agree with everything you wrote.
But your talking about 'most' hackers. Graham was talking about 'great' hackers. That's different things.
If you look at what a good joiner uses, you'll note that he has a large set of tools, and picks the right one. There is no advantage in trying to turn wood on a lathe with a screwdriver - that's the job of a chisel.
A similar thing applies with computational work. If you truely know what you are doing, you'll use the right tool for the job. If your wanting to accumulate a large set of facts, and then do some comparisons across that set of facts, that's a job for Prolog. No matter that C, or Java, or Perl, or whatever, is more popular. They are just a poor fit to the task, which would mean you'd need to write a predicate logic packeage in them, to get them to work.
Look at tools like FFTW. It's written in OCaml, and C. Two different languages, each used seperatly, to play to thier strengths. OCaml does tree parsing, and optimising of an abstract syntax tree. C code does the numerical heavy lifing. That's choosing the right (rather, a good, there is a pluraity of good tools for that) tool for the job. Trying to do the abstract syntax tree parsing in C, or the numerical heavy lifting in OCaml is just stupid - you'll end up with something that's nowhere near as good.
Try writing an OS kernel in Perl.
'Favourite language' is something that's not a good metric. I've solved problems (and that's what it's all about) using 50 lines of C feeding 100 lines of Fortran feeding 50 lines of Perl producing Postscript that compiled to the desired diagrams, because that's what suited the problem domains best.
Claiming that 'good hackers like language X' misses the whole point. Good hackers will use the best tool for the job.
Also, Graham seems to be conviently ignoring the 'can this be understood three years down the line' aspect. There is no point in having code that you can't maintain. That's where Java comes in - it's got a blend of power and syntactic salt help keep things maintainable. Asserting that maintainabilty isn't relevant just strikes me as something that's, well, immature.
Uh, Cray have a backlog of orders. A backlog to the tune of $153 million, if I recall correctly.
That's not the sign of a dying buisness model. If they are having problems, it's down to the mangement, not lack of demand.
There are problems that don't work well on clusters, but rocket on a proper supercomputer. These include a lot of interesting areas, there will always be demand for a few pieces of big iron. At the risk of echoing the ghost of IBM CEO's past, I think somewhere around 20-30 serious top end supercomputers in the world [0]. Most of the rest of the jobs will do just fine on high end clusters.
If you read the article, there are no quotes from Cray people. What there are quotes from is the people who used to get to play with special hardware, who now admin those clusters.
It's toys for the boys, not a buggy whip issue.
[0] That's informed by being someone who uses high perfromance computing, both cluster and supercomputer.
dtrace, due with Solaris 10 does that. So it's not quite a top equivelent, but it does laet you answear your questions ("What processes are kicking the shit out of the disk", and "By how much"), and long with the also useful "In what way" i.e. many small writes, hugh seek to read ratio, or what have you.
It is, however, expert driven, unlike top, which is simple to use. Still, I think that dtrace shows the furture of performance monitoring apps.
Note that dtrace lives partially in the kernel - it's not portable to Linux.
Not really. Computer magazines use 'off self' dating. That is, when the date listed on the magazine comes around, it should be removed from the newsagents shelf.
Most magazines use 'on date' dating, where they get put on the shelf when the date listed on them comes up.
Why the difference? Tradition mostly. The argument is that computer magazines need to seem as new as possible (cos the tech changes), moreso than most other magazines. Thus once one magazine went with 'off date' naming, the rest followed, rather than seem a month or so out of date.
Typically the magazine is on the shelves for a month, so a subscriber would be getting the magazine intended for same during August about now. That magazine will have September as the date written on it.
So, it's bizzare, counter intuative, but perfectly possible to quote a 'September' issue now.
He runs a web hosting firm. I forget what it's called, but that's also how he's able to donate all the bandwidth for Wikipedia, and where all the servers are located.
Gotta admit, saying that you host Wikipedia is a serious selling point, in terms of proving you can cope with a big site.
To be fair to the UK parliment, they knew that. As did the police. Some forces were for a new law, some were against.
In principle, the offence was covered under 'driving without due care and attention'. In practice, most people felt that they were in full control of the vehicle, whilst chatting on the phone (in spite of studies to the contrary) [0]. Mobile phone use was endemic, so the legistlative decided to make it perfectly clear that is was not accpetable, by a specific and clear new law.
I understand that, although there have been very few prosecutions, there has been a marked decrease in mobile phone use whilst driving. This may be considered a sucessful law, in that it has reduced the dangerous behaviour significantly.
In short, the aim of the law was to educate the driving public, rather that create a new offense. It has a achieved that aim.
[0] I'll note that techincally driving whilst intoxicated falls into exactly the same catagory. Sepcific laws allow for specific limits and additional penalties, but that is, in principle, all they add.
In a word, wrong. Maintinance.
It's cheaper repair a satelite than to put a new one in orbit. There are plenty one-off statelites up there that once they go, that's it. See, for example, the Hubble space telescope. It can do a lot of science, but it'll need some help soon, or it's a gonner. Is that worth sending a man up for? I think so.
Note that that doesn't require a continued presencein space, just send a crew of mechanics up every so often to keep things working. I accept that most manned space flights are redundant, but that doesn't mean that all of them are.