I can think of two ways, of the top of my head. Note that the 'equation' is, as with mathematical desrciptions of relationships, just a method of formal statment, and need not 'look like' a typical mathematical equation.
The first, and probably the simplest, is to use a formal description of a state machine. Thus, the system is normally in the 'wait for input state', and then it branches to a state determined by the type of user input. This encapsulates the interactive element in a single part, and closely resembles the typical structure of most GUI systems (with callbacks etc).
The other method is to treat the system as a function of infinite arguments and use combinator logic. Curry all the arguments into the function, up to the latest existsing, then as each piece of new input occurs, add another argument, and curry it out. Something like an RDBMS is probably better suited to this sort of desription.
This is, I think, an impure calculus - currying is normally invoked to allow description of multiargument functions withing lambda calculus which requires single argument functions. Nevertheless, I can see no major hurdles to describing a program in such a manner.
Granted, I've not had the chance to express any non-trivial programs in either form as yet (lack of time), but I think that some programs are better suited to one representation that the other.
Worth noting that there is no change in the description if the input is known all a priori, and processed from a file, or if it's all garnered piecemeal. Consider a shell script for an example where this is obvious.
A mouse action is probably best represented by a tuple of tuples, giving button down and button up coordinates - thus ((10,10),(20,10)) represnts a mouse drag action, and clicks fall out as degenerate coordinates.
Alternativly, for another option, look at how a pure functional language does a GUI. For example, the wxHaskell bindings for, (unsurprisingly) Haskell. Haskell (a pure functional language with lazy evaluation) programs are just an implementation of a mathematical model of computation. Here, the description is effectivly as a set of functions, where the 'user input' determines which function to run [0]. Techincally, this is no longer a set of equations, however I can prove that this is equivelent to the state machine description above.
Any errors, feel free to correct - this is all a bit rough and ready. I just felt that it was worth pointing out that just because it might be absurb, doesn't make it impossible. For example, the halting problem seems absurb to everyone whose not studied it (because it's obvious if a program will finish).
[0] Or something close to that. I'm not intimatly familer with either the language or the bindings, so I might be a little of with the description.
Replying to myself, because I just had one of those silly ideas, that Might Just Work (tm).
You know how the TV remote gets lost from time to time? And it's always a pain to find. Or that the remote is the other side of the room, so you have to walk away from the TV, pick it up, and end up moving further than to the TV itself?
Put a microphone on the set top box, and use voice recognition instead / as well as a remote.
Sonic contamination is easily solved, by subrtracting out of the picked up audio the TV stream.
Use a keyword, then a simple set of commands (chanel up / down, jump to channel, volume up / down, mute, maybe some menu/PVR functions).
For those that use MythTV boxes, this should be straightforward to set up, although subtracting out the final audio stream might be tricky. Might not be needed, depends on the room geometry.
That's the power of open source - no need to wait for someone else to implement it. I'm off to see if I can persuade mplayer and Sphinx to comunicate...
You are, of course, perfectly correct in everything you said.
There are a number of HCI aspects where speech recognition is not a good solution.
However, let me enumerate a number of other ones, where it's superior:
Minutes of meetings, or similar. Imagine having a verbatim record of a discussion there by the time you get back to your desk.
Someone who cannot type - e.g. no hands. Rare, granted, but still a viable use.
Someone whose hands are busy. The cannonical example here is a pathologist doing an autopsy, where they dictate everything. Speech recogition saves time in transcription (and money for the audio typist).
I'd love to be able to issue voice commands to a computer, for a few, isolated cases. For example, diagnosing hardware. Bring up a doc, and be able to get the computer to flip pages, without having to remove the probes from the hardware. Re locating them is a pain, and sucks time.
Moreover, I'm certain that there are others, some of which will only be realised when it's common and cheap enough to be widely available.
It's like a mouse. It's one of the worst general purpose input devices for a computer [0], but it's excels at indicating a single element on a display. The mouse and keyboard complement each other, and there are a bunch of other, more specifc input devices, such as the graphics tablet. I have no doubt that if speech recognition was as accurate and reliable as a graphics tablet, it would get a similar amount of use.
[0] Try inputing a block of prose with only a mouse. Even specilist software makes it only suck marginally less.
RTLinux Realtime microkernel/macrokernel work. Hell, it _is_ patented.
ReiserFS Filesystem based on dancing trees, with a plugin archtecture.
ZisoFS Transparant handling of compressed ISO9660 filesystems.
Seperate LLC stack. Logical Link Control is handled by a single stack, rather than embeded into underlying protocols.
InterMezzo Distributed filesystem, with network interrupt transparacy.
Now, I grant that not everone will agree that all of the above is patentable. On the other hand, the current bar for US software patents appears to be the 'one click' patent.
Most of the above focus on transpency of clever behaviour - as befits an OS. Most of Linux is not particularly surprising, but the above are some of the more unusual features, or unsual apsects thereof.
It is idiotic to correlate the amount of information in a signal path with its quality.
By this 'logic' the lossless codec FLAC is only half the quality of CD. No matter how I look at it, I can't make that 'observation' make sense.
Secondly, you are deliberatly ignoring parts of the parents post. He clearly said that you can't assume that the quality scales linearly with the bandwidth.
Yout argument also appears to apply equally to just removing random parts of a CD audio stream until it was of an equal bitrate to MP3. I hope all can see that that is not correct.
May I suggest that you look into signal to noise ratios, dynamic range, time-frequency domain transformations and psycho acoustic masking to see exactly why your original assertion was wrong.
Re:How Things Work
on
Security Alert
·
· Score: 2, Interesting
It always amazes me that geeks think that everyone should know how a computer works. Why?
Whilst I don't fall into that catagory, I can explain that attitude.
I don't use anything that I don't understand how it works, and that I don't know how to construct at least a basic version of it. Thus, I can't design a state of the art VLSI chip, but I could make a transistor, and assemble discretes into logic blocks, and make a basic computer out of logic blocks.
Same goes for a car, a CRT, plastic bottle, door (hinge, lock, woodworking), etc.
In fact, I even know how to recognise basic mineral ores, and how to smelt them. I have cast and forged basic metal objects.
From where I sit, the surprising thing is that people are happy to use things they don't understand why they work, rather than the reverse.
No doubt a history geek would find it shocking that I don't have a clue about the causes, aims nor outcome of the Boer war. There are merits to both points of view, but I'm not surprised that one is expoused more than the other on here.
... and establish proof for a long-believed philosophy many have about file-sharing: that it actually benefits the industry.
Fairplay to the author - that admission of bias was early on, and upfront. However:
Each submission has been analyzed by hand and bogus or questionable entries falling into the test window were discarded.
Without the author giving stricter criteria here, one is left wondering if data that did not fit with the authors thesis was 'questionable' - it certianally would fly against his expectations, but that does not make it nesecerally invalid. Granted, given it was on here, there was probably a crapflood from the trolls that was justifiably deleted - but a reader cannot be certain it was just crap that was deleted.
There is also a serious flaw in premise with the study.
Digital media provides a means of gratification that is usually only temporal, like sex or good barbecue.
Full-length movie downloads have also led to many sales.
The latter quote is somewhat opposed to the former. If the value of a film is ephemeral, as the former implies, why do people purchase it? Both cannot be literly true.
The discussion of TV shows suggests there there needs to be a way for people to preview the shows, before purchasing, in order to drive sales. Doesn't the broadcasting of these shows on TV count?
From my reading of the report, the only thing I can draw from it reliably is: that some section of the people who download media later go on to purchase it.
That's not a strong conclusion, and skirts around some far more interesting (although much harder to answear) questions, such as: What proportion of illegal downloads lead to a sale? How many people would have puchased something if they could not have downloaded it, and how does that vary? [0]
In short, I don't feel anymore informed about anything after reading this report.
[0] For example, I think that highly marketed items (e.g. blockbuster films) and essentially not-marketed items (e.g. music from some unknown band) would show a difference here.
The Atkins diet, as descibed by the various books and articles from Atkins, is not that bad, in principle. Let me distil down the logic behind it:
1) People eat too much. 2) Eating less just makes you hungry. Ergo, it's difficult. 3) If you look at the rates of ``fullness'' to calories, carbohydrates are way down the list. 4) Thus, if you skip the carbs for a while, it lets the body get used to lower total volume of food, without feeling hungry. 5) After the body is used to lower volumes of food, replace the highly energy dense foods with low energy density foods. 6) Loose weight.
Thus, the whole diet is just a hack, to get people to eat less without going through the tough phase of being hungry at the start.
Note that step 4 is to ``skip'' the carbs. That is, eat the steak, and the veg, skip the fries. Not, eat a bigger steak in place of the fries. That defeats the point.
When viewed in this manner, the Atkins approach has some merit.
Of course, as we all know, when you take a hack, and run with it for a long period, it creates it's own problems. Hack's work for a short period, to get a job done, and then should get refactored into something more wholistic.
What really gets my hackles up is when people order a meal, skip the starchy part, but order a double 'non starchy' part. Way to miss the point!
That goes for everything, be it beer, crisps, hamburgers, apples, lettuce, hell - even water [0]. Get it out of balance, and it's a problem.
Accordingly, some bad qualities != Unhealthy. For example, my natural [1] diet is too low in salt [2]. So, the odd bag of crisps is not a bad thing [3] for me. On the other hand, I know someone whose got high blood pressure - a single bad of can push him towards the danger area - it's a very bad thing for him. Most people, are in the middle.
With that in mind, what does this research actually mean, for the average person? Bugger all. The odd beer won't hurt, and hey, has some good points too. Too much is still bad.
May I reccomend, "Total diet approach to communicating food and nutrition information", J Am Diet Assoc 2002;102:100, available from http://www.eatright.org/Public/GovernmentAffairs /9 2_adar_0102.cfm for some further reading.
And, if your looking for antioxidents, eat more raw fruit and veg. Particular foods may have more than others, but, frankly, if you are worried about antioxident intake, then either any will help, or your micromanaging your food intake excessivly. The human body is not a brittle thing - we've lasted this long by being able to live on a range of inputs, so just eat a broad range, and let the body do it's thing.
[0] Although, granted, drinking too much water is damn hard to do without some other contributry factor. [1] By natural, I mean the diet I would eat if I didn't really think about it - just eat what I want, when I want. [2] By too low, I mean averages 500mg of salt daily. Reccomended is 1-3g, recommended limit 6g. [3] Better would be to have it more evenly distributed, prehaps.
Yeah, you can do it with sudo. It's painful. Not so much sudo itself, but supporting generalised X11 authentication methods is.
That would be a HUGE waste of CPU, and a lot of lag as well. Plus, it requires a few setup steps, since X11 isn't forwarded by default.
Not that big a waste of CPU. In particular, if you are using a web browser, it's most likely a desktop, with spare CPU anyway. At time when CPU usage peaks, it tends to be opposite from when you want to use the browser. In other words, typical useage says the CPU is spare, most of the time. And I didn't start with the caveat 'if you have CPU to burn'. [0]
As for lag, I don't notice anything parceptable, on an Athlon 1.3 GHz. Maybe 100ms or so additional, when I change tabs.
If you don't forward X11 over ssh by default (my bad, I do it by default, due to it being a staple task), then it's not 'a few setup steps' - it's a -X switch, so the command line becomes "ssh -X dummy@localhost riskyapp".
Note also that the ssh hack above works transparently if you are running on a remote server (which, personally, I often am). Concerns about CPU useage have more validity here.
If you really want to go the sudo route, then you need three step - set up X11 authentication, run the app, and then tear down the authentication.
Unfortunatly, the tear down step is complicated by the problem of lanching two apps - if you tear it down whilst another app is running, that's going to cause problems. On the other hand, leaving the authentication after it's needed, for a UID that's intended for sandboxing, is not desireable. I can see no clear solution, short of sophisticated coding.
Anyway, the following should work, but not fully tested: put the following line in/etc/sudoers [1] user ALL=(dummy) NOPASSWD:/usr/bin/mozilla,/usr/X11R6/bin/xauth where user is your username, and dummy is the sandpit username. Replace specific programs with 'ALL' if you want acess to all programs.
Each time, run the following: xauth extract localhost/unix:0 | (HOME=~dummy; sudo -u dummy xauth merge -) HOME=~dummy; sudo -u dummy mozilla
replacing localhost with the machine name. That is likely to work, but there are a few gotchas: If your not using xauth, I dunno. If you're only using xhost [2], then it's trivial. Other authentication methods, see the manual. There are complex interactions with paths, and permissions here. It's brittle.
Tear down is simple to do: HOME=~dummy; sudo -u dummy xauth delete localhost/unix:0
Deciding when to run that is left as an excercise for the reader.
In closing, it should be clear why I recommended the ssh hack - much simpler, it takes care of all the tough bits, and I've not noticed any perceptable lag in general. Still, there's the outline. Feel free to test and improve.
[0] If you really want to, you can configure ssh and sshd to support the 'none' cipher. Every single deployment I've seen doesn't allow it, but it does have it's occasional uses. That would be the ideal situation here, if not for setup complexity (compile your own), and the fact is allows accidental security gaps. [1] Use visudo as root. [2] I laugh at you. There is no point using a sand pit if you use only xhost.
Probably the simplest option is to run Firefox as a different user. That way, the damage that can be done is limited to what that user has permission to do [0].
It's so simple, I'll be back in a couple of minutes once I've done it..
Done it, make that 25 seconds. Most of that was updating authentication tokens for the new user.
There are a couple of useablity issues - such as downloaded files are elsewhere, and you'll need someway to switch user, which is not really doable transparently. Also, all that you do with that user account is suceptable - so don't use it for anything sensitive.
One main problems: 1) It needs acess to the X display. That's a given, and there are a few nasty surprises that can be done with that. That would be the case no matter what, (chroot etc) however.
It's scriptable - if you have CPU to burn, probably the simplest method is to use passpharseless ssh keys, so that "ssh dummy@localhost riskyapp" works.
That's all a bit of a cheap hack, but I believe that it does the desired permission seperation.
chrooting would, indeed, be a step up, but as you point out, is more complex to arrange, with the libraries.
[0] Barring any local root holes, which is an orthogonal issue.
HyperThreading presents a virtual CPU - there are the same number of compuational units in the core. The speed advantage from HT is that with threaded code, there is additional silicon to save the state of each thread.
With the same number of execution units, however, you can't get better then optimal for a single non-HT CPU; once all the execution units are full, that's it, whether it's one thread or two.
HT is a great boost for a threaded app where it is not CPU bound in general.
On the other hand, a second CPU carries an aditional set of execution units; that means you can, in theory double the CPU output.
Neither helps with the memory - cpu bandwidth issues, which can limit performance. Dual CPU can mitigate that with dual memory controllers (see, e.g. Opteron), but that has it's own complications.
So, HT is a small step between dual CPU, and dual CPU.
However, even the most optimistic benchmarks from Intel that I have ever seen quote a 30ish% speed increase with HT. I have never, ever, seen anyone claim that HT can give a 100% speed boost - can you reference that claim?
I quote from http://www.intel.com/business/bss/products/hyper th reading/server/index.htm":
While Hyper-Threading Technology will not provide the level of performance scaling achieved by adding a second processor, benchmark tests show some server applications can experience a 30 percent gain in performance.
The advantages become apparent when you have a large number of identical systems. Even more so when you want them diskless.
That description matches an compute farm in the next room [0]. It also handles the case of 'diskless' install with a local disk, used for application specific working space [1].
Hell, in the next building there is a beowulf of 32 nodes that hasn't bee updated because the updating of 32 nodes wasn't automated, and time crunch [2]. If it's all from a single image, that's trivial to update the lot.
Sure, there are methods of doing all that as it stands. I am unaware of any other distro that has suport for it in mainline.
Oh, lets not forget about the 50 odd machines in the labs. They're all set up for Windows, but something like this would let them boot to Linux, without reformatting disks. I smell an 'over the holidays' compute farm - think over the week of the Christmas break... that's a lot of sums.
There's a few places where I might use something like this. All those have been solved elsewhere, but it would make a number of things much simpler to do.
[0] So to speak. It's actually round the corner, along a bit, and behind a door from my office. [1] computational chem - 6 GB of precomputed lookuptables, or thereabouts. [2] No, not mine.
I think that a fork of the codebase is in order. I hope that they're not pinned to the curent version. Something to check, I suspect.
Re:Interested, but confused by Apache License 2.0
on
APR 1.0.0 Goes Gold
·
· Score: 3, Informative
Disclaimer: Your not paying for this; this is not legal advice. For that, contact a lawyer in your juristriction.
By my reading of the liscence, it makes absolutly no distinction between static and dynamic linking. Therefore, the only way that it could cause a difference is within the definition of a 'derived work'. To quote the licence:
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
If you link, or bind by name, to the interfaces of the Work, then your code is not a derived work. Thus, the only applicable terms in the licence are those that govern use and distribution of the code. The licence grants you the right to distribute in source or object form the work.
Accordingly, my reading is that this is semantically virtually equivlent to the BSD licence for case specified (and, in fact, the same as BSD for pretty much any case of use and distribution).
Short answer: Stick a mention of it in the NOTICE text file, tell people what liscene the Work (in this case the APR) was under, and go ahead.
Interestingly, this licence would, as I read it, allow you to make a derived work, and redistribute that in binary form only. It doesn't grant you the right to change liscence, or apply restrictions, so a Derived Work wouldn't work as a commerical product (as the first purachaser can redisribute it).
But, as it specifically excludes linking to the interfeces specified, then for a Work which is a library [0], the only clause that imparts any restriction is 4(d) [1]
In fact, I can see no part of the liscence that would prevent one from taking a program under this liscence, creating a Derived Work that is that program implemented as a library, with well defined interfaces, and then linking to said library from a commercial/closed program. There is no requirement to publish Derived Works [2]. The only mildly non-obvious outcome is that if the library was extracted from the final disribution, the licence allows for its free distribution and use, which is not a restriction.
Of course, if this is for commerical software, you'll have the money to speak to a lawyer licence to practice in your juristriction first.
[0] And where that library is used unmodified [1] And the expiration of patent licences in event of you issuing a patent suit. [2] Only that you make any changes clear if you do publish.
SPF is part of a domain record, and specifies who can send email from that domain.
It does _not_ specify who can sent email from an netblock.
Thus, if you wish to send email not through your ISP's SMTP server, you require to have your own domain. This is not considered a major problem, given that the majority of people who wish to bypass thier ISP's SMTP servers do so _because_ they have their own domain for email.
The only people who would lose under SPF would be those people who wish to use a domain name, but not the SMTP servers for that domain. This is prevented, because that's the modus operendi of spam.
So, if you get your own domain, and add the IP of your home network to the DNS record, and that would all work.
Downside: You either need a static IP (or 'nearly static' - a dynamic IP that you know will be stable over a long period), or to set the SPF records over the large netblock that you will be on. The former is slightly more expensive (typically), the latter is less secure.
I genuinly can't see an issue with that as a scheme, and I certinally can't see a better way.
Worst case scenario: You need to get a domain name (around what, 10 bucks a year), and set the allowed range to your ISP's dialup pool.
Heh, I did think that a coin was a bit too large for photonic momentum to have an observable effect. Looks like that's already proven. Ah, well, ignore the specifics, and just look at the principle
The think about physics rather than economics is that physics is based of repeated and repeatable observations. Economics, at the mico level at least, is based of human preferences - where you can end up with (where x > y should be read as 'x is preffered over y') a > b AND b > c AND c > a.
There is no good mathematical way of doing much with that set of relationships. within physics, however, the field of statistical mechanics is all about relating microstates to macroscopic observables. There is no generally applicable equivelent in economics.
Quantum mechanics and newtonian physics are not mutually exclusive. As you increase the sizes of things involved, the equations that govern QM reduce to the Newtonian equivelents. Newtonian physics (that which is obervable to most people) is a simpler model.
Likewise, the equations for relativistic motion reduce to the Newtonian equations as you slow things down. There is some disconnect between QM and relativity, but that's getting esoteric - for the most part they coincide.
Prehaps the most direct example of the connection between microstates and macroscopic observables is within something like the Onsager solution [0] for a 2 dimensional square lattice. This has direct applications for a single layer of a magnetic material, and has been observed with a single layer of NiO. Onsager's particularly impressive (and turgid) analysis calculates the partition function of the system - from which all of the macroscopic observables related to the microstates can be derived.
Anyway, the partition function is the key that link the microscopic states and macroscopic states. If you want to look into the link between micro and macro, that is where to start (it's part of statistical mechanics).
Not heard micro/macro economists debate directly, but I've heard it mentioned before.
[0] Lars Onsager, Phys. Rev. 65, 117 (1944). I'd advise against reading it - I've yet to meet more than a handful of people who understand it all. Still, it's an impressive piece of work.
The problem is, however, that the random nature of quantised states exerts some influcence on macroscopic states. It's not very big. In fact, it's posivtly tiny (other wise the quantum nature of things would have explored sooner). Let me give an example.
Light has momentum. The solar sail is the most direct application of this.
Consider a coin toss. In the average place where it takes place, there is uneven illumination. That is, as the coin is spinning, there will be time where the illumination on one side is different to the other. So far this is still accontable for.
However, some of the incoming light will be absorbed by the material of the 'coin', which will enter an excited state, and then later re-emit that light. There is a hugh amount of photochemistry which relies on this sort of behaviour.
So, as the coin is spining in the air, the momentum from reflected light is calculable. Let's ignore the effect of absorbing the light, and focus on the re-emmision which will apply some momentum. In what direction is the light re-emited?
Well, that's a tough question. Most importantly, as the coin is spinning in the air, it depends on the time between absorbtion and re-emmision. That's a quantum phenonema, and is randomly distributed in a Gaussian disribution about some mean.
So, to calculated the effect of the coin toss exactly, you need to account for all those quantum effects. Which is impossible, because they are random.
I accept my example is a little contrived, in that the effect of the differential momentum transfer by photonic processes is negligable for any real coin, compared to other factors. It is, however, not zero, and is a solid example of how the randomness of quantum events effects macroscopic observables.
Given enough time, the fuzzyness of the quantum states gradually takes over. For most things that's a long time - it is, however, non zero.
The only point where I might even question this is with quantam states, and even there we really know precious little.
Uh, sort of. Heisenbergs uncertinty principle can be read as "We can never know the details" of quantum states. If it is true, then it does not matter whether or not a quantum state could be determanitsic if we can measure the things we need to determine it.
Now, there is an awful lot of discoveries and technology that have been predicated on Heisenbergs principle being true (or, at least, true enough, for some value of enough) [0]. Thus, the burden of proof is heavily on the side of anyone claiming that it's not valid (just as it is for anyone claiming Einsteins relativity is wrong, and as it was for Einstien when he showed Newton was wrong [1]).
So, I refute your claim on 'It's too early', by Schottky diodes, Mossbauer spectroscopy and quantum computing, which all rely on quantum states having true randomness [2].
Furthermore, by the way, there was a bunch of work on something called the Bell inequality, which, although painfully esoteric in testing, has disproved the existance of hidden variables. That is, it is _not_ the case that quantum states are deterministic, by data we can't measure. There are no such hidden bits of data.
Moreover, pretty much every macroscopic physical observable is a statistical average of very many microscopic states or events. These microstates are randomly distributed within some known distribution (e.g. disribution individual molectular kinetic energies for a given temperature of a set of particles). The various physical laws that we depend on (in the case of temperature, the predicability of the increase in the rate of some chemical reaction with increasing temperature, for example) have the concept of this random disribution so inherent in them, that I must argue that if 'random' is a a human thought construct, it is fortunate that the laws of nature also think that way (i.e. random is a physical concept)
Such is the opinion of this quantum physicist, at any rate.
[0] E.g Mossbauer spectroscopy [1] Strictly, Newton was farsighted enough to state his basic assumptions expcitly. Einstein just showed that one of them ("Time is the same for all men") was incorrect, and the consequences of it. [2] Or, at very least, something that is indistinguisable from it.
took into account the links _to_ a page as a measure of it's relevence.
The idea being that the more linked to a page is, the more value it has - thereby using people as a way of meauring the worth of a page. By examing the words people link with, as well as allowing Googlebombing, it sidesteps meta-tag pollution etc.
Been de-emphasised, compared to other sub-algorithms, but it's not just the appearence that set google apart in the early days. Before they had ad's.
"Early days" *shiver* I can remeber when AltaVista was the pinnicle of web searching, and using Archie and Veronica.
The way you want to define the compexity of the solution makes it the same as the compexity of the problem. That's a perfectly valid defintion, but that's not the one the author uses (clearly).
What I think the author means is that the difficulty to understand the code that is the solution increases 100% for every 25% increase in the difficutly to understand the details of the problem.
That's clumsy language, but I think it gets the gisty of the point over.
By example, if you have a hunk of code that does something subject to 4 independant constraints, applying a 5th indepentant constraint will increase the volume and turgidity of the code by around 100%.
Not sure I agree with the precise numbers, but the principle is roughly there.
If printing it out is not an option, displaying it in a different font, in a different size, ideally with differnt line breaks (hard for code, possible for other things) is almost as good.
The aim of printing or reformating is to change the text, and force you to actually read the letters that are on the page. This is done by destroying the patterns in the positioning of the text that the writer is used to, thereby hindering recall.
This is one of the reasons LaTeX is useful (for me, at any rate), because it does all of the above, without actually printing it (written in 10 pt monospaced Courier, read is 12pt Times New Roman, 1.5 spaced, paginated). Most literate programming schemes also have this as a side effect, notably Web derived scheme which output LaTeX. I've always wondered how much that contributes to the sucess of those methods.
Not meaning to be (overly) pedantic, but that's not wear. Wear is caused by bits rubbing over each other.
This is not just a semantic difference. The failure modes of silicon chips are mostly diffusion limited - that it, the metal conductors expand, the pn junctions become more diffuse, vacencies develop in the silicon, and so on. The failure mode of a part which wears is generally that the wear causes a mechanical weakness in a part till it breaks, bends, or is otherwise no longer functional.
This difference is reflected in the time to failure of different devices. Electronics show a bathtub curve - essentially, manufacturing defects show up in young failures, then after a period (around 8 - 10 months), there is no intrinsitic source of failure other than the (slow) diffusion limited modes, so there number of devices failing drop very low, until that mode dominates, at sometime around 8-10 years after manufacture.
Mechanical parts also show young failures, but, due to wearing, they do not last as long, and the rate of failures does not drop as low. The exact duration is determined by the type of use of the part. For example, this motor here *clunk* has bushes and brushes that have a design life of 1 months constant use, which translates to about 4 years with typical uses patterns. On the other hand, the motor in a washing machine is rated for something like 2 years constant use. The washing machine motor has bigger bushes and brushes, which are designed to last longer.
I could go on, but a) it gets boring rapidly, and b) I'd have to did out some notes on it, and cba.
In 10 years with computers, which gives experince with devices up to 20 years old, I have seen 1 case of failure in a componant over 3 months old that was not caused (directly or indirectly [0]) by mechanical wear.
Having said all that, Flash memory is not as reliable as most electronics, as it has a particular structure that causes insulator breakdown after around 1000 writes. But that's not _really_ wear, although I'm told it has a similar failure profile.
Not moving parts does not translate to no deterioration, but it _does_ mean no wear.
[0] Couple of times, power supply fans died, power supply overheats, fails, and frys electronics.
Nah, you just use a diamond saw. Same as for the silicon wafers. It's conceptually the same thing as a very thin diamond tipped grinding wheel, and it grinds a cut through the material. You can also use a diamond encrusted wire as a saw, like, erm, this one *holds one up*, but they are much slower, and only really good as hand saws, or for chopping thin sheets [0].
It's going to be a little slower, as SiC is about twice as hard as silicon, but that's not going to slow it down that much. Diamond saws are also used to chop up boules of sapphire and ruby, which are of similar hardness to SiC (a little softer), and also diamond (harder), so it's no big techical problem.
Or, a laser. A nice big excimer laser would slice it neater than a diamond saw. With the improved surface texture after cutting, the decrease is polishing coupled with the increase in hardness might make it worth while. Probably not, though.
[0] I use my saw for cutting rocks for lapidary purposes, principly quatrz of various sorts.
Slashdot Mirror
I can think of two ways, of the top of my head. Note that the 'equation' is, as with mathematical desrciptions of relationships, just a method of formal statment, and need not 'look like' a typical mathematical equation.
The first, and probably the simplest, is to use a formal description of a state machine. Thus, the system is normally in the 'wait for input state', and then it branches to a state determined by the type of user input. This encapsulates the interactive element in a single part, and closely resembles the typical structure of most GUI systems (with callbacks etc).
The other method is to treat the system as a function of infinite arguments and use combinator logic. Curry all the arguments into the function, up to the latest existsing, then as each piece of new input occurs, add another argument, and curry it out. Something like an RDBMS is probably better suited to this sort of desription.
This is, I think, an impure calculus - currying is normally invoked to allow description of multiargument functions withing lambda calculus which requires single argument functions. Nevertheless, I can see no major hurdles to describing a program in such a manner.
Granted, I've not had the chance to express any non-trivial programs in either form as yet (lack of time), but I think that some programs are better suited to one representation that the other.
Worth noting that there is no change in the description if the input is known all a priori, and processed from a file, or if it's all garnered piecemeal. Consider a shell script for an example where this is obvious.
A mouse action is probably best represented by a tuple of tuples, giving button down and button up coordinates - thus ((10,10),(20,10)) represnts a mouse drag action, and clicks fall out as degenerate coordinates.
Alternativly, for another option, look at how a pure functional language does a GUI. For example, the wxHaskell bindings for, (unsurprisingly) Haskell. Haskell (a pure functional language with lazy evaluation) programs are just an implementation of a mathematical model of computation. Here, the description is effectivly as a set of functions, where the 'user input' determines which function to run [0]. Techincally, this is no longer a set of equations, however I can prove that this is equivelent to the state machine description above.
Any errors, feel free to correct - this is all a bit rough and ready. I just felt that it was worth pointing out that just because it might be absurb, doesn't make it impossible. For example, the halting problem seems absurb to everyone whose not studied it (because it's obvious if a program will finish).
[0] Or something close to that. I'm not intimatly familer with either the language or the bindings, so I might be a little of with the description.
Replying to myself, because I just had one of those silly ideas, that Might Just Work (tm).
You know how the TV remote gets lost from time to time? And it's always a pain to find. Or that the remote is the other side of the room, so you have to walk away from the TV, pick it up, and end up moving further than to the TV itself?
Put a microphone on the set top box, and use voice recognition instead / as well as a remote.
Sonic contamination is easily solved, by subrtracting out of the picked up audio the TV stream.
Use a keyword, then a simple set of commands (chanel up / down, jump to channel, volume up / down, mute, maybe some menu/PVR functions).
For those that use MythTV boxes, this should be straightforward to set up, although subtracting out the final audio stream might be tricky. Might not be needed, depends on the room geometry.
That's the power of open source - no need to wait for someone else to implement it. I'm off to see if I can persuade mplayer and Sphinx to comunicate...
You are, of course, perfectly correct in everything you said.
There are a number of HCI aspects where speech recognition is not a good solution.
However, let me enumerate a number of other ones, where it's superior:
Minutes of meetings, or similar. Imagine having a verbatim record of a discussion there by the time you get back to your desk.
Someone who cannot type - e.g. no hands. Rare, granted, but still a viable use.
Someone whose hands are busy. The cannonical example here is a pathologist doing an autopsy, where they dictate everything. Speech recogition saves time in transcription (and money for the audio typist).
I'd love to be able to issue voice commands to a computer, for a few, isolated cases. For example, diagnosing hardware. Bring up a doc, and be able to get the computer to flip pages, without having to remove the probes from the hardware. Re locating them is a pain, and sucks time.
Moreover, I'm certain that there are others, some of which will only be realised when it's common and cheap enough to be widely available.
It's like a mouse. It's one of the worst general purpose input devices for a computer [0], but it's excels at indicating a single element on a display. The mouse and keyboard complement each other, and there are a bunch of other, more specifc input devices, such as the graphics tablet. I have no doubt that if speech recognition was as accurate and reliable as a graphics tablet, it would get a similar amount of use.
[0] Try inputing a block of prose with only a mouse. Even specilist software makes it only suck marginally less.
Now, I grant that not everone will agree that all of the above is patentable. On the other hand, the current bar for US software patents appears to be the 'one click' patent.
Most of the above focus on transpency of clever behaviour - as befits an OS. Most of Linux is not particularly surprising, but the above are some of the more unusual features, or unsual apsects thereof.
Whilst I don't fall into that catagory, I can explain that attitude.
I don't use anything that I don't understand how it works, and that I don't know how to construct at least a basic version of it. Thus, I can't design a state of the art VLSI chip, but I could make a transistor, and assemble discretes into logic blocks, and make a basic computer out of logic blocks.
Same goes for a car, a CRT, plastic bottle, door (hinge, lock, woodworking), etc.
In fact, I even know how to recognise basic mineral ores, and how to smelt them. I have cast and forged basic metal objects.
From where I sit, the surprising thing is that people are happy to use things they don't understand why they work, rather than the reverse.
No doubt a history geek would find it shocking that I don't have a clue about the causes, aims nor outcome of the Boer war. There are merits to both points of view, but I'm not surprised that one is expoused more than the other on here.
Fairplay to the author - that admission of bias was early on, and upfront. However:
Without the author giving stricter criteria here, one is left wondering if data that did not fit with the authors thesis was 'questionable' - it certianally would fly against his expectations, but that does not make it nesecerally invalid. Granted, given it was on here, there was probably a crapflood from the trolls that was justifiably deleted - but a reader cannot be certain it was just crap that was deleted.
There is also a serious flaw in premise with the study.
The latter quote is somewhat opposed to the former. If the value of a film is ephemeral, as the former implies, why do people purchase it? Both cannot be literly true.
The discussion of TV shows suggests there there needs to be a way for people to preview the shows, before purchasing, in order to drive sales. Doesn't the broadcasting of these shows on TV count?
From my reading of the report, the only thing I can draw from it reliably is: that some section of the people who download media later go on to purchase it.
That's not a strong conclusion, and skirts around some far more interesting (although much harder to answear) questions, such as: What proportion of illegal downloads lead to a sale? How many people would have puchased something if they could not have downloaded it, and how does that vary? [0]
In short, I don't feel anymore informed about anything after reading this report.
[0] For example, I think that highly marketed items (e.g. blockbuster films) and essentially not-marketed items (e.g. music from some unknown band) would show a difference here.
3) What does ZFS offer over AdvFS?
Granted, Solaris hasn't been EOL'd and Tru64 has, but I fail to see anything meaningful [0] that ZFS does that AdvFS doesn't.
[0] dtrace is a seperate thing, although I supose ZFS has hooks for it. The 128 bit filesystem is just excessive.
The Atkins diet, as descibed by the various books and articles from Atkins, is not that bad, in principle. Let me distil down the logic behind it:
1) People eat too much.
2) Eating less just makes you hungry. Ergo, it's difficult.
3) If you look at the rates of ``fullness'' to calories, carbohydrates are way down the list.
4) Thus, if you skip the carbs for a while, it lets the body get used to lower total volume of food, without feeling hungry.
5) After the body is used to lower volumes of food, replace the highly energy dense foods with low energy density foods.
6) Loose weight.
Thus, the whole diet is just a hack, to get people to eat less without going through the tough phase of being hungry at the start.
Note that step 4 is to ``skip'' the carbs. That is, eat the steak, and the veg, skip the fries. Not, eat a bigger steak in place of the fries. That defeats the point.
When viewed in this manner, the Atkins approach has some merit.
Of course, as we all know, when you take a hack, and run with it for a long period, it creates it's own problems. Hack's work for a short period, to get a job done, and then should get refactored into something more wholistic.
What really gets my hackles up is when people order a meal, skip the starchy part, but order a double 'non starchy' part. Way to miss the point!
...only a healthy diet.
s /9 2_adar_0102.cfm
That goes for everything, be it beer, crisps, hamburgers, apples, lettuce, hell - even water [0]. Get it out of balance, and it's a problem.
Accordingly, some bad qualities != Unhealthy. For example, my natural [1] diet is too low in salt [2]. So, the odd bag of crisps is not a bad thing [3] for me. On the other hand, I know someone whose got high blood pressure - a single bad of can push him towards the danger area - it's a very bad thing for him. Most people, are in the middle.
With that in mind, what does this research actually mean, for the average person? Bugger all. The odd beer won't hurt, and hey, has some good points too. Too much is still bad.
May I reccomend, "Total diet approach to communicating food and nutrition information", J Am Diet Assoc 2002;102:100, available from
http://www.eatright.org/Public/GovernmentAffair
for some further reading.
And, if your looking for antioxidents, eat more raw fruit and veg. Particular foods may have more than others, but, frankly, if you are worried about antioxident intake, then either any will help, or your micromanaging your food intake excessivly. The human body is not a brittle thing - we've lasted this long by being able to live on a range of inputs, so just eat a broad range, and let the body do it's thing.
[0] Although, granted, drinking too much water is damn hard to do without some other contributry factor.
[1] By natural, I mean the diet I would eat if I didn't really think about it - just eat what I want, when I want.
[2] By too low, I mean averages 500mg of salt daily. Reccomended is 1-3g, recommended limit 6g.
[3] Better would be to have it more evenly distributed, prehaps.
Yeah, you can do it with sudo. It's painful. Not so much sudo itself, but supporting generalised X11 authentication methods is.
Not that big a waste of CPU. In particular, if you are using a web browser, it's most likely a desktop, with spare CPU anyway. At time when CPU usage peaks, it tends to be opposite from when you want to use the browser. In other words, typical useage says the CPU is spare, most of the time. And I didn't start with the caveat 'if you have CPU to burn'. [0]
As for lag, I don't notice anything parceptable, on an Athlon 1.3 GHz. Maybe 100ms or so additional, when I change tabs.
If you don't forward X11 over ssh by default (my bad, I do it by default, due to it being a staple task), then it's not 'a few setup steps' - it's a -X switch, so the command line becomes "ssh -X dummy@localhost riskyapp".
Note also that the ssh hack above works transparently if you are running on a remote server (which, personally, I often am). Concerns about CPU useage have more validity here.
If you really want to go the sudo route, then you need three step - set up X11 authentication, run the app, and then tear down the authentication.
Unfortunatly, the tear down step is complicated by the problem of lanching two apps - if you tear it down whilst another app is running, that's going to cause problems. On the other hand, leaving the authentication after it's needed, for a UID that's intended for sandboxing, is not desireable. I can see no clear solution, short of sophisticated coding.
Anyway, the following should work, but not fully tested:
put the following line in
user ALL=(dummy) NOPASSWD:
where user is your username, and dummy is the sandpit username. Replace specific programs with 'ALL' if you want acess to all programs.
Each time, run the following:
xauth extract localhost/unix:0 | (HOME=~dummy; sudo -u dummy xauth merge -)
HOME=~dummy; sudo -u dummy mozilla
replacing localhost with the machine name. That is likely to work, but there are a few gotchas:
If your not using xauth, I dunno. If you're only using xhost [2], then it's trivial. Other authentication methods, see the manual.
There are complex interactions with paths, and permissions here. It's brittle.
Tear down is simple to do:
HOME=~dummy; sudo -u dummy xauth delete localhost/unix:0
Deciding when to run that is left as an excercise for the reader.
In closing, it should be clear why I recommended the ssh hack - much simpler, it takes care of all the tough bits, and I've not noticed any perceptable lag in general. Still, there's the outline. Feel free to test and improve.
[0] If you really want to, you can configure ssh and sshd to support the 'none' cipher. Every single deployment I've seen doesn't allow it, but it does have it's occasional uses. That would be the ideal situation here, if not for setup complexity (compile your own), and the fact is allows accidental security gaps.
[1] Use visudo as root.
[2] I laugh at you. There is no point using a sand pit if you use only xhost.
Probably the simplest option is to run Firefox as a different user. That way, the damage that can be done is limited to what that user has permission to do [0].
It's so simple, I'll be back in a couple of minutes once I've done it..
Done it, make that 25 seconds. Most of that was updating authentication tokens for the new user.
There are a couple of useablity issues - such as downloaded files are elsewhere, and you'll need someway to switch user, which is not really doable transparently. Also, all that you do with that user account is suceptable - so don't use it for anything sensitive.
One main problems:
1) It needs acess to the X display. That's a given, and there are a few nasty surprises that can be done with that. That would be the case no matter what, (chroot etc) however.
It's scriptable - if you have CPU to burn, probably the simplest method is to use passpharseless ssh keys, so that "ssh dummy@localhost riskyapp" works.
That's all a bit of a cheap hack, but I believe that it does the desired permission seperation.
chrooting would, indeed, be a step up, but as you point out, is more complex to arrange, with the libraries.
[0] Barring any local root holes, which is an orthogonal issue.
HyperThreading presents a virtual CPU - there are the same number of compuational units in the core. The speed advantage from HT is that with threaded code, there is additional silicon to save the state of each thread.
With the same number of execution units, however, you can't get better then optimal for a single non-HT CPU; once all the execution units are full, that's it, whether it's one thread or two.
HT is a great boost for a threaded app where it is not CPU bound in general.
On the other hand, a second CPU carries an aditional set of execution units; that means you can, in theory double the CPU output.
Neither helps with the memory - cpu bandwidth issues, which can limit performance. Dual CPU can mitigate that with dual memory controllers (see, e.g. Opteron), but that has it's own complications.
So, HT is a small step between dual CPU, and dual CPU.
However, even the most optimistic benchmarks from Intel that I have ever seen quote a 30ish% speed increase with HT. I have never, ever, seen anyone claim that HT can give a 100% speed boost - can you reference that claim?
I quote from
http://www.intel.com/business/bss/products/hype
The advantages become apparent when you have a large number of identical systems. Even more so when you want them diskless.
That description matches an compute farm in the next room [0]. It also handles the case of 'diskless' install with a local disk, used for application specific working space [1].
Hell, in the next building there is a beowulf of 32 nodes that hasn't bee updated because the updating of 32 nodes wasn't automated, and time crunch [2]. If it's all from a single image, that's trivial to update the lot.
Sure, there are methods of doing all that as it stands. I am unaware of any other distro that has suport for it in mainline.
Oh, lets not forget about the 50 odd machines in the labs. They're all set up for Windows, but something like this would let them boot to Linux, without reformatting disks. I smell an 'over the holidays' compute farm - think over the week of the Christmas break... that's a lot of sums.
There's a few places where I might use something like this. All those have been solved elsewhere, but it would make a number of things much simpler to do.
[0] So to speak. It's actually round the corner, along a bit, and behind a door from my office.
[1] computational chem - 6 GB of precomputed lookuptables, or thereabouts.
[2] No, not mine.
I think that a fork of the codebase is in order. I hope that they're not pinned to the curent version. Something to check, I suspect.
By my reading of the liscence, it makes absolutly no distinction between static and dynamic linking. Therefore, the only way that it could cause a difference is within the definition of a 'derived work'. To quote the licence:
If you link, or bind by name, to the interfaces of the Work, then your code is not a derived work. Thus, the only applicable terms in the licence are those that govern use and distribution of the code. The licence grants you the right to distribute in source or object form the work.
Accordingly, my reading is that this is semantically virtually equivlent to the BSD licence for case specified (and, in fact, the same as BSD for pretty much any case of use and distribution).
Short answer: Stick a mention of it in the NOTICE text file, tell people what liscene the Work (in this case the APR) was under, and go ahead.
Interestingly, this licence would, as I read it, allow you to make a derived work, and redistribute that in binary form only. It doesn't grant you the right to change liscence, or apply restrictions, so a Derived Work wouldn't work as a commerical product (as the first purachaser can redisribute it).
But, as it specifically excludes linking to the interfeces specified, then for a Work which is a library [0], the only clause that imparts any restriction is 4(d) [1]
In fact, I can see no part of the liscence that would prevent one from taking a program under this liscence, creating a Derived Work that is that program implemented as a library, with well defined interfaces, and then linking to said library from a commercial/closed program. There is no requirement to publish Derived Works [2]. The only mildly non-obvious outcome is that if the library was extracted from the final disribution, the licence allows for its free distribution and use, which is not a restriction.
Of course, if this is for commerical software, you'll have the money to speak to a lawyer licence to practice in your juristriction first.
[0] And where that library is used unmodified
[1] And the expiration of patent licences in event of you issuing a patent suit.
[2] Only that you make any changes clear if you do publish.
SPF is part of a domain record, and specifies who can send email from that domain.
It does _not_ specify who can sent email from an netblock.
Thus, if you wish to send email not through your ISP's SMTP server, you require to have your own domain. This is not considered a major problem, given that the majority of people who wish to bypass thier ISP's SMTP servers do so _because_ they have their own domain for email.
The only people who would lose under SPF would be those people who wish to use a domain name, but not the SMTP servers for that domain. This is prevented, because that's the modus operendi of spam.
So, if you get your own domain, and add the IP of your home network to the DNS record, and that would all work.
Downside: You either need a static IP (or 'nearly static' - a dynamic IP that you know will be stable over a long period), or to set the SPF records over the large netblock that you will be on. The former is slightly more expensive (typically), the latter is less secure.
I genuinly can't see an issue with that as a scheme, and I certinally can't see a better way.
Worst case scenario: You need to get a domain name (around what, 10 bucks a year), and set the allowed range to your ISP's dialup pool.
Heh, I did think that a coin was a bit too large for photonic momentum to have an observable effect. Looks like that's already proven. Ah, well, ignore the specifics, and just look at the principle
The think about physics rather than economics is that physics is based of repeated and repeatable observations. Economics, at the mico level at least, is based of human preferences - where you can end up with (where x > y should be read as 'x is preffered over y') a > b AND b > c AND c > a.
There is no good mathematical way of doing much with that set of relationships. within physics, however, the field of statistical mechanics is all about relating microstates to macroscopic observables. There is no generally applicable equivelent in economics.
Quantum mechanics and newtonian physics are not mutually exclusive. As you increase the sizes of things involved, the equations that govern QM reduce to the Newtonian equivelents. Newtonian physics (that which is obervable to most people) is a simpler model.
Likewise, the equations for relativistic motion reduce to the Newtonian equations as you slow things down. There is some disconnect between QM and relativity, but that's getting esoteric - for the most part they coincide.
Prehaps the most direct example of the connection between microstates and macroscopic observables is within something like the Onsager solution [0] for a 2 dimensional square lattice. This has direct applications for a single layer of a magnetic material, and has been observed with a single layer of NiO. Onsager's particularly impressive (and turgid) analysis calculates the partition function of the system - from which all of the macroscopic observables related to the microstates can be derived.
Anyway, the partition function is the key that link the microscopic states and macroscopic states. If you want to look into the link between micro and macro, that is where to start (it's part of statistical mechanics).
Not heard micro/macro economists debate directly, but I've heard it mentioned before.
[0] Lars Onsager, Phys. Rev. 65, 117 (1944). I'd advise against reading it - I've yet to meet more than a handful of people who understand it all. Still, it's an impressive piece of work.
The problem is, however, that the random nature of quantised states exerts some influcence on macroscopic states. It's not very big. In fact, it's posivtly tiny (other wise the quantum nature of things would have explored sooner). Let me give an example.
Light has momentum. The solar sail is the most direct application of this.
Consider a coin toss. In the average place where it takes place, there is uneven illumination. That is, as the coin is spinning, there will be time where the illumination on one side is different to the other. So far this is still accontable for.
However, some of the incoming light will be absorbed by the material of the 'coin', which will enter an excited state, and then later re-emit that light. There is a hugh amount of photochemistry which relies on this sort of behaviour.
So, as the coin is spining in the air, the momentum from reflected light is calculable. Let's ignore the effect of absorbing the light, and focus on the re-emmision which will apply some momentum. In what direction is the light re-emited?
Well, that's a tough question. Most importantly, as the coin is spinning in the air, it depends on the time between absorbtion and re-emmision. That's a quantum phenonema, and is randomly distributed in a Gaussian disribution about some mean.
So, to calculated the effect of the coin toss exactly, you need to account for all those quantum effects. Which is impossible, because they are random.
I accept my example is a little contrived, in that the effect of the differential momentum transfer by photonic processes is negligable for any real coin, compared to other factors. It is, however, not zero, and is a solid example of how the randomness of quantum events effects macroscopic observables.
Given enough time, the fuzzyness of the quantum states gradually takes over. For most things that's a long time - it is, however, non zero.
Uh, sort of. Heisenbergs uncertinty principle can be read as "We can never know the details" of quantum states. If it is true, then it does not matter whether or not a quantum state could be determanitsic if we can measure the things we need to determine it.
Now, there is an awful lot of discoveries and technology that have been predicated on Heisenbergs principle being true (or, at least, true enough, for some value of enough) [0]. Thus, the burden of proof is heavily on the side of anyone claiming that it's not valid (just as it is for anyone claiming Einsteins relativity is wrong, and as it was for Einstien when he showed Newton was wrong [1]).
So, I refute your claim on 'It's too early', by Schottky diodes, Mossbauer spectroscopy and quantum computing, which all rely on quantum states having true randomness [2].
Furthermore, by the way, there was a bunch of work on something called the Bell inequality, which, although painfully esoteric in testing, has disproved the existance of hidden variables. That is, it is _not_ the case that quantum states are deterministic, by data we can't measure. There are no such hidden bits of data.
Moreover, pretty much every macroscopic physical observable is a statistical average of very many microscopic states or events. These microstates are randomly distributed within some known distribution (e.g. disribution individual molectular kinetic energies for a given temperature of a set of particles). The various physical laws that we depend on (in the case of temperature, the predicability of the increase in the rate of some chemical reaction with increasing temperature, for example) have the concept of this random disribution so inherent in them, that I must argue that if 'random' is a a human thought construct, it is fortunate that the laws of nature also think that way (i.e. random is a physical concept)
Such is the opinion of this quantum physicist, at any rate.
[0] E.g Mossbauer spectroscopy
[1] Strictly, Newton was farsighted enough to state his basic assumptions expcitly. Einstein just showed that one of them ("Time is the same for all men") was incorrect, and the consequences of it.
[2] Or, at very least, something that is indistinguisable from it.
took into account the links _to_ a page as a measure of it's relevence.
The idea being that the more linked to a page is, the more value it has - thereby using people as a way of meauring the worth of a page. By examing the words people link with, as well as allowing Googlebombing, it sidesteps meta-tag pollution etc.
Been de-emphasised, compared to other sub-algorithms, but it's not just the appearence that set google apart in the early days. Before they had ad's.
"Early days" *shiver* I can remeber when AltaVista was the pinnicle of web searching, and using Archie and Veronica.
Sort of, but not really.
The way you want to define the compexity of the solution makes it the same as the compexity of the problem. That's a perfectly valid defintion, but that's not the one the author uses (clearly).
What I think the author means is that the difficulty to understand the code that is the solution increases 100% for every 25% increase in the difficutly to understand the details of the problem.
That's clumsy language, but I think it gets the gisty of the point over.
By example, if you have a hunk of code that does something subject to 4 independant constraints, applying a 5th indepentant constraint will increase the volume and turgidity of the code by around 100%.
Not sure I agree with the precise numbers, but the principle is roughly there.
If printing it out is not an option, displaying it in a different font, in a different size, ideally with differnt line breaks (hard for code, possible for other things) is almost as good.
The aim of printing or reformating is to change the text, and force you to actually read the letters that are on the page. This is done by destroying the patterns in the positioning of the text that the writer is used to, thereby hindering recall.
This is one of the reasons LaTeX is useful (for me, at any rate), because it does all of the above, without actually printing it (written in 10 pt monospaced Courier, read is 12pt Times New Roman, 1.5 spaced, paginated). Most literate programming schemes also have this as a side effect, notably Web derived scheme which output LaTeX. I've always wondered how much that contributes to the sucess of those methods.
Not meaning to be (overly) pedantic, but that's not wear. Wear is caused by bits rubbing over each other.
This is not just a semantic difference. The failure modes of silicon chips are mostly diffusion limited - that it, the metal conductors expand, the pn junctions become more diffuse, vacencies develop in the silicon, and so on. The failure mode of a part which wears is generally that the wear causes a mechanical weakness in a part till it breaks, bends, or is otherwise no longer functional.
This difference is reflected in the time to failure of different devices. Electronics show a bathtub curve - essentially, manufacturing defects show up in young failures, then after a period (around 8 - 10 months), there is no intrinsitic source of failure other than the (slow) diffusion limited modes, so there number of devices failing drop very low, until that mode dominates, at sometime around 8-10 years after manufacture.
Mechanical parts also show young failures, but, due to wearing, they do not last as long, and the rate of failures does not drop as low. The exact duration is determined by the type of use of the part. For example, this motor here *clunk* has bushes and brushes that have a design life of 1 months constant use, which translates to about 4 years with typical uses patterns. On the other hand, the motor in a washing machine is rated for something like 2 years constant use. The washing machine motor has bigger bushes and brushes, which are designed to last longer.
I could go on, but a) it gets boring rapidly, and b) I'd have to did out some notes on it, and cba.
In 10 years with computers, which gives experince with devices up to 20 years old, I have seen 1 case of failure in a componant over 3 months old that was not caused (directly or indirectly [0]) by mechanical wear.
Having said all that, Flash memory is not as reliable as most electronics, as it has a particular structure that causes insulator breakdown after around 1000 writes. But that's not _really_ wear, although I'm told it has a similar failure profile.
Not moving parts does not translate to no deterioration, but it _does_ mean no wear.
[0] Couple of times, power supply fans died, power supply overheats, fails, and frys electronics.
Nah, you just use a diamond saw. Same as for the silicon wafers. It's conceptually the same thing as a very thin diamond tipped grinding wheel, and it grinds a cut through the material. You can also use a diamond encrusted wire as a saw, like, erm, this one *holds one up*, but they are much slower, and only really good as hand saws, or for chopping thin sheets [0].
It's going to be a little slower, as SiC is about twice as hard as silicon, but that's not going to slow it down that much. Diamond saws are also used to chop up boules of sapphire and ruby, which are of similar hardness to SiC (a little softer), and also diamond (harder), so it's no big techical problem.
Or, a laser. A nice big excimer laser would slice it neater than a diamond saw. With the improved surface texture after cutting, the decrease is polishing coupled with the increase in hardness might make it worth while. Probably not, though.
[0] I use my saw for cutting rocks for lapidary purposes, principly quatrz of various sorts.