It is, indeed a big problem. Solaris zones, solaris containers, obviously have nothing to offer here. The issue with colaborative grid computing is that your computation (or some of it) may well be run on your colaborators' computers.
This is a major issue with many HTC (high-throughput computing, which is what this is, really) solutions. In fact, many sites look to create their own dedicated "pools" of compute nodes rather than push out computation to less sensitive areas.
So, generally, you are stuck with the "don't compute it somewhere you don't trust" issue. This is a problem in universities, too: we (in the UK) have data-proection act issues with many of the HTC jobs we run, since they may well be image processing for the medical faculty here.
An alternative approach, which requires work and doesn't always succeed, is to break down your computation into segments: compromising the security of a computation or result relies on compromising all the segments. Eg, for many image processing tasks (X-ray processing), it's possible to dish out tiny pieces of the picture to be processed. Only the originator of the computation actually knows which pieces go together, and how, to recreate the solution. Sometimes this is a viable solution; at other times, not. It often requires retooling the algorithms used, which is a highly expensive proposition requiring a great deal of skill.
1. "It may be *illegal* to use GPLed code..." It's not use, it's distribution, that the GPL talks about. Using it isn't illegal.
2. Distributing it isn't illegal, either. If a package exports functionality via an exposed API, and that package and its API aren't GPL, you can still write a "plugin" that uses that API. And you can GPL it. And you can distribute it under the GPL. And it doesn't "contaminate" the parent product.
3. If the LKP contains or is substantially derived from linux code (there's not much reason for it to be, it's a syscall translation layer) then it would inherit the GPL.
It's a sensible tool. It might be a worthwhile educational process developing and deploying java "by hand" - once - but given the wealth of decent IDEs out there with integrated J2EE support, it's only a fool who'll go through that pain on a regular basis. Use the tools, lose the pain.
I think the point (that should probably be conceded) is that if you hire a team of professional lisp developers there's a rather good chance that they are really going to know what they're doing. But you'll probably find that you can get decent "commodity" programmers at a lower cost and more readily.
"To scale java well..." means what? You can "scale" java just as trivially as PHP if all you're after is what you get from a no-brainer "scaling" of php. If you're talking about session migration, etc: actually, that's pretty simple. What does PHP give you in that regard?
"Fast development..." again, I suspect you've done no more than trivial java deployment without taking advantage of any of the many IDEs that assist with this. By-hand java webapp deployment is actually pretty simple: drop a file onto a server. If you're talking about the effort involved in packaging, then perhaps you should try not doing it by hand?
And finally: looking at "Enterprise" scaling of PHP, you'll find that Zend's stuff doesn't come free. Or even cheap.
In a nutshell: my experience of the provisioning and deployment of java apps is not the same as yours. Your comments lead me to believe I've done it a lot more than you.
"got to be better than make". I'm not so sure. There appear to be a lot of people at loggerheads over ant vs make in this thread. Perhaps they fail to see the distinction, which I'm sure you're familiar with: compiling C (and C++) is harder than compiling java, by a long chalk.
With ant, you use the javac task and let it get on with it. Generally, no more than 10% (upper limit) of my ant scripts are actually devoted to compiling java. That's because platform dependencies, defines, conditional includes and library definitions are not something that tend to be a problem in the java world. Java itself is not a difficult language to compile, compared (say) to C++. Conditional includes, etc, _have_ been a problem with every major C / C++ project I've worked on.
We use ant where possible to produce a one-command "get this project running" target. The ant scripts can be quite complex, but they're predictable and (since we work with remote project partners across europe) such a setup makes troubleshooting far simpler: we require developers to provide as little external environment as possible, and have ant recreate it. (It turns out that when I did this for the first time I was basically reinventing what maven does; however, we still find maven opaque in comparison.)
The situation is much more complex with our C++ stuff, which consequently tends to live in-house. It's possible to get a makefile working that'll cooperate with a posix-compatible environment in order to work. If you can guarantee that environment will exist, you might well be better off sticking with make, or look at jam.
We use ant build scripts alongside all our (eclipse-hosted) projects. We make sure the ant script is compatible with eclipse's notion of dynamic compilation, so that the two will work seamlessly together. However, the big advantage (as you point out) is that this means we don't need to run eclipse in headless mode to build and deploy a project: just use ant.
You're failing to see the Linspire argument behind "running as root, or not, is irrelevant". MOST of the value in a machine's files is contained in the user-created, user-owned stuff. Who cares about the rest? You can recreate it with only a loss of your time. Your own private data, once leaked, cannot be remade private.
Your thinking is flawed. The counterargument is the Linspire "running as root is irrelevant" position: you don't need root to access the most importnat files on your machine - the user data files - you just need to be the user that owns those files.
Unless you're running firefox as a separate UID to the one that owns all your important data, and that UID is incapable of accessing those files, then you're in a position where you need a real fix to GM.
Easy fix won't work. Javascript is turing complete, and comes with eval(). Static inspection can't catch every invocation. The correct approach is to separate out the contexts.
You need to (re)read the thread. A web-page can subvert a greasemonkey script. The problem is that your (trusted) greasemonkey scripts have a security context associated with them that usually has a large number of privileges. A malicious web page (not a malicious greasemonkey script) can access the GM security context. Since there are a number of different ways in which GM scripts can be triggered, there are a number of potential avenues that need close examination.
That is to say: firstly, the GM architecture needs a step taken back and to be rethought with a security hat on (this is going on at the moment); secondly, it demonstrates that every piece of software that embeds a scripting language is doomed to reinvent outlook's bugs. Because doing this correctly is _hard_.
Yeah, the big advantage of RSS 1.0 is that it's basically using the RDF model. Yes, it has a "regular" format, but I don't much care about that, because I consume it using my RDF tools. The nice thing that you get is the ability to hang assertions (using arbitrary properties) off RSS items. Thus, RSS+Events (as an example) - although frankly it means you have the ability to have "rich" (or if you prefer, "multimedia") RSS feeds. Or you can refer to your FOAF entries. And so on.
Atom gives you more-or-less the same thing; its advantage is mostly that it just doesn't have a name that automatically gets Dave Whiner frothing; (also, they've actually specified a protocol as well as a format, but that part's trivial).
I'm sorry?! If the frame of reference is rotating, there IS an effective resulting potential gradient.
Just because you get taught the simpler maths first earlier in your college physics course* is no reason to think that inertial frames of reference are in any way "preferred". you're showing an inertial bias in your reasoning:-)
* You may have a point. Many undergrad physicists may not be capable of the calculus required to cope with general frames of reference:-/
It's a pointless and pretty meaningless distinction. If you're in the right (rotating) frame of reference, what you experience is indistinguishable from a "centrifugal force".
You're spot on. However, taking the whole population, economists love to derive absolute dollar values for a particular person. (You'll see this all the time: "slacking workers cost the US $480 billion a year".) Clearly the powers that be do NOT reckon the value of a human life to be infinite - or even to be of particalarly large finite value - because otherwise they wouldn't spend them so cheaply in war, by continuing to do little about poverty (domestic and worldwide) and so on and so forth.
The "cost" of many things is often touted be opponents of measures - eg, the Kyoto protocols. Whatever you think of their efficacy (they don't go far enough), we hear a lot about the dollar cost to the US (in particular). Yet John Kerry was talking, during the run-up to the election, about the jobs that Kyoto compliance would create in the US.
Summary: I agree with your sentiment. The equation of a dollar value to a human life is something that goes on all the time (eg, rail companies in the UK estimating the liklihood of failure versus the cost of maintenance; the famous Ford Pinto scandal) - doesn't mean it's right.
Well, perhaps it is. Although it's examples like this that give the lie to the assertion that economics is about the behaviour of "rational" agents.
Take a case in point. Someone I was talking to recently said, of ID cards (in the UK), that "even if they stop one more 9/11 they're worth it."
Look at that from a cost-benefit view:
Well, apart from the fact that there's no measurable way to accurately tell if such an atrocity has indeed been prevented, let's throw ball-park figures around.
These cards are going to need renewing every five years [source: government office]. Let's be generous and say that travel costs don't matter, and estimate that it takes an hour to get a card [source: I took 25% of the time it took me to get a passport in person last time]. The cost of the card, around 100 quid [source: government] (again, ignoring the tax you pay towards this, just the up-front cost) will take on average about 10 hours to earn [source: NSO figures for average hourly wage - I took the largest figure]. So, an ID card osts 11, maybe 12, hours of someone's life.
So every 5 years, 50,000,000 people will lose 11 hours. That's a total of around about 63,000 person-years. The figure I have in front of me is around 2800 people who died in 9/11 [wikipedia]. Assuming they're half-way through a long and productive life, that's a total of - what? - 98,000 person-years. So, to be "for the good", the scheme has to work, come in on budget, and actually prevent one 9/11 atrocity every 7.5 years.
There are no bins on or around train or tube stations in the UK, and haven't been since the 80s when the IRA demonstrated that they're an excellent (a) hiding place and (b) source of shrapnel.
That isn't all it takes. AirCon is about the whole environment: that includes keeping humidity levels safe, too (not too high, not too low), and not just worrying about the temperature.
"Why do we, as American citizens, have to keep a close eye on everything that our elected officials do so that they do not sneak unlawful provision into law."
Complete the well-known phrase or saying: "The price of freedom...."
Slashdot Mirror
"usability" only in a general layman's sense. The term comes from "eating your own dogfood", that is, using the app internally in anger.
There isn't sufficient energy in the solar system to complete a brute force attack.
It is, indeed a big problem. Solaris zones, solaris containers, obviously have nothing to offer here. The issue with colaborative grid computing is that your computation (or some of it) may well be run on your colaborators' computers.
This is a major issue with many HTC (high-throughput computing, which is what this is, really) solutions. In fact, many sites look to create their own dedicated "pools" of compute nodes rather than push out computation to less sensitive areas.
So, generally, you are stuck with the "don't compute it somewhere you don't trust" issue. This is a problem in universities, too: we (in the UK) have data-proection act issues with many of the HTC jobs we run, since they may well be image processing for the medical faculty here.
An alternative approach, which requires work and doesn't always succeed, is to break down your computation into segments: compromising the security of a computation or result relies on compromising all the segments. Eg, for many image processing tasks (X-ray processing), it's possible to dish out tiny pieces of the picture to be processed. Only the originator of the computation actually knows which pieces go together, and how, to recreate the solution. Sometimes this is a viable solution; at other times, not. It often requires retooling the algorithms used, which is a highly expensive proposition requiring a great deal of skill.
1. "It may be *illegal* to use GPLed code..." It's not use, it's distribution, that the GPL talks about. Using it isn't illegal.
2. Distributing it isn't illegal, either. If a package exports functionality via an exposed API, and that package and its API aren't GPL, you can still write a "plugin" that uses that API. And you can GPL it. And you can distribute it under the GPL. And it doesn't "contaminate" the parent product.
3. If the LKP contains or is substantially derived from linux code (there's not much reason for it to be, it's a syscall translation layer) then it would inherit the GPL.
My experience with all too many developers is, "we can do it slow and expensive; hey, we'll throw in badly for free." :-/
It's a sensible tool. It might be a worthwhile educational process developing and deploying java "by hand" - once - but given the wealth of decent IDEs out there with integrated J2EE support, it's only a fool who'll go through that pain on a regular basis. Use the tools, lose the pain.
I think the point (that should probably be conceded) is that if you hire a team of professional lisp developers there's a rather good chance that they are really going to know what they're doing. But you'll probably find that you can get decent "commodity" programmers at a lower cost and more readily.
You describe your reasoning as a "no brainer".
"To scale java well..." means what? You can "scale" java just as trivially as PHP if all you're after is what you get from a no-brainer "scaling" of php. If you're talking about session migration, etc: actually, that's pretty simple. What does PHP give you in that regard?
"Fast development..." again, I suspect you've done no more than trivial java deployment without taking advantage of any of the many IDEs that assist with this. By-hand java webapp deployment is actually pretty simple: drop a file onto a server. If you're talking about the effort involved in packaging, then perhaps you should try not doing it by hand?
And finally: looking at "Enterprise" scaling of PHP, you'll find that Zend's stuff doesn't come free. Or even cheap.
In a nutshell: my experience of the provisioning and deployment of java apps is not the same as yours. Your comments lead me to believe I've done it a lot more than you.
"got to be better than make". I'm not so sure. There appear to be a lot of people at loggerheads over ant vs make in this thread. Perhaps they fail to see the distinction, which I'm sure you're familiar with: compiling C (and C++) is harder than compiling java, by a long chalk.
With ant, you use the javac task and let it get on with it. Generally, no more than 10% (upper limit) of my ant scripts are actually devoted to compiling java. That's because platform dependencies, defines, conditional includes and library definitions are not something that tend to be a problem in the java world. Java itself is not a difficult language to compile, compared (say) to C++. Conditional includes, etc, _have_ been a problem with every major C / C++ project I've worked on.
We use ant where possible to produce a one-command "get this project running" target. The ant scripts can be quite complex, but they're predictable and (since we work with remote project partners across europe) such a setup makes troubleshooting far simpler: we require developers to provide as little external environment as possible, and have ant recreate it. (It turns out that when I did this for the first time I was basically reinventing what maven does; however, we still find maven opaque in comparison.)
The situation is much more complex with our C++ stuff, which consequently tends to live in-house. It's possible to get a makefile working that'll cooperate with a posix-compatible environment in order to work. If you can guarantee that environment will exist, you might well be better off sticking with make, or look at jam.
... or just use Eclipse's embedded Ant.
We use ant build scripts alongside all our (eclipse-hosted) projects. We make sure the ant script is compatible with eclipse's notion of dynamic compilation, so that the two will work seamlessly together. However, the big advantage (as you point out) is that this means we don't need to run eclipse in headless mode to build and deploy a project: just use ant.
You're failing to see the Linspire argument behind "running as root, or not, is irrelevant". MOST of the value in a machine's files is contained in the user-created, user-owned stuff. Who cares about the rest? You can recreate it with only a loss of your time. Your own private data, once leaked, cannot be remade private.
Your thinking is flawed. The counterargument is the Linspire "running as root is irrelevant" position: you don't need root to access the most importnat files on your machine - the user data files - you just need to be the user that owns those files.
Unless you're running firefox as a separate UID to the one that owns all your important data, and that UID is incapable of accessing those files, then you're in a position where you need a real fix to GM.
Easy fix won't work. Javascript is turing complete, and comes with eval(). Static inspection can't catch every invocation. The correct approach is to separate out the contexts.
You need to (re)read the thread. A web-page can subvert a greasemonkey script. The problem is that your (trusted) greasemonkey scripts have a security context associated with them that usually has a large number of privileges. A malicious web page (not a malicious greasemonkey script) can access the GM security context. Since there are a number of different ways in which GM scripts can be triggered, there are a number of potential avenues that need close examination.
That is to say: firstly, the GM architecture needs a step taken back and to be rethought with a security hat on (this is going on at the moment); secondly, it demonstrates that every piece of software that embeds a scripting language is doomed to reinvent outlook's bugs. Because doing this correctly is _hard_.
Only if you normally run firefox as a separate userid to the one that owns your home directory.
So probably: no, not right.
Guess the answer to that is that the RSS version number battle is one not worth fighting?
Congratulations, you Get It :-)
Yeah, the big advantage of RSS 1.0 is that it's basically using the RDF model. Yes, it has a "regular" format, but I don't much care about that, because I consume it using my RDF tools. The nice thing that you get is the ability to hang assertions (using arbitrary properties) off RSS items. Thus, RSS+Events (as an example) - although frankly it means you have the ability to have "rich" (or if you prefer, "multimedia") RSS feeds. Or you can refer to your FOAF entries. And so on.
Atom gives you more-or-less the same thing; its advantage is mostly that it just doesn't have a name that automatically gets Dave Whiner frothing; (also, they've actually specified a protocol as well as a format, but that part's trivial).
I'm sorry?! If the frame of reference is rotating, there IS an effective resulting potential gradient.
:-)
:-/
Just because you get taught the simpler maths first earlier in your college physics course* is no reason to think that inertial frames of reference are in any way "preferred". you're showing an inertial bias in your reasoning
* You may have a point. Many undergrad physicists may not be capable of the calculus required to cope with general frames of reference
It's a pointless and pretty meaningless distinction. If you're in the right (rotating) frame of reference, what you experience is indistinguishable from a "centrifugal force".
You're spot on. However, taking the whole population, economists love to derive absolute dollar values for a particular person. (You'll see this all the time: "slacking workers cost the US $480 billion a year".) Clearly the powers that be do NOT reckon the value of a human life to be infinite - or even to be of particalarly large finite value - because otherwise they wouldn't spend them so cheaply in war, by continuing to do little about poverty (domestic and worldwide) and so on and so forth.
The "cost" of many things is often touted be opponents of measures - eg, the Kyoto protocols. Whatever you think of their efficacy (they don't go far enough), we hear a lot about the dollar cost to the US (in particular). Yet John Kerry was talking, during the run-up to the election, about the jobs that Kyoto compliance would create in the US.
Summary: I agree with your sentiment. The equation of a dollar value to a human life is something that goes on all the time (eg, rail companies in the UK estimating the liklihood of failure versus the cost of maintenance; the famous Ford Pinto scandal) - doesn't mean it's right.
Well, perhaps it is. Although it's examples like this that give the lie to the assertion that economics is about the behaviour of "rational" agents.
Take a case in point. Someone I was talking to recently said, of ID cards (in the UK), that "even if they stop one more 9/11 they're worth it."
Look at that from a cost-benefit view:
Well, apart from the fact that there's no measurable way to accurately tell if such an atrocity has indeed been prevented, let's throw ball-park figures around.
These cards are going to need renewing every five years [source: government office]. Let's be generous and say that travel costs don't matter, and estimate that it takes an hour to get a card [source: I took 25% of the time it took me to get a passport in person last time]. The cost of the card, around 100 quid [source: government] (again, ignoring the tax you pay towards this, just the up-front cost) will take on average about 10 hours to earn [source: NSO figures for average hourly wage - I took the largest figure]. So, an ID card osts 11, maybe 12, hours of someone's life.
So every 5 years, 50,000,000 people will lose 11 hours. That's a total of around about 63,000 person-years. The figure I have in front of me is around 2800 people who died in 9/11 [wikipedia]. Assuming they're half-way through a long and productive life, that's a total of - what? - 98,000 person-years. So, to be "for the good", the scheme has to work, come in on budget, and actually prevent one 9/11 atrocity every 7.5 years.
There are no bins on or around train or tube stations in the UK, and haven't been since the 80s when the IRA demonstrated that they're an excellent (a) hiding place and (b) source of shrapnel.
That isn't all it takes. AirCon is about the whole environment: that includes keeping humidity levels safe, too (not too high, not too low), and not just worrying about the temperature.
"Why do we, as American citizens, have to keep a close eye on everything that our elected officials do so that they do not sneak unlawful provision into law."
Complete the well-known phrase or saying: "The price of freedom...."
What he said.