What was once a great company making high quality computer hardware and software for creative professionals which just worked, most of the time, they have got off their face on dollars, have a mulltimillion-a-day consumer 'greenback crack' habit, and are basically scalping the consumer market for all they can get to keep feeding their dollar-addiction. It is horrifying to see an addictive substance like consumer-dollars reduce them to this.
So the mainstream cosmologists' viewpoint is based on the assumption of isotropy, and this result shows support for that. But what assumptions does this result rely upon, and what do you do with the 'intellectual ponzi scheme' problem of needing to rely on progressively more and more, deeper and deeper assumptions to back up your reasoning?
(I did my doctoral studies in the foundations of mathematics, and take a perverse interest in such intellectually subterranean stuff.)
A lot of the issues come down to a general type of problem, one I term 'NSA/GCQH problems', namely "is this meaningful data?" type questions.
For example, if trying to decrypt a file, if one alphanumeric password of length 16 characters ends up with something like passable HTML or English text, chances are you have the right password. Thus there are easy(ish) ways for an attacker/listener to verify whether or not they have the the correct password. I imagine future anonymity systems will need to look at means of effective communication which do not allow such easy verification of a correct attack. That requirement, rather than defining _how_ information is anonymously transmitted, will define _what_ can sensibly be anonymously transmitted, and what practical use can be made of what can sensibly be anonymously transmitted.
Much of this comes down to making things computationally 'vague' in some well-defined way, so that 'attack problems' (like e.g. find the password for this AES encrypted file) are, in general, poorly defined and open-ended (so that the search space is effectively infinite). This means harnessing computational complexity in different ways to current mainstream cryptographic methods (though probably using them in conjunction with mainstream crypto).
This begins with taking real-world communication scenarios, asking what basic problem is being solved, and what communication is necessary for solving this problem, and considering the whole space of possibilities.
Crypto like AES has the nice property of being easily implemented on small custom hardware. For important things, it is sensible to at least contemplate methods which would take large amounts of ram and processor power (e.g. if it took 5s and 1GB RAM on my i5 laptop to encrypt and decrypt a 4k textual message into, say, a 256k binary blob, for the kinds of things TOR was originally about, which was not selling drugs and spreading kiddie porn, this would be acceptable). Doing it in such a way as to make the 'false positive' rate for an attacker very high (so restricting the format of communication to a very computer-friendly and formulaic language format, such that many plausible but incorrect 'decryptions' are possible, and non-interactive verification is hard). Stuff like that.
A lot of this really requires thinking outside-the-box about what we need to communicate, rather than sticking with everyday communication conventions and throwing all our effort at _how_ to transmit that everyday communication anonymously. I did envisage, years ago, something I termed the 'schizophone', which would generally throw around pseudo-bullshit in the forms of spiritual poetry or whatever, reminiscent of a psychotic mental patient, but for which there were well-defined means to extract meaning. But modelling the communication language on the kind of crap people send round twitter these days, you get a kind of steganography-on-acid where attackers have a hard enough time figuring out what is even meaningful. (Then there is the fun of defining 'meaningful' in terms of mathematically hard language recognition problems of the NP-complete kind, where the 'certificate' functions as a filter, a little like the 'chaffing and winnowing' paper talked about a while back: if I have an NP-complete problem for a language L, where L is contained in some larger computationally efficient language L2 (by being much less stringent about what is in L2 than in L) and both an element of this language s, a certificate c, and many other elements of L2 all encoded in some blob, it is feasible to extract all possible candidates for elements of L2 from that blob, but without access to c, verifying which are elements of L is much harder, assuming P != NP, or that in the event that P = NP, there is still a significant gulf between the best 'solver' and a decent 'checker'.)
There needs to be sufficient regulation to prevent free-marketeering from trying to milk the free money supply.
More generally, it is necessary that the universal basic income is sufficient not to force those on it into defacto poverty.
The two are related in the sense that, with an unregulated free market, if you pump money in but no more material resources, more money is chasing those same resources, pushing prices up.
In general, though, removing the anxiety about putting a roof over your head and food on the table should be considered a necessity if you want to get the best out of your workforce in a modern technologically driven world: the more you brain has to worry about the basics, the less brain there is left to think about productive things.
By making the labelling more confusing, fewer buyers can make informed buying decisions, and are thus more subject to the ShinyThingEffect (whereby there is little intelligent thought capable of counting the feelings of 'Oooh! ShinyThing!') and then manufacturers get a level playing field of ShinyThing-ness.
In the past, there has been a shift from outboard hardware and coprocessors to CPUs, then from single core to multi-core. I invisage offloading the main CPUs as much as possible. Having lightweight RISC cores (e.g. what you find in a cheap smartphone) doing things like menial OS duties, possibly even much of what a kernel traditionally does, I/O and sound, moving the GUI and much rendering (e.g. what OSX's Quartz 'display pdf' layer did, and stuff like window management) to a RISC core on the GPU, and so on. If you take a $200 CPU chip, and offload much of the menial OS stuff that could be done sufficiently quickly with a $1 RISC core, how much CPU power will that free up, especially since there is less task switching to do? Then in CPU design, taking the task switching and hyperthreading thing up again, having a means in hardware to save/load state to cache, and then to memory in the background. Much of these things were done in old school mainframes and supercomputers, so much knowhow is still around (e.g. having a front-end machine to the main processors: the suggestion above is to put the GUI in a frontend machine running on the GPU card, so that the main CPUs only have to worry about window content). Trying to find parallelism in CPU tasks is one thing, moving them back off the CPU is another.
I love having.pdf files lying around that I can print out. For ebooks, when I can be bothered, I have a script on my Linux box (and rotate the screen 90 degrees for the form factor) to xdotool key Right, sleep 1, screenshot, sleep 1, repeat, then magick it together into a pdf. Not brilliant, but with enough resolution you can get something worth printing out and reading (approx. 180 dpi).
Agree. It is a basic fact of computer science that you can write sluggish and unusable software for any platform. Whether you can write efficient software is another thing. Whether it is easy to do so is yet another. Most app vendors aim to do just enough to get paid.
Kind of like the market for Windows PCs. Again they all 'differentiate' their products with piles of crapware. This is 'business school' thinking, and the evidence of the crapware mess on both Windows and Android ought to be evidence enough that, in the case of computer equipment, this 'market differentiation' mindset just plain does not fucking work. What we need is stuff that is as uncluttered as possible and just works. Apple used to do that very well with macs mid last decade, then got carried away with the 'shiny thing' consumer market. PC newbies, as with beginners in anything, know little about what they're getting in for. Those newbies are thus very vulnerable to 'shiny thing' marketing tactics, and are then trapped in 'shinything land' as a result, and those companies who produce solid products are confined to the expensive 'discerning pro' end of the market. I like to compare HP consumer goods to their pro stuff. Their pro workstations are great, their consumer PCs are rubbish; their pro printers are pretty good, their consumer printers are rubbish (mine I simply gave away to make room for a Kyocera, an old HP consumer laptop I ended up with had the hard drive removed and reused and the rest left in a box as soldering practice). The long term result of 'shiny thing' mass marketing is a mass of by-design-obsolete stuff that is not worth the effort to reuse. As a society, can we afford to be that wasteful?
Strong crypto is widely available, and given a.js library can be done in a browser. There was a golden age of information spying, when info was carried by wires or waves, without strong crypto. Before, you had to capture the courier, now you have to attack either side of the maths. Deal with it. Rolling back strong crypto will just give a false sense of security.
(and by deterministic I mean deterministically gives the correct answer, in the sense that 'while true { print ("sexist"); } is not an effective procedure which always gives the correct answer in finite time and halts, not 'can be implemented on a deterministic machine'.)
Your 'algorithm' has two flaws: first, it loops indefinitely for all inputs, rather than halting for all inputs as an algorithm must, and then sometimes it yields incorrect answers (for example I don't believe Happy Feet does a poor job of portraying women, mainly due to it not portraying women at all).
It may seem like a fun toy, but given that some researchers are seriously questioning whether 'major depression' is a single well-defined illness, and whether human diagnostic means are reliable, does anybody seriously think this will work reliably in a clinical setting the way an ECG does.
What is worse, is that those who work in health research often do not grasp what happens to structured logical reasoning when even one 'falsehood' creeps in. All papers whose conclusions depend upon papers with these errors must be considered suspect until checked, for example. Otherwise you are simply gambling that no errors are present. This is playing Russian Roulette with patients' lives when done in the context of the health system.
Have you ever wondered what it is like to be a foix gras goose, to become the epitome of the best pate? Well now you can, in the form of force fed videos paid for by our sponsors. Enjoy!
It is software written assuming the APIs a linux machine exposes. Microsoft wrote a clean room implementation that did what colinux did on 32bit windows, and cooperated with Ubuntu to make it work better. That Microsoft have seen the need for a more positive attitude towards Free Software, Open Source, and Linux is a good thing. That Ubuntu Bash on Windows would not have happened without the success of Linux based operating systems is, I think, certain. Don't knock the penguin, he doesn't like it.
A process should not, by default, have access to any syscalls except self-termination. Likewise hardware virtualised operating systems. This should not just be within the OS itself, but within languages like Python and Javascript. Restricting what functions can be called to a minimum, and wrapping important ones in 'computational condoms' is something that, now we have LLVM to compile things on the fly, be considered mandatory. AOT compilation like on modern Android, combined with a well thought out API where what part has access to what is, to me, where to go. Your program comes in in LLVM bitcode, with special permission required to run binaries (esp. outside a VM), and based on information as to what syscalls are needed, a custom syscall interface is compiled on the fly, folliwing ideas such as in synthesis os, though for security rather than speed. Importantly, you want a non Turing complete layer in there somewhere.
Just because something is possible 'in principle' with X11 is not enough. Doing security the right way needs to be easy and obvious, as does doing away with security, as does knowing which of these is the case. Possible but not easy means most won't do it; easy and default means most do, which gives a kind of 'herd immunity' where speculative attacks are likely to fail rather than succeed. This 'herd immunity' makes it more expensive for attackers to target, since the population of viable targets is small, diverse, and sparsely distributed. Part of security comes from making it harder for an attacker that it's worth. Another comes from structuring things so that one breach can't lead to too much damage. Making it too hard for the average user to do these makes good security the preserve of a small elite, which is not a good thing unless you are in the elite (and even then, to me, is not a good thing).
What was once a great company making high quality computer hardware and software for creative professionals which just worked, most of the time, they have got off their face on dollars, have a mulltimillion-a-day consumer 'greenback crack' habit, and are basically scalping the consumer market for all they can get to keep feeding their dollar-addiction. It is horrifying to see an addictive substance like consumer-dollars reduce them to this.
Proof.
echo Courage | tr 'aeCougr' 'ntInsia' | sed -e "s/t/ty/"
So the mainstream cosmologists' viewpoint is based on the assumption of isotropy, and this result shows support for that. But what assumptions does this result rely upon, and what do you do with the 'intellectual ponzi scheme' problem of needing to rely on progressively more and more, deeper and deeper assumptions to back up your reasoning?
(I did my doctoral studies in the foundations of mathematics, and take a perverse interest in such intellectually subterranean stuff.)
A lot of the issues come down to a general type of problem, one I term 'NSA/GCQH problems', namely "is this meaningful data?" type questions.
For example, if trying to decrypt a file, if one alphanumeric password of length 16 characters ends up with something like passable HTML or English text, chances are you have the right password. Thus there are easy(ish) ways for an attacker/listener to verify whether or not they have the the correct password. I imagine future anonymity systems will need to look at means of effective communication which do not allow such easy verification of a correct attack. That requirement, rather than defining _how_ information is anonymously transmitted, will define _what_ can sensibly be anonymously transmitted, and what practical use can be made of what can sensibly be anonymously transmitted.
Much of this comes down to making things computationally 'vague' in some well-defined way, so that 'attack problems' (like e.g. find the password for this AES encrypted file) are, in general, poorly defined and open-ended (so that the search space is effectively infinite). This means harnessing computational complexity in different ways to current mainstream cryptographic methods (though probably using them in conjunction with mainstream crypto).
This begins with taking real-world communication scenarios, asking what basic problem is being solved, and what communication is necessary for solving this problem, and considering the whole space of possibilities.
Crypto like AES has the nice property of being easily implemented on small custom hardware. For important things, it is sensible to at least contemplate methods which would take large amounts of ram and processor power (e.g. if it took 5s and 1GB RAM on my i5 laptop to encrypt and decrypt a 4k textual message into, say, a 256k binary blob, for the kinds of things TOR was originally about, which was not selling drugs and spreading kiddie porn, this would be acceptable). Doing it in such a way as to make the 'false positive' rate for an attacker very high (so restricting the format of communication to a very computer-friendly and formulaic language format, such that many plausible but incorrect 'decryptions' are possible, and non-interactive verification is hard). Stuff like that.
A lot of this really requires thinking outside-the-box about what we need to communicate, rather than sticking with everyday communication conventions and throwing all our effort at _how_ to transmit that everyday communication anonymously. I did envisage, years ago, something I termed the 'schizophone', which would generally throw around pseudo-bullshit in the forms of spiritual poetry or whatever, reminiscent of a psychotic mental patient, but for which there were well-defined means to extract meaning. But modelling the communication language on the kind of crap people send round twitter these days, you get a kind of steganography-on-acid where attackers have a hard enough time figuring out what is even meaningful. (Then there is the fun of defining 'meaningful' in terms of mathematically hard language recognition problems of the NP-complete kind, where the 'certificate' functions as a filter, a little like the 'chaffing and winnowing' paper talked about a while back: if I have an NP-complete problem for a language L, where L is contained in some larger computationally efficient language L2 (by being much less stringent about what is in L2 than in L) and both an element of this language s, a certificate c, and many other elements of L2 all encoded in some blob, it is feasible to extract all possible candidates for elements of L2 from that blob, but without access to c, verifying which are elements of L is much harder, assuming P != NP, or that in the event that P = NP, there is still a significant gulf between the best 'solver' and a decent 'checker'.)
There needs to be sufficient regulation to prevent free-marketeering from trying to milk the free money supply.
More generally, it is necessary that the universal basic income is sufficient not to force those on it into defacto poverty.
The two are related in the sense that, with an unregulated free market, if you pump money in but no more material resources, more money is chasing those same resources, pushing prices up.
In general, though, removing the anxiety about putting a roof over your head and food on the table should be considered a necessity if you want to get the best out of your workforce in a modern technologically driven world: the more you brain has to worry about the basics, the less brain there is left to think about productive things.
By making the labelling more confusing, fewer buyers can make informed buying decisions, and are thus more subject to the ShinyThingEffect (whereby there is little intelligent thought capable of counting the feelings of 'Oooh! ShinyThing!') and then manufacturers get a level playing field of ShinyThing-ness.
In the past, there has been a shift from outboard hardware and coprocessors to CPUs, then from single core to multi-core. I invisage offloading the main CPUs as much as possible. Having lightweight RISC cores (e.g. what you find in a cheap smartphone) doing things like menial OS duties, possibly even much of what a kernel traditionally does, I/O and sound, moving the GUI and much rendering (e.g. what OSX's Quartz 'display pdf' layer did, and stuff like window management) to a RISC core on the GPU, and so on. If you take a $200 CPU chip, and offload much of the menial OS stuff that could be done sufficiently quickly with a $1 RISC core, how much CPU power will that free up, especially since there is less task switching to do? Then in CPU design, taking the task switching and hyperthreading thing up again, having a means in hardware to save/load state to cache, and then to memory in the background. Much of these things were done in old school mainframes and supercomputers, so much knowhow is still around (e.g. having a front-end machine to the main processors: the suggestion above is to put the GUI in a frontend machine running on the GPU card, so that the main CPUs only have to worry about window content). Trying to find parallelism in CPU tasks is one thing, moving them back off the CPU is another.
I love having .pdf files lying around that I can print out. For ebooks, when I can be bothered, I have a script on my Linux box (and rotate the screen 90 degrees for the form factor) to xdotool key Right, sleep 1, screenshot, sleep 1, repeat, then magick it together into a pdf. Not brilliant, but with enough resolution you can get something worth printing out and reading (approx. 180 dpi).
Agree. It is a basic fact of computer science that you can write sluggish and unusable software for any platform. Whether you can write efficient software is another thing. Whether it is easy to do so is yet another. Most app vendors aim to do just enough to get paid.
Kind of like the market for Windows PCs. Again they all 'differentiate' their products with piles of crapware. This is 'business school' thinking, and the evidence of the crapware mess on both Windows and Android ought to be evidence enough that, in the case of computer equipment, this 'market differentiation' mindset just plain does not fucking work. What we need is stuff that is as uncluttered as possible and just works. Apple used to do that very well with macs mid last decade, then got carried away with the 'shiny thing' consumer market. PC newbies, as with beginners in anything, know little about what they're getting in for. Those newbies are thus very vulnerable to 'shiny thing' marketing tactics, and are then trapped in 'shinything land' as a result, and those companies who produce solid products are confined to the expensive 'discerning pro' end of the market. I like to compare HP consumer goods to their pro stuff. Their pro workstations are great, their consumer PCs are rubbish; their pro printers are pretty good, their consumer printers are rubbish (mine I simply gave away to make room for a Kyocera, an old HP consumer laptop I ended up with had the hard drive removed and reused and the rest left in a box as soldering practice). The long term result of 'shiny thing' mass marketing is a mass of by-design-obsolete stuff that is not worth the effort to reuse. As a society, can we afford to be that wasteful?
Strong crypto is widely available, and given a .js library can be done in a browser. There was a golden age of information spying, when info was carried by wires or waves, without strong crypto. Before, you had to capture the courier, now you have to attack either side of the maths. Deal with it. Rolling back strong crypto will just give a false sense of security.
If you asked Richie back in the early 70s whether he thought it would be a major language in 40 years time, I wonder what he'd say?
(and by deterministic I mean deterministically gives the correct answer, in the sense that 'while true { print ("sexist"); } is not an effective procedure which always gives the correct answer in finite time and halts, not 'can be implemented on a deterministic machine'.)
Your 'algorithm' has two flaws: first, it loops indefinitely for all inputs, rather than halting for all inputs as an algorithm must, and then sometimes it yields incorrect answers (for example I don't believe Happy Feet does a poor job of portraying women, mainly due to it not portraying women at all).
This is a probabalistic algorithm, not a deterministic one. It does not always give the correct answer, but does so with high probability.
More handsome than average, and more extreme in one trait or another.
def IsThisMovieSexist(movie):
return True
Won't be accurate for all movies, but gets the answer right with a high degree of probability.
It may seem like a fun toy, but given that some researchers are seriously questioning whether 'major depression' is a single well-defined illness, and whether human diagnostic means are reliable, does anybody seriously think this will work reliably in a clinical setting the way an ECG does.
Or researchers should simply be banned from using Excel. There is enough money in the area to customize Libreoffice to avoid these kinds of errors.
Because, being medicine people, they believe the are God, and hence exempt from being subject to making errors with Excel.
What is worse, is that those who work in health research often do not grasp what happens to structured logical reasoning when even one 'falsehood' creeps in. All papers whose conclusions depend upon papers with these errors must be considered suspect until checked, for example. Otherwise you are simply gambling that no errors are present. This is playing Russian Roulette with patients' lives when done in the context of the health system.
Have you ever wondered what it is like to be a foix gras goose, to become the epitome of the best pate? Well now you can, in the form of force fed videos paid for by our sponsors. Enjoy!
It is software written assuming the APIs a linux machine exposes. Microsoft wrote a clean room implementation that did what colinux did on 32bit windows, and cooperated with Ubuntu to make it work better. That Microsoft have seen the need for a more positive attitude towards Free Software, Open Source, and Linux is a good thing. That Ubuntu Bash on Windows would not have happened without the success of Linux based operating systems is, I think, certain. Don't knock the penguin, he doesn't like it.
If a modern kernel were to panic once 65+ processes were running, I wonder how far it would get through the boot process.
A process should not, by default, have access to any syscalls except self-termination. Likewise hardware virtualised operating systems. This should not just be within the OS itself, but within languages like Python and Javascript. Restricting what functions can be called to a minimum, and wrapping important ones in 'computational condoms' is something that, now we have LLVM to compile things on the fly, be considered mandatory. AOT compilation like on modern Android, combined with a well thought out API where what part has access to what is, to me, where to go. Your program comes in in LLVM bitcode, with special permission required to run binaries (esp. outside a VM), and based on information as to what syscalls are needed, a custom syscall interface is compiled on the fly, folliwing ideas such as in synthesis os, though for security rather than speed. Importantly, you want a non Turing complete layer in there somewhere.
Just because something is possible 'in principle' with X11 is not enough. Doing security the right way needs to be easy and obvious, as does doing away with security, as does knowing which of these is the case. Possible but not easy means most won't do it; easy and default means most do, which gives a kind of 'herd immunity' where speculative attacks are likely to fail rather than succeed. This 'herd immunity' makes it more expensive for attackers to target, since the population of viable targets is small, diverse, and sparsely distributed. Part of security comes from making it harder for an attacker that it's worth. Another comes from structuring things so that one breach can't lead to too much damage. Making it too hard for the average user to do these makes good security the preserve of a small elite, which is not a good thing unless you are in the elite (and even then, to me, is not a good thing).