... things that that do not have a physical component cannot be stolen.
Well, I don't know about any hive mind, but to my mind, the term stealing means to deprive the rightful owner of something, and obtain it for oneself.
Copying an mp3 wouldn't meet that - as they original is still intact.
On the other hand, shaving time off from an employee time sheet _does_ in fact, deprive the rightful owner of something. Maybe it's not stealing by the law, but it's close enough for me to be comfortable with it. Consider if the manager had, instead, removed the equivelent money from a pay packet - wouldn't that be theft? Even if the pay packed was purely electronic?
And, as an addenda - removing money from someone's bank account without thier permission or knowlede would also be cassified as theft, yet nothing tangible is removed there. That's distinct from fruad, which is 'under false pretenses' - if there is no pretenses, then that's theft [0].
[0] Might be different in your juristriction. This is not legal advice - if you want legal advice consult someone qualified to practice in your juristriction.
I suspect that the reason that we haven't is partly conicedental, and partly not.
There's a degree of 'chance' that the IBM PC was on an 8088 in the first place. However, it's worth recalling that Intel chips have normally been quite tolerant, almost supportive, of self-modifiying code, than other chip designs [0]. That's a trend, and not specific.
But there are times where a self modifing algorithim is the neatest method to acomplishing things. Scince end user applications ceased to be written in assembler, that's prehaps a moot point, as ease of documentation is now seen as more important that those sorts of efficency (be it space or speed efficency). Back in the day, though, it was a used programming technique. Telling programmers that their application cant use certain techinques is not a good selling point - given that the gains wouldn't be anything the customer at that time.
In short, it would have prevented certain sets of techniques - and that would have been a barrier to adoption.
[0] For example, RISC architectures tend not to work well with self modifiying code. It's in caching, and pipeling depths.
Well, it's more interesting that the actual 'story'.
The GPL says that you can't apply constraints to people you distribute the software (or deriviative works thereof) to. Just using the software doesn't involve the GPL at all.
The nearest analogy is implmented a patented algorithim in GPL code. The patent holder has the right to require payment for the use of the algorithm, but the code is still GPL'd. Granted, it's messy, but all such corner cases are.
Plus, the GPL relies on the law for enforcement. Unless your a government, there is not way around that. If you _are_ a government [0], then you can change the law, and that's not a problem.
[0] Who doesn't are about things like the Berne convention.
... because if there is no copyright infringment, then all of SCO's FUD dissolves. They can't hold a contract dispute over the head of anyone wanting to use Linux like they could a copyright case. Once the copyright issue is put to bed, then the situation is cut and dried, for everyone except people who have done business with SCO.
ccache will cache the previous compiles, and, if they haven't changed at all, use the cached results. This allows the certianty of a clean build to be gained in significantly less time. Make won't do that, because it was just cleaned.
Additionally, I belive that ccache uses a global cache. So, if, for example, you are compiling a couple of linux kernals, each patched differently, some of the compilations will be the same between both trees. ccache will recognise this, and only compile once, and use the cached results the second time. This is impossible with make, as these are two different invocations of make.
ccache is not something that everyone needs. But for those doing lots of development, it can really save alot of wasted time.
First off the generalised methods you allude to are MPI, the older PVM, and there's Mosix too.
MPI and PVM are framework libraries that allow for code to be written to take parallelism into account. They tend to be used for numerics calculations (which was thier birthplace), simply because numerics are CPU bound. There are others, that are even more numerics centric (HPF - a Fortran varient, for example), but MPI should probably be the target of choice for new code, including non-numerics based calculations. Note that the term 'Beowulf cluster' implies MPI. The biggest point to note with MPI is that it allows for communication between nodes, and thus can be used for calulcations that are not trivially parralisable.
Mosix is subtle different. It's a patch to Linux that distributed processes across multiple boxes. This tends to work better for jobs with long runtimes, as opposed to many smaller duration processes, however. For example, Ralphzilla>
Parrallel applications need to be written to target MPI or PVM, whereas Mosix doesn't need special targeting. On the other hand, any multiprocessor aware application will be more efficent at using them than any automated solution. Still, Mosix may well be sufficent for most purposes.
The downside to MPI &c is that they require libraries installed. Which raises dependancies, so most such applications tend to use thier own libs, built in. This is actually not a bad idea - in that it allows more specific tailoring to take place. On the other hand, MPI &c libs can be tailored for a specific set up (e.g. using non-Ethernet conectivitiy - such as a mix of Ethernet, Myranet and Papers, for example). That's a little out of the intended usage for distcc, however, where minimal set up times are desired.
On the video front, then, transcode has a buildin cluster mode, for pretty much what you were talking about. Again, it's methods are all internal, but that's not an issue here.
Re:Why wasn't a factorial experiment used?
on
Optimizing distcc
·
· Score: 3, Interesting
Probably because it wasn't needed. And secondly, factorial DOE isn't as good as your implying it to be.
Factorial DOE is useful if you have multiple measurable, continious or quasi continous [0] factors, and want to optimise - particualry when there is some trade off. In this case, however, most of the variables that were altered were clearly discrete (This version of make, or that version of make, for example), or it was clear that the optimum was at an extreme (More CPU speed is always good, for example).
So, the factors I can see that would be suitable to a factorial DOE is the number of machines in the farm. Except, each machine is different, so that's effectivly an n-dimensional set, with 2 options on each dimension, for n machines. If your going to do the stats, you'd want to do them properly, so no handwaving them all together there.
Plus, this is a determanistic situation. There is no real need for empirical analysis - you can do it all from first principles, which would be much more efficent, I think. And, indeed, that's what the author did - by looking at the theoretical background of it all, to use different makes and so on, to optimise.
Finally, if you think that a factorial DOE will get you a global optimum solution, then your sadly mistaken. It's a good procedure for optimising, and it can avoid some local minima - but it's not guarenteed to find a global minima. The only guarenteed method I'm aware of is a synthetic annealing - and if you've got a faster method, I, and a large number of people doing numerical caluclations, would love to hear it.
Oh, and the aim here was _not_ to find a global minima. It was to get something that was good enough. Trying for better than that is wasted effort.
[0] For example, the set of integers, from 0 to 1000 is quasi continous. It's not really continous, but it's close enough for real purposes.
Whatever the intent, here is the result: Samba will be unable to develop new versions to follow MS changes without paying.
That is just plain wrong.
Samba team managed to remain interoperable through, what, Win 3.11 even, definitly Windows 95, 98, 98SE, ME, and NT 3.5, 2k, and XP series, without any acess to documentation, beyond what was freely available.
On what basis does making Microsoft make more information available to some other people make it more difficult for the Samba team to continue to do what they do, for future versions of Windows?
In short, Samba exists without Microsoft assistance. Forcing Microsoft to help a third party doesn't make it more difficult for Samba, at all.
(As an aside, given that the EU was only looking at Media players, I think that the API's will only be for Media playing interfaces - thus I don't think that, say, the printing subsystem, will bo covered in all this.)
Oh, and Samba doesn't _use_ any Windows API's. It uses the SMB protocol, and I've not seen anyone claim that Microsoft's protocols will have to be opened - the equivelent here would be the protocols that cover WMP to server negotiations, I think.
So, unless you want to point me to something I must have missed, I can't agree with you.
Re:watch the torrent go...
on
Thebroken Videos
·
· Score: 2, Interesting
Just run a HTTP connection to the tracker. btshowmetainfo from the offical bt dist will give you the tracker URL: in this case http://fpcat.homelinux.org:6969/
Stick that in a web browser, and ta-da! current stats report. I suspect that not all trackers support this, but this one does.
OpenFirmware for Intel is perfectly feasable - indeed, the portability of OpenFirmware was a design intent. No one makes such a board.
On the other hand, it wasn't an Intel creation, and thus is suffereing from NIH (Not Invented Here). Intel are looking at recasting the whole boot up process, but they're using thier own replacement, and not OpenFirmware. They call it EFI, see, for example, http://deviceforge.com/articles/AT8747644820.html
The claim is that Intel's solution is superior - and no doubt it is, in some technical aspects. However, comments like the parent show that a uniformity in boot up process would be worth a lot.
What this is, is if Linus (who I think personally owns the Linux trademark) starting up a company with some good mates, which takes the current Linux source, close-sources it and sells it for a profit with the name Linux 2 and takes the domain name, www.linux.com as his company's front.
He can't, as Linus doesn't own the copyright to all of the code in the current source. For example, there are major contributions by Alan Cox, Al Viro, IBM, and thousands of other, lesser known contributers. Unless, and until, he gets the agreement of each of those contributers, the current linux source cannot be used like that. I think that there are some contributers that would not agree to that (Alan Cox springs to mind here, as an example).
The major difference here is that Linux is copyrighted, under the GPL. Indeed, it's a desgin intent of the GPL to prevent such a situation.
The PG e-texts are public domain. There is no copyright on them. This is a fundemental difference.
That's an interesting question, but ultimaitly, I can't see there being anything interesting in these invisible sections.
It will only take one link to reconnect a seperate section. Whilst this may not be much for many networks, with search engines that walk the entire network, it's then going to re-enter the indicies. At this point, it's connected by more than one link, and thus a bit more robust.
So, these invisible sections will only contain things that no one links to - which is a pretty good definition of not interesting, in general.
The only exceptions would be very specialist sites, of little interest to the general populations. That's insufficiant to ensure seperation, because those specialist sites would have to be done by and for people that have no interest in the rest of the internet (think how many people link to where they work, or sites they developed, for example).
In short, I can't see any such search turning up anything worthwhile.
Yeah, I know. Problem is that in usage, it's meaning is nothing like anything that the word 'elite' actually means. Which is why I didn't try to translate it, because that would actually obscure information more than illuminate
To the best of my knowledge, there is no posibility of an all encompassing regular expression that can translate 1337 to english.
Not a perfect translation, no.
However, with a context free grammar (!) and some herustics with a spell checking engine, you can get conversion to something that is much more readable.
For example, I ran
1337 d00d> D000dZ! I R s0 1337!
through my munging engine and got
leet dude> Dudes! I are so leet!
(I prefer to leave 1337 as leet, cos I don't think it's really transatable to formal english.) It's not perfect, but the time to read drops down to something approaching printed english.
More relevently, as one can learn to read 1337 and other forms of munged english to the same speed as normal text, this step drastically cuts the learning time down, to about 20 minutes (for me, anyway).
So, what you say was strictly correct, but for practical purposes, the majority of it can be fixed. Certinally, for review by people not familar with it, it's handy. Still needs to have the original check, of course, but that would always have to happen anyway.
No, because it's perfectly possible to have code under two liscencesin the same program.
The problem arises when you want to change that liscence. Actually, it's two problems:
1) The contributors must all agree to the liscence change. If they don't, you have to back out thier code, or not change the liscence. That's the fundemental protection of copyright.
2) The new liscence is incomplatable with the GPL. Thus, you can't mix GPL code with code under the new XFree86 liscence. You could with the old liscence. This a result of the wording of the two liscences.
Neither problem existed prior to the liscence change.
If your doing 3D visulisation of data, that can be a lot of polygons.
I have tools that are available for both windows, and Linux.
If I load a protein molecule into them, Windows burps a little, and then smoothes out.
Linux doens't burp at all, and give a consistant 0.001 fps, if using software renderes.
Hell, I've seen some people consider a GeForce FX 5700 just to get something that will allow them to rotate big [0] molecules in nearly real time.
Who said it was games? Some people use this stuff for work. When you pay through the nose for enough CPU to work out the gemoetries in near real time, it bites a lot of ass that your display sub system can't keep up.
[0] Ok, obscenly big - something like 30 000 amino acids, so 350 000 atoms, each being a sphere. A lot of vertices.
1. Solid. 2. Liquid 3. Gas 4. Plasma 5. Bose-einstein condensate 7. Nemetic liquid crystals 8. Smetic liquid crystals 9. The other type of liquid crystals whoes name escapes me 10. Glass (Arguable) 11. That funky stuff that neurtron stars are made of 12-15 truely wierd QM stuff, like charmonium
And now, the newest member: 6
Maybe, just maybe, that's an over hyped term. There are lot's of states of matter. I've probably missed some.
Can we please kill the meme that there are only a very small number.
Well, hate to say it, but either you ran into the problems of SEM elemental amalysis, or the diamond's a fake.
Real, dug out of the earth diamonds, have a small quantity of nitrogen in them. In clear (D colour) diamonds, the nitrogen has paired up, and is clear. Individual nirtogen atoms are colour centres, and give it a yellow tint.
Plus, the edge of a diamond contains hyrdrogen.
No, what's far more likely is that you were using energy dispersive x-ray analysis. This only tests the spot illuminated by the electron beam, and is not the most sensitive method in in the world. It can't really pick up hydrogen and other light elements in trace quantities, and it's limit of detection is very likely to be below the levels of nitrogen in a gem diamond.
Note that EDX analysis doesn't penetrate deep into a material. That ring could have very easily been copper, and coated with gold, and EDX would still insist it was gold, because the penetration depth was fully within the gold layer [0].
IAAMS (I am a materials scientist) - I spend my masters thesis on an SEM. Doing a range of studies that hindged on the penetration depth.
The correct way to test the compounds would be to use a chemical assay, or some other precise method such as atomic absorbtion spectroscopy in a plasma flame or similar. Note that the acids in the testing compound would be more than capable of cutting through any organic binders to get to the silver. SEM EDX analysis is quick, but not any better than what they did use, in my opinion.
Note that if the silver was in a molecular compound of any sort then it's dubious that it's a fair thing to claim that it contains silver. This is because the reason for claiming the silver is the high thermal conductivity of silver metal. This does not apply to compounds of silver, and so counting those in something sold on it's thermal conductivity is somewhat misleading, in my opinion. I am a chemist too...
[0] Strictly, you have to calculate the deepest part of the penetration depth that the X-rays can escape from. Normally, the bottom of the penetration depth, but it might not be for something like gold. That's an assumption that would have to be checked for true rigour. The ZAF correction takes account of this to an extent, but I'd want to see detailed proof before making any quantitative statments.
In Canada, fruit flavoured juices are not allowed to have caffine added.
On the other hand, vegetable flavoured juices are. Thus cola's (flavoured from the cola nut, which is, apprently, a vegtable), and Irn-Bru (ordiginally a Scottish concoction, various vegetables) are avaialble caffineated.
Mountain Dew is the only well known fruit flavoured normally caffineated soda. (Well, I've never seen any others, and I'm a label reader to a freakish extent).
He could have ment Ogg, given that it's a container format, and can have various codecs embeded in it. He did not give enough infomation to be precise enough proven wrong in his statement i.e. it was not clear that Vorbis was, indeed ment. It's only wrong if you apply an unprovable assumption to his words.
Morale of this? Someone's going to reply to me, pointing out the pedantic mistake I probably made.
It's not a tempory name. That's it's offical IUPAC name. The other, more informal names, are the offical-yet-unoffical names.
The methodical naming scheme was broguht in to remove the hissy fits and cat fights that were going on over who made the stuff first (traditionally, the first discoverer got to name the thing). So, IUPAC decided to tell them all to sod off, and went with the Un...ium naming scheme.
It also simplyfies the memoriseing all the name, although that's a minor point.
You'll find that, outside people who actually deal with the stuff, Ununnilium is what it's called.
As an aside, the -ium suffix jsut means it's an element. the suffix has an interesting history, originally meaning element, then there was a monve to restrict it to only metals, but a number of misclassifiactions diluted the usefulness of that. Still, most of the time, if it ends in -ium, it's a metal.
Or, alternativly, why not? If it's just because your not used to it, then ponder it a bit more.
if/usr/lib/prog stored all the information that prog required, then it would be simpler to cleanly uninstall, and to bundle, a working application.
Why not reserve/etc for system-wide configuration, and put program specific information somewhere where it is clear that it's program specific?
Is there a good reason that configuration data must be all the way across the filesystem from the rest of the program? If you have a range of different machines, doing different tasks, all using one program in different manners, and NFS mount/usr, then yes. Note that this approach would have a program reside entierly reside in/usr/lib/prog, except for the primary binary, which would be in/usr/bin.
Now, POSIX may be broken because it's inconsitant (some per-prog configuation in/etc, some in/usr/lib/prog), but that's a seperate issue.
One big advantage of this approach would be for a large number of systems, that NFS mount/usr. Now, in order to update the program, or to adjust it's settings, you change one set of files, and it is automatically replicated, throught the NFS mounts. If the configureation was seprate, then a new version that required a change in configuration files would result in having to change the file on all the machines, or some ugly hack invloving lot's of symlinks in/etc. And hope that you never have to add a new program to/usr, or it's time to go around all the boxes manually again. This sort of configuration is desirable on Beowulf clusters.
I fell into the trap of assuming that the amount of money that Microsoft made was the same as the high street sale price. That is clearly false.
It is normal that the manufactor recieves around 50% of the normal sale price for the goods. The remainder is eaten by distribution, shop costs (e.g. staff) and so on.
This does not invalidate the above particularly much, except that the actual estimates for the cost of the system are now off, by around a factor of two. The profit/loss made doesn't change, thus the major point is intact.
This makes my assesment of the cost no longer agree with one of the linked artickles, making me question the validity of any other information from it - specifically, the royalty per game that microsoft makes. Can anyone corroborate (or otherwise) that information?
Slashdot Mirror
Well, I don't know about any hive mind, but to my mind, the term stealing means to deprive the rightful owner of something, and obtain it for oneself.
Copying an mp3 wouldn't meet that - as they original is still intact.
On the other hand, shaving time off from an employee time sheet _does_ in fact, deprive the rightful owner of something. Maybe it's not stealing by the law, but it's close enough for me to be comfortable with it. Consider if the manager had, instead, removed the equivelent money from a pay packet - wouldn't that be theft? Even if the pay packed was purely electronic?
And, as an addenda - removing money from someone's bank account without thier permission or knowlede would also be cassified as theft, yet nothing tangible is removed there. That's distinct from fruad, which is 'under false pretenses' - if there is no pretenses, then that's theft [0].
[0] Might be different in your juristriction. This is not legal advice - if you want legal advice consult someone qualified to practice in your juristriction.
I suspect that the reason that we haven't is partly conicedental, and partly not.
There's a degree of 'chance' that the IBM PC was on an 8088 in the first place. However, it's worth recalling that Intel chips have normally been quite tolerant, almost supportive, of self-modifiying code, than other chip designs [0]. That's a trend, and not specific.
But there are times where a self modifing algorithim is the neatest method to acomplishing things. Scince end user applications ceased to be written in assembler, that's prehaps a moot point, as ease of documentation is now seen as more important that those sorts of efficency (be it space or speed efficency). Back in the day, though, it was a used programming technique. Telling programmers that their application cant use certain techinques is not a good selling point - given that the gains wouldn't be anything the customer at that time.
In short, it would have prevented certain sets of techniques - and that would have been a barrier to adoption.
[0] For example, RISC architectures tend not to work well with self modifiying code. It's in
caching, and pipeling depths.
Well, it's more interesting that the actual 'story'.
The GPL says that you can't apply constraints to people you distribute the software (or deriviative works thereof) to. Just using the software doesn't involve the GPL at all.
The nearest analogy is implmented a patented algorithim in GPL code. The patent holder has the right to require payment for the use of the algorithm, but the code is still GPL'd. Granted, it's messy, but all such corner cases are.
Plus, the GPL relies on the law for enforcement. Unless your a government, there is not way around that. If you _are_ a government [0], then you can change the law, and that's not a problem.
[0] Who doesn't are about things like the Berne convention.
Ur, he asked 2 things. One was about frameworks, the other was for an application. I covered both - see transcode mentions.
make clean && make
ccache will cache the previous compiles, and, if they haven't changed at all, use the cached results. This allows the certianty of a clean build to be gained in significantly less time. Make won't do that, because it was just cleaned.
Additionally, I belive that ccache uses a global cache. So, if, for example, you are compiling a couple of linux kernals, each patched differently, some of the compilations will be the same between both trees. ccache will recognise this, and only compile once, and use the cached results the second time. This is impossible with make, as these are two different invocations of make.
ccache is not something that everyone needs. But for those doing lots of development, it can really save alot of wasted time.
Yes and no.
First off the generalised methods you allude to are MPI, the older PVM, and there's Mosix too.
MPI and PVM are framework libraries that allow for code to be written to take parallelism into account. They tend to be used for numerics calculations (which was thier birthplace), simply because numerics are CPU bound. There are others, that are even more numerics centric (HPF - a Fortran varient, for example), but MPI should probably be the target of choice for new code, including non-numerics based calculations. Note that the term 'Beowulf cluster' implies MPI. The biggest point to note with MPI is that it allows for communication between nodes, and thus can be used for calulcations that are not trivially parralisable.
Mosix is subtle different. It's a patch to Linux that distributed processes across multiple boxes. This tends to work better for jobs with long runtimes, as opposed to many smaller duration processes, however. For example, Ralphzilla>
Parrallel applications need to be written to target MPI or PVM, whereas Mosix doesn't need special targeting. On the other hand, any multiprocessor aware application will be more efficent at using them than any automated solution. Still, Mosix may well be sufficent for most purposes.
The downside to MPI &c is that they require libraries installed. Which raises dependancies, so most such applications tend to use thier own libs, built in. This is actually not a bad idea - in that it allows more specific tailoring to take place. On the other hand, MPI &c libs can be tailored for a specific set up (e.g. using non-Ethernet conectivitiy - such as a mix of Ethernet, Myranet and Papers, for example). That's a little out of the intended usage for distcc, however, where minimal set up times are desired.
On the video front, then, transcode has a buildin cluster mode, for pretty much what you were talking about. Again, it's methods are all internal, but that's not an issue here.
Probably because it wasn't needed. And secondly, factorial DOE isn't as good as your implying it to be.
Factorial DOE is useful if you have multiple measurable, continious or quasi continous [0] factors, and want to optimise - particualry when there is some trade off. In this case, however, most of the variables that were altered were clearly discrete (This version of make, or that version of make, for example), or it was clear that the optimum was at an extreme (More CPU speed is always good, for example).
So, the factors I can see that would be suitable to a factorial DOE is the number of machines in the farm. Except, each machine is different, so that's effectivly an n-dimensional set, with 2 options on each dimension, for n machines. If your going to do the stats, you'd want to do them properly, so no handwaving them all together there.
Plus, this is a determanistic situation. There is no real need for empirical analysis - you can do it all from first principles, which would be much more efficent, I think. And, indeed, that's what the author did - by looking at the theoretical background of it all, to use different makes and so on, to optimise.
Finally, if you think that a factorial DOE will get you a global optimum solution, then your sadly mistaken. It's a good procedure for optimising, and it can avoid some local minima - but it's not guarenteed to find a global minima. The only guarenteed method I'm aware of is a synthetic annealing - and if you've got a faster method, I, and a large number of people doing numerical caluclations, would love to hear it.
Oh, and the aim here was _not_ to find a global minima. It was to get something that was good enough. Trying for better than that is wasted effort.
[0] For example, the set of integers, from 0 to 1000 is quasi continous. It's not really continous, but it's close enough for real purposes.
That is just plain wrong.
Samba team managed to remain interoperable through, what, Win 3.11 even, definitly Windows 95, 98, 98SE, ME, and NT 3.5, 2k, and XP series, without any acess to documentation, beyond what was freely available.
On what basis does making Microsoft make more information available to some other people make it more difficult for the Samba team to continue to do what they do, for future versions of Windows?
In short, Samba exists without Microsoft assistance. Forcing Microsoft to help a third party doesn't make it more difficult for Samba, at all.
(As an aside, given that the EU was only looking at Media players, I think that the API's will only be for Media playing interfaces - thus I don't think that, say, the printing subsystem, will bo covered in all this.)
Oh, and Samba doesn't _use_ any Windows API's. It uses the SMB protocol, and I've not seen anyone claim that Microsoft's protocols will have to be opened - the equivelent here would be the protocols that cover WMP to server negotiations, I think.
So, unless you want to point me to something I must have missed, I can't agree with you.
Just run a HTTP connection to the tracker. btshowmetainfo from the offical bt dist will give you the tracker URL: in this case http://fpcat.homelinux.org:6969/
Stick that in a web browser, and ta-da! current stats report. I suspect that not all trackers support this, but this one does.
OpenFirmware for Intel is perfectly feasable - indeed, the portability of OpenFirmware was a design intent. No one makes such a board.
On the other hand, it wasn't an Intel creation, and thus is suffereing from NIH (Not Invented Here). Intel are looking at recasting the whole boot up process, but they're using thier own replacement, and not OpenFirmware. They call it EFI, see, for example, http://deviceforge.com/articles/AT8747644820.html
The claim is that Intel's solution is superior - and no doubt it is, in some technical aspects. However, comments like the parent show that a uniformity in boot up process would be worth a lot.
He can't, as Linus doesn't own the copyright to all of the code in the current source. For example, there are major contributions by Alan Cox, Al Viro, IBM, and thousands of other, lesser known contributers. Unless, and until, he gets the agreement of each of those contributers, the current linux source cannot be used like that. I think that there are some contributers that would not agree to that (Alan Cox springs to mind here, as an example).
The major difference here is that Linux is copyrighted, under the GPL. Indeed, it's a desgin intent of the GPL to prevent such a situation.
The PG e-texts are public domain. There is no copyright on them. This is a fundemental difference.
S. John Ross made a list of plots at http://www.io.com/~sjohn/plots.htm
The RPG references pencil and paper RPG's, but it's still pretty insightful when applied to computer games.
That's an interesting question, but ultimaitly, I can't see there being anything interesting in these invisible sections.
It will only take one link to reconnect a seperate section. Whilst this may not be much for many networks, with search engines that walk the entire network, it's then going to re-enter the indicies. At this point, it's connected by more than one link, and thus a bit more robust.
So, these invisible sections will only contain things that no one links to - which is a pretty good definition of not interesting, in general.
The only exceptions would be very specialist sites, of little interest to the general populations. That's insufficiant to ensure seperation, because those specialist sites would have to be done by and for people that have no interest in the rest of the internet (think how many people link to where they work, or sites they developed, for example).
In short, I can't see any such search turning up anything worthwhile.
Yeah, I know. Problem is that in usage, it's meaning is nothing like anything that the word 'elite' actually means. Which is why I didn't try to translate it, because that would actually obscure information more than illuminate
Not a perfect translation, no.
However, with a context free grammar (!) and some herustics with a spell checking engine, you can get conversion to something that is much more readable.
For example, I ran
through my munging engine and got
(I prefer to leave 1337 as leet, cos I don't think it's really transatable to formal english.) It's not perfect, but the time to read drops down to something approaching printed english.
More relevently, as one can learn to read 1337 and other forms of munged english to the same speed as normal text, this step drastically cuts the learning time down, to about 20 minutes (for me, anyway).
So, what you say was strictly correct, but for practical purposes, the majority of it can be fixed. Certinally, for review by people not familar with it, it's handy. Still needs to have the original check, of course, but that would always have to happen anyway.
No, because it's perfectly possible to have code under two liscencesin the same program.
The problem arises when you want to change that liscence. Actually, it's two problems:
1) The contributors must all agree to the liscence change. If they don't, you have to back out thier code, or not change the liscence. That's the fundemental protection of copyright.
2) The new liscence is incomplatable with the GPL. Thus, you can't mix GPL code with code under the new XFree86 liscence. You could with the old liscence. This a result of the wording of the two liscences.
Neither problem existed prior to the liscence change.
If your doing 3D visulisation of data, that can be a lot of polygons.
I have tools that are available for both windows, and Linux.
If I load a protein molecule into them, Windows burps a little, and then smoothes out.
Linux doens't burp at all, and give a consistant 0.001 fps, if using software renderes.
Hell, I've seen some people consider a GeForce FX 5700 just to get something that will allow them to rotate big [0] molecules in nearly real time.
Who said it was games? Some people use this stuff for work. When you pay through the nose for enough CPU to work out the gemoetries in near real time, it bites a lot of ass that your display sub system can't keep up.
[0] Ok, obscenly big - something like 30 000 amino acids, so 350 000 atoms, each being a sphere. A lot of vertices.
"sixth form of matter"
So, let's count, shall we - we have:
1. Solid.
2. Liquid
3. Gas
4. Plasma
5. Bose-einstein condensate
7. Nemetic liquid crystals
8. Smetic liquid crystals
9. The other type of liquid crystals whoes name escapes me
10. Glass (Arguable)
11. That funky stuff that neurtron stars are made of
12-15 truely wierd QM stuff, like charmonium
And now, the newest member: 6
Maybe, just maybe, that's an over hyped term. There are lot's of states of matter. I've probably missed some.
Can we please kill the meme that there are only a very small number.
Yours, a miffed quantum materials physicist
Well, hate to say it, but either you ran into the problems of SEM elemental amalysis, or the diamond's a fake.
Real, dug out of the earth diamonds, have a small quantity of nitrogen in them. In clear (D colour) diamonds, the nitrogen has paired up, and is clear. Individual nirtogen atoms are colour centres, and give it a yellow tint.
Plus, the edge of a diamond contains hyrdrogen.
No, what's far more likely is that you were using energy dispersive x-ray analysis. This only tests the spot illuminated by the electron beam, and is not the most sensitive method in in the world. It can't really pick up hydrogen and other light elements in trace quantities, and it's limit of detection is very likely to be below the levels of nitrogen in a gem diamond.
Note that EDX analysis doesn't penetrate deep into a material. That ring could have very easily been copper, and coated with gold, and EDX would still insist it was gold, because the penetration depth was fully within the gold layer [0].
IAAMS (I am a materials scientist) - I spend my masters thesis on an SEM. Doing a range of studies that hindged on the penetration depth.
The correct way to test the compounds would be to use a chemical assay, or some other precise method such as atomic absorbtion spectroscopy in a plasma flame or similar. Note that the acids in the testing compound would be more than capable of cutting through any organic binders to get to the silver. SEM EDX analysis is quick, but not any better than what they did use, in my opinion.
Note that if the silver was in a molecular compound of any sort then it's dubious that it's a fair thing to claim that it contains silver. This is because the reason for claiming the silver is the high thermal conductivity of silver metal. This does not apply to compounds of silver, and so counting those in something sold on it's thermal conductivity is somewhat misleading, in my opinion. I am a chemist too...
[0] Strictly, you have to calculate the deepest part of the penetration depth that the X-rays can escape from. Normally, the bottom of the penetration depth, but it might not be for something like gold. That's an assumption that would have to be checked for true rigour. The ZAF correction takes account of this to an extent, but I'd want to see detailed proof before making any quantitative statments.
It's not specific to cola.
In Canada, fruit flavoured juices are not allowed to have caffine added.
On the other hand, vegetable flavoured juices are. Thus cola's (flavoured from the cola nut, which is, apprently, a vegtable), and Irn-Bru (ordiginally a Scottish concoction, various vegetables) are avaialble caffineated.
Mountain Dew is the only well known fruit flavoured normally caffineated soda. (Well, I've never seen any others, and I'm a label reader to a freakish extent).
He could have ment Ogg, given that it's a container format, and can have various codecs embeded in it. He did not give enough infomation to be precise enough proven wrong in his statement i.e. it was not clear that Vorbis was, indeed ment. It's only wrong if you apply an unprovable assumption to his words.
Morale of this? Someone's going to reply to me, pointing out the pedantic mistake I probably made.
It's not a tempory name. That's it's offical IUPAC name. The other, more informal names, are the offical-yet-unoffical names.
The methodical naming scheme was broguht in to remove the hissy fits and cat fights that were going on over who made the stuff first (traditionally, the first discoverer got to name the thing). So, IUPAC decided to tell them all to sod off, and went with the Un...ium naming scheme.
It also simplyfies the memoriseing all the name, although that's a minor point.
You'll find that, outside people who actually deal with the stuff, Ununnilium is what it's called.
As an aside, the -ium suffix jsut means it's an element. the suffix has an interesting history, originally meaning element, then there was a monve to restrict it to only metals, but a number of misclassifiactions diluted the usefulness of that. Still, most of the time, if it ends in -ium, it's a metal.
Because that's where they belong?
/usr/lib/prog stored all the information that prog required, then it would be simpler to cleanly uninstall, and to bundle, a working application.
/etc for system-wide configuration, and put program specific information somewhere where it is clear that it's program specific?
/usr, then yes. Note that this approach would have a program reside entierly reside in /usr/lib/prog, except for the primary binary, which would be in /usr/bin.
/etc, some in /usr/lib/prog), but that's a seperate issue.
/usr. Now, in order to update the program, or to adjust it's settings, you change one set of files, and it is automatically replicated, throught the NFS mounts. If the configureation was seprate, then a new version that required a change in configuration files would result in having to change the file on all the machines, or some ugly hack invloving lot's of symlinks in /etc. And hope that you never have to add a new program to /usr, or it's time to go around all the boxes manually again. This sort of configuration is desirable on Beowulf clusters.
Or, alternativly, why not? If it's just because your not used to it, then ponder it a bit more.
if
Why not reserve
Is there a good reason that configuration data must be all the way across the filesystem from the rest of the program? If you have a range of different machines, doing different tasks, all using one program in different manners, and NFS mount
Now, POSIX may be broken because it's inconsitant (some per-prog configuation in
One big advantage of this approach would be for a large number of systems, that NFS mount
I fell into the trap of assuming that the amount of money that Microsoft made was the same as the high street sale price. That is clearly false.
It is normal that the manufactor recieves around 50% of the normal sale price for the goods. The remainder is eaten by distribution, shop costs (e.g. staff) and so on.
This does not invalidate the above particularly much, except that the actual estimates for the cost of the system are now off, by around a factor of two. The profit/loss made doesn't change, thus the major point is intact.
This makes my assesment of the cost no longer agree with one of the linked artickles, making me question the validity of any other information from it - specifically, the royalty per game that microsoft makes. Can anyone corroborate (or otherwise) that information?