Being human, some computer scientists and economists probably do make unwarranted assumptions. But the fact that humans can alter the rules of the game might not be relevant here: if there is an underlying meta-game whose rules constrain how the rules can be altered, then that is the model who's Nash equilibrium is sought. It seems, to me, unlikely that this will be an infinite regress: humans are ultimately restricted by the laws of physics. Even though any model of that meta-game would probably to too complex to be represented as any arrangement of all the subatomic particles in a human brain, it would be interesting if it were possible to characterize any of its properties mathematically.
If OpenOffice is "open", then why does a preview need to be a "sneak" preview? That term should be used for a review of something that has been developed behind closed doors, that we are only now being given a brief glimpse of...
I find many people don't know that "cd -" goes to a previous directory: great for toggling between two directories, and lighter weight than pushd/popd.
Theories do put an upper limit on the probable mass of the Higgs. According to Wikipedia, 95% confidence interval is 114 to 140 GeV. If this experiment fails to detect it then it is very likely that it doesn't exist (and therefore our theories need significant overhaul) or that it is very different from what the models predict (in which case our theories need significant overhaul).
Skeptics tell us that the climate models are riddled with errors, and cannot be trusted. It it turns out that the artic does indeed become ice free this summer then this would prove them right.
Just last year, the models were predicting summer 2013. That would be about 60 months to be ice free. If it happens this summer, then that would be less than 10 months. The time predicted by the model would be 500% greater than reality (if it happens).
How can you base environment policies on models that are shown to have such large errors? We obviously need to postpone any action until the models are much more accurate! [/sarcasm]
That assumes that the set of universes is countable. For things like non-negative integers it is indeed guaranteed that repeated subtraction will eventually reach zero. For uncountables (e.g. real numbers) this is not true. If the set of encapsulated universes is some strange quantum string super-symmetric imaginary set then perhaps it's not countable.
He didn't actually say there was no benefit. There are two scenarios:
fix the damage caused by each infection
pay for AV, plus pay to fix the damage caused by each infection. (hopefully fewer infections)
The argument is that the first option is cheaper because the number of infections prevented doesn't cover the cost of the AV software.
A corporate environment isn't the same as a home user. Given that there are going to be some infections, they need the procedures and infrastructure in place to clean up damage either way. The incremental cost of additional infection is therefore quite low.
Of course, even with a paper trail there could be a warehouse fire, or flood, or whatever to destroy the records (even in a "secure" box). What's needed to to store the votes in a safe way that cannot be easily erased: for example, write a ROM to store the original records during the election; and then when the polls close create multiple backup copies (e.g. burn a set of write-once CDs) that you give to each election observer. (The original ROM can be made of paper if you want; but I'd still want multiple off-site backups to be made before the elections workers go home for the day)
It is of course true that there is uncertainty in the models -- this fact even makes it into most non-scientific reporting. The problem that I see is that the people who focus on these uncertainties as a basis for inaction typically assume that the errors lead to systematically pessimistic models. I do not know of any evidence for this skewed error distribution: it is equally likely that the errors lead to models that are optimistic. Activists may wish to promote one particular interpretation but purely scientific publications tend to be scrupulous is their desire not to be seen as alarmist.
I'd say the problem is that premature optimization leads people to overly complex, and therefore hard, solutions. If you're willing to live with a pure message passing system (i.e. something equivalent to Unix processes, not threads) then most of the problems associated with parallel programming a vastsly diminished (spaghetti coding may still lead to deadlocks and livelocks; but a little disciple will avoid that, most of the time -- it's not "hard").
If this pure message passing system can take advantage of an extra core or two, then maybe you can live with its inefficiency. To assume otherwise is a premature optimization. Once you identify that optimization is actually necessary then you have two options: optimize it into a single threaded program (yes, sequentialization is an optimization) or else start sharing memory and adding locks, etc.
Most problems are moderately parallelization; so you should train yourself to code them in that way. Then you don't need to rearchitect to take advantage of the extra hardware resources.
IIRC, the senate vote pertained to instructions to the US negotiators: it instructed them, amongst other things, not to come back with an agreement that didn't limit the emissions China and India. Sure, the negotiators came back with a treaty the didn't abide by all the instructions (treaties never do: the public instructions are a negotiating position): but no vote was ever taken on the result of the negotiations.
The internet was designed as a way to interconnect networks -- and networks are, of course, an interconnection of computers.
The obvious result of the creation of multiple internets is that someone will develop a protocol to interconnect them. It'd be clumsy to name this thing the "inter-inter-network", so perhaps it will be the "Interweb".
This interweb protocol will feature a unified naming system, access to porn, and everything else we've come to love about the internet. The only difference is that there'll be an extra layer of distributed control.
ID proponents say that they see evidence of an intelligent designer, but decline to (publically) say who/what this designer is. Science can do better: not only could it agree that there is evidence of intelligence, but it can explain that intelligence.
Computer Scientists studying artificial intelligence have used evolutionary programming in many contexts -- even to design hardware. If evolution can be a basis for artificial intelligence then it can also be an explaination for natural intelligence.
So scientists could turn ID on its head. By embracing it, then can teach that evolution is not a random process. Indeed it is the filtering, not the variation, that adds information to the system. By explainng a non-supernatural origin for intelligence, we would undercut attempts to disprove evolution by identifying ever more obscure examples that suggest that intelligence was needed in their design.
That techies may regard a lack of literacy is a badge of honor is a mirror of the pervasive attitude amongst the literate that holds a lack of technical knowledge as a badge of honor. How many (non-technical) people do you know who will proudly proclaim that they don't understand algebra/trig/calculus?
The filesystem abstraction is good: You have a lump of data, and any process can stream it in by asking for it by name.
But we are stuck with the idea that only kernel-kackers know where the data comes from. Even things link Linux' VFS require kernel modules to add new filesystems. So user-mode users can't add new types of files.
Why is this important? There are several types of problems that could be easily solved using simple user-mode mount points:
1) persentation of information: Lets say we have a set of objects (or database rows -- the data source shouldn;t matter), and you want to present it as a file. The unix-way is to run a query to generate a file. The you can look at the data in a n editor; and if you modify it, you can run an update script to put the data back. So we have 2 operations to "open" the data, and 2 to update it. Why?
A kluge solution would be to attach trigers to the open/close file operations, but that doesn't really work. I want to be able to type:
ls people.age vi people.age/20-24 {edit and save}
and have it all work dynamically (i.e. I'd be able to use standard unix tools to browse data, and modify it).
Non of this is rocket science. People talk about database file systems, but they're looking at the wrong part of the problem. Anyone with root access can easily (well moderately so) write a kernel module that does this today. But why isn't it user-mode?
A second usermode filesystem app should be version control. It should be possible to write a filesystem client similar to Clearcase without being a kernel hacker.
I remember I once asked on Perlmonks about a tool called PerlFS, that lets you write filesystems in usermode (though you do need to install a kernel-module to set it up). I was laughed off the site -- there is a mindset that says "filesystems are kernel apps". "It'd be too slow" people say, forgetting that you can mount (and use) NFS over a 14K modem. "It'd be insecure" is another favorite.
People build IDE tools for developing software, but they forget that Unix *is* and IDE. We just need a filesystem that lets us join together the fundamental tools (ls, more, grep,...) in more ways than just pipes.
I remember watching a lecture on the reseach channel, where a comparison was made of growth rates of different technologies: cpu, storage and network bandwidth. The bottom line was that cpu performance growth follows Moores Law (i.e. the perf increase is dominated by manufacturing issues) while network performance is increasing at 10X the cpu rate (disk is somewhere between). The talk discussed the implications of this.
The summary was that we'd need to revisit system tradeoffs. We currently compress data on the cpu, because the bottleneck is the network bandwidth. But given the rate of growth of the different components of the system, the bottleneck is likely to move from the network to the cpu (or storage). At that point, we increase system performance by sending raw data and eliminating the CPU compression stage.
Things get more complex again when you look at offloading various tasks from CPU onto dedicated hardware. But my basic point is that performance of the network shouldn't be considered in isolation. If we can improve performance by "being lazy and sending everything", then where's the harm?
>> Member functions are nice for associating a function with an object. > We have that. Function pointers. Kernel uses them all over.
With a function pointer, you pay for an extra pointer indirection: member functions on a class do not suffer that overhead unless they are virtual -- in which case the cost will be essentially the same as for C (if you need to pay attention to the structure of your vtable -- say, to avoid cache-thrash -- then you may decide to use tables of function pointers, even in C++)
C++ sucked 12 years ago, so attempting to support it now, 12 years later is a stupid idea.
Sorry, that argument doesn't quite work for me.
As I understand it, this patch would simply add runtime support to give a kernel-module-writer the option of experimenting with C++, if desired. Accepting it would not force anyone to use C++. It possibly that the patch itself could be written in C, not C++, so accepting it (or a similar patch) need not introduce C++ into the kernel.
Once that support is there, you could leave it for a few years while experimenting. No one is forced to rewrite any code (unless they want to). In the meanwhile the kernel becomes increasing modular and, one day, one of the core subsystem might choose to use C++. For example, the VM subsystem could choose to use C++ without having any visible impact on other subsystems.
Linux moves forward through evolution, not revolution. Add the support, and see if its useful. If it is, people will eventually use it as the old maintainers drift away.
Almost right. The "World Service" of the BBC is actually funded from the foreign office budget -- which comes from tax payers. BBC America is an independent organisation, part of one of the big american networks (in a group with Discovery and TLC).
The domestic BBC has two sources of funding: the license fee and "commercial ventures". For example, they sell cheesy old series to PBS for american viewers. And, of course, they sell DVDs, etc.
The filesystem part of Clearcase is nice, but I don't think it is actually necessary to implement clearmake style dependency watching: In the past, I've tracked down a dependency issue in a makefile simply by running the commands under strace, and seeing what files were read/written by each rule.
Of course, running under strace does have a performance hit.
I agree that "Advanced" is in the eye of the beholder. An MS example: are "Environment Variables" really an advanced options? For me, as a developer: no, they're not. For an email/office use (even an exerienced user): Yes.
A better approach is to have "options that I'm interested in, and those that I'm not". Of couse, automatgically changing menu systems have been tried, and failed.
Perhaps we need to break this down into use-cases
Change an option on something I'm working on
I'm working on a new machine -- I want to treak random options all over the place
The former probably doesn't lead to cluttered dialogs, because you associate the options with the task. For example, when I select "print", I see the "printer options".
The latter is best implemented as an import/export to text-file option. But It can be extended to support skinning: The file could include, as options, guidence as to which options are available with 1-click, and which are more hidden.
One could have a web site with look-and-feel options files, so I can load the "I'm hardcore" look and feel (which flattens all tabs on all dialogs into a single full-screen translucent dialog with a 4-point font), or a "I'm a Fedora user", which has a more sane (though greatly disliked by traditionalists) layout.
If options are a "lazy hack" then an "Advanced" tab is utter apathy.
This may be true, but I'm sure Google will not be so foolish as to believe it. When a company like Microsoft declares you as a high priority target, you have to take it as a serious threat.
I was actually blocking the entire site. But it seems that Adblock doesn't prevent the access to the site: it just disables the action once the image/script is loaded. In the case of JavaScript, it seems to wait to display the page until the script is loaded, even if its going to supress it.
Slashdot Mirror
Being human, some computer scientists and economists probably do make unwarranted assumptions. But the fact that humans can alter the rules of the game might not be relevant here: if there is an underlying meta-game whose rules constrain how the rules can be altered, then that is the model who's Nash equilibrium is sought. It seems, to me, unlikely that this will be an infinite regress: humans are ultimately restricted by the laws of physics. Even though any model of that meta-game would probably to too complex to be represented as any arrangement of all the subatomic particles in a human brain, it would be interesting if it were possible to characterize any of its properties mathematically.
If OpenOffice is "open", then why does a preview need to be a "sneak" preview? That term should be used for a review of something that has been developed behind closed doors, that we are only now being given a brief glimpse of...
I find many people don't know that "cd -" goes to a previous directory: great for toggling between two directories, and lighter weight than pushd/popd.
Theories do put an upper limit on the probable mass of the Higgs. According to Wikipedia, 95% confidence interval is 114 to 140 GeV. If this experiment fails to detect it then it is very likely that it doesn't exist (and therefore our theories need significant overhaul) or that it is very different from what the models predict (in which case our theories need significant overhaul).
Skeptics tell us that the climate models are riddled with errors, and cannot be trusted. It it turns out that the artic does indeed become ice free this summer then this would prove them right.
Just last year, the models were predicting summer 2013. That would be about 60 months to be ice free. If it happens this summer, then that would be less than 10 months. The time predicted by the model would be 500% greater than reality (if it happens).
How can you base environment policies on models that are shown to have such large errors? We obviously need to postpone any action until the models are much more accurate! [/sarcasm]
That assumes that the set of universes is countable. For things like non-negative integers it is indeed guaranteed that repeated subtraction will eventually reach zero. For uncountables (e.g. real numbers) this is not true. If the set of encapsulated universes is some strange quantum string super-symmetric imaginary set then perhaps it's not countable.
- fix the damage caused by each infection
- pay for AV, plus pay to fix the damage caused by each infection. (hopefully fewer infections)
The argument is that the first option is cheaper because the number of infections prevented doesn't cover the cost of the AV software.A corporate environment isn't the same as a home user. Given that there are going to be some infections, they need the procedures and infrastructure in place to clean up damage either way. The incremental cost of additional infection is therefore quite low.
Of course, even with a paper trail there could be a warehouse fire, or flood, or whatever to destroy the records (even in a "secure" box). What's needed to to store the votes in a safe way that cannot be easily erased: for example, write a ROM to store the original records during the election; and then when the polls close create multiple backup copies (e.g. burn a set of write-once CDs) that you give to each election observer. (The original ROM can be made of paper if you want; but I'd still want multiple off-site backups to be made before the elections workers go home for the day)
It is of course true that there is uncertainty in the models -- this fact even makes it into most non-scientific reporting. The problem that I see is that the people who focus on these uncertainties as a basis for inaction typically assume that the errors lead to systematically pessimistic models. I do not know of any evidence for this skewed error distribution: it is equally likely that the errors lead to models that are optimistic. Activists may wish to promote one particular interpretation but purely scientific publications tend to be scrupulous is their desire not to be seen as alarmist.
I'd say the problem is that premature optimization leads people to overly complex, and therefore hard, solutions. If you're willing to live with a pure message passing system (i.e. something equivalent to Unix processes, not threads) then most of the problems associated with parallel programming a vastsly diminished (spaghetti coding may still lead to deadlocks and livelocks; but a little disciple will avoid that, most of the time -- it's not "hard").
If this pure message passing system can take advantage of an extra core or two, then maybe you can live with its inefficiency. To assume otherwise is a premature optimization. Once you identify that optimization is actually necessary then you have two options: optimize it into a single threaded program (yes, sequentialization is an optimization) or else start sharing memory and adding locks, etc.
Most problems are moderately parallelization; so you should train yourself to code them in that way. Then you don't need to rearchitect to take advantage of the extra hardware resources.
IIRC, the senate vote pertained to instructions to the US negotiators: it instructed them, amongst other things, not to come back with an agreement that didn't limit the emissions China and India. Sure, the negotiators came back with a treaty the didn't abide by all the instructions (treaties never do: the public instructions are a negotiating position): but no vote was ever taken on the result of the negotiations.
The obvious result of the creation of multiple internets is that someone will develop a protocol to interconnect them. It'd be clumsy to name this thing the "inter-inter-network", so perhaps it will be the "Interweb".
This interweb protocol will feature a unified naming system, access to porn, and everything else we've come to love about the internet. The only difference is that there'll be an extra layer of distributed control.
Ultimately, busines as usual.
Computer Scientists studying artificial intelligence have used evolutionary programming in many contexts -- even to design hardware. If evolution can be a basis for artificial intelligence then it can also be an explaination for natural intelligence.
So scientists could turn ID on its head. By embracing it, then can teach that evolution is not a random process. Indeed it is the filtering, not the variation, that adds information to the system. By explainng a non-supernatural origin for intelligence, we would undercut attempts to disprove evolution by identifying ever more obscure examples that suggest that intelligence was needed in their design.
10 years behind. Hmm. So they're about due for their internet bubble :).
That techies may regard a lack of literacy is a badge of honor is a mirror of the pervasive attitude amongst the literate that holds a lack of technical knowledge as a badge of honor. How many (non-technical) people do you know who will proudly proclaim that they don't understand algebra/trig/calculus?
The filesystem abstraction is good: You have a lump of data, and any process can stream it in by asking for it by name.
...) in more ways than just pipes.
But we are stuck with the idea that only kernel-kackers know where the data comes from. Even things link Linux' VFS require kernel modules to add new filesystems. So user-mode users can't add new types of files.
Why is this important? There are several types of problems that could be easily solved using simple user-mode mount points:
1) persentation of information: Lets say we have a set of objects (or database rows -- the data source shouldn;t matter), and you want to present it as a file. The unix-way is to run a query to generate a file. The you can look at the data in a n editor; and if you modify it, you can run an update script to put the data back. So we have 2 operations to "open" the data, and 2 to update it. Why?
A kluge solution would be to attach trigers to the open/close file operations, but that doesn't really work. I want to be able to type:
ls people.age
vi people.age/20-24
{edit and save}
and have it all work dynamically (i.e. I'd be able to use standard unix tools to browse data, and modify it).
Non of this is rocket science. People talk about database file systems, but they're looking at the wrong part of the problem. Anyone with root access can easily (well moderately so) write a kernel module that does this today. But why isn't it user-mode?
A second usermode filesystem app should be version control. It should be possible to write a filesystem client similar to Clearcase without being a kernel hacker.
I remember I once asked on Perlmonks about a tool called PerlFS, that lets you write filesystems in usermode (though you do need to install a kernel-module to set it up). I was laughed off the site -- there is a mindset that says "filesystems are kernel apps". "It'd be too slow" people say, forgetting that you can mount (and use) NFS over a 14K modem. "It'd be insecure" is another favorite.
People build IDE tools for developing software, but they forget that Unix *is* and IDE. We just need a filesystem that lets us join together the fundamental tools (ls, more, grep,
.
The summary was that we'd need to revisit system tradeoffs. We currently compress data on the cpu, because the bottleneck is the network bandwidth. But given the rate of growth of the different components of the system, the bottleneck is likely to move from the network to the cpu (or storage). At that point, we increase system performance by sending raw data and eliminating the CPU compression stage.
Things get more complex again when you look at offloading various tasks from CPU onto dedicated hardware. But my basic point is that performance of the network shouldn't be considered in isolation. If we can improve performance by "being lazy and sending everything", then where's the harm?
>> Member functions are nice for associating a function with an object.
> We have that. Function pointers. Kernel uses them all over.
With a function pointer, you pay for an extra pointer indirection: member functions on a class do not suffer that overhead unless they are virtual -- in which case the cost will be essentially the same as for C (if you need to pay attention to the structure of your vtable -- say, to avoid cache-thrash -- then you may decide to use tables of function pointers, even in C++)
C++ sucked 12 years ago, so attempting to support it now, 12 years later is a stupid idea.
Sorry, that argument doesn't quite work for me.
As I understand it, this patch would simply add runtime support to give a kernel-module-writer the option of experimenting with C++, if desired. Accepting it would not force anyone to use C++. It possibly that the patch itself could be written in C, not C++, so accepting it (or a similar patch) need not introduce C++ into the kernel.
Once that support is there, you could leave it for a few years while experimenting. No one is forced to rewrite any code (unless they want to). In the meanwhile the kernel becomes increasing modular and, one day, one of the core subsystem might choose to use C++. For example, the VM subsystem could choose to use C++ without having any visible impact on other subsystems.
Linux moves forward through evolution, not revolution. Add the support, and see if its useful. If it is, people will eventually use it as the old maintainers drift away.
The domestic BBC has two sources of funding: the license fee and "commercial ventures". For example, they sell cheesy old series to PBS for american viewers. And, of course, they sell DVDs, etc.
Of course, running under strace does have a performance hit.
A better approach is to have "options that I'm interested in, and those that I'm not". Of couse, automatgically changing menu systems have been tried, and failed.
Perhaps we need to break this down into use-cases
- Change an option on something I'm working on
- I'm working on a new machine -- I want to treak random options all over the place
The former probably doesn't lead to cluttered dialogs, because you associate the options with the task. For example, when I select "print", I see the "printer options".The latter is best implemented as an import/export to text-file option. But It can be extended to support skinning: The file could include, as options, guidence as to which options are available with 1-click, and which are more hidden.
One could have a web site with look-and-feel options files, so I can load the "I'm hardcore" look and feel (which flattens all tabs on all dialogs into a single full-screen translucent dialog with a 4-point font), or a "I'm a Fedora user", which has a more sane (though greatly disliked by traditionalists) layout.
If options are a "lazy hack" then an "Advanced" tab is utter apathy.
This may be true, but I'm sure Google will not be so foolish as to believe it. When a company like Microsoft declares you as a high priority target, you have to take it as a serious threat.
I was actually blocking the entire site. But it seems that Adblock doesn't prevent the access to the site: it just disables the action once the image/script is loaded. In the case of JavaScript, it seems to wait to display the page until the script is loaded, even if its going to supress it.