What size is your project? For small projects with one to three people who all work in the same place yu can use RCS. It is serverless and works inside the file system. For many years I simply NFS mounted the RCS directories onto the development machine. There is almost zero setup and very little learning curve.
I used to do that, but it has one big problem: all it takes is one person who doesn't believe in releasing locks, and everyone else is SOL. CVS (which can also be operated serverless) doesn't have that problem, and it can manage multiple directories at once. (Yes, there are fancier systems, but what there isn't really is a reason to keep on using RCS directly.)
Sounds remarkably a lot like the free market working.
Yes, but not for the power companies.
Nobody ever promised that the free market would work in favor of specific companies or individuals. At best it functions at a "whole system" level by overall encouraging efficient use of resources, but that hides a whole infernal circle of detail-devils.
At the other end of the spectrum are the "wishy-washy" sciences which have no proofs, just uncontrolled observations: climatology, paleontology, social sciences, etc.
Don't forget to add astronomy to that list. After all, nobody's ever managed to conduct an experiment on a galaxy under laboratory conditions...
I fail to see how you can draw any conclusions about the reliability of atmospheric physics papers from a study of biomedical research papers.
It's not much more difficult than extrapolating it to high-energy physics. (It doesn't.)
In other news, researchers have discovered that in the medical sciences, 1/3 == "most". When asked for a comment, a leading mathematician who refused to be named described this as "a crock of shit", and added that the old saw about it being dangerous to let a medic near a calculator remains true.
VM's come in two basic varieties: low-level and high-level. Low-level VMs are really software-implemented microprocessors, and targeting them is like writing another back-end for GCC, though with some odd instructions. High-level VMs are much much easier to generate code for, but tend to be locked to a particular front-end language (or group of semantically-similar languages) because the operations of the VM capture a lot of high-level details.
If someone is peddling a universal VM, they are either doing a new low-level VM (oh great, we've already got x86, JVM and CLR and they have a lot more existing tool support thankyouverymuch) or they're doing a high-level VM (you want my language to change to be yours?!?) It matters not which: both are foolish. (In fact, I'll keep doing my own high-level VM implementations, since then I can make them highly efficient for the key use-cases I care about by adding special-purpose code for just that. That's fine, because I don't claim universality at all.)
Each language is most likely going to require some minor changes in order to support interoperability at the VM level, and of course there will be quirks and gotchas on each VM as well.
I think you underestimate the problem. At the VM level, you're dealing with the deep language semantics only; simple stuff tends to be either syntax or in the language libraries. When you mess with the deep semantics, you have far reaching consequences. For example, consider the differences caused by switching between mutable and immutable values, or between simple variables and vars where accessing them can cause reentrant calls to the VM, or between eager and lazy evaluation of expressions.
Those who argue for the creation of The One VM should go back to school to re-learn their semantics classes, since their position demonstrates deep ignorance.
assume 1 and 2 are there because 3 was still numbered
I still remember Windows 2 with cold shudders. Win3.0 was much much better, both in usability and stability. (Mind you, running a Win2 application under Win3 was better still, since then you also got a decent amount of speed...)
You're missing the point: the visual components isn't a generic purpose programming language. It's a domain specific language tailored to a specific task.
Whether it's visual, or it's just a bunch of XML markup is up the implementers. Sometimes some paradigms are much simpler to present visually, and then visual editing can be used.
You underestimate the degree to which the syntactic idioms constrain things. It takes a lot of work to create a visual programming language's infrastructure, most of which is spent increasing the set of supported idioms. ("What does it mean if A overlaps B in one corner?" and stuff like that.) My experience with real users (yes, I wrote a domain-specific visual programming language) indicates that they tend to want a very large set of idioms. It's a lot of work, and runs the real risk of having the users turn round at the end and go back to textual forms. Don't diss textual DSLs; they work well. (I think this may be because there's only a few basic syntactic classes in language, and you can get a long long way with just two - verbs and nouns.)
My point is that, while it might be possible to beat the linguistic model for DSLs, it's very hard to do so with graphical models, and the effort is probably better spent elsewhere to be honest.
Think of it that way: the DSL and the models they represent don't explain *how* things work, but *what* the major agents in a system are there and their interaction.
They are evolved metadata, an evolved "settings" file, that lets you set more things in the system than normally you're able to.
I've been getting interested in ontological descriptions of systems recently, as you get all sorts of nice reasoning over the metadata "for free" (or rather someone else has done the work for you). I've not got to the bottom of that rabbit hole yet though, so judgement is reserved (except to note that it will be useful for at least one domain of interest: datacenter management).
BTW, if you're doing how things interact them you're (at a higher level of abstraction) doing how things work. That's an inescapable truth.
The basic idea here is that any bigger project can be made more maintainable and flexible at the same time, if the deveopers create a domain specific model for the given task, and let the end-users (for example accountants, drug store chemists, biologists, business owners) model the concrete behaviour of the application by manipulating that simplified and specialized language, often visually, the way an UML diagram or a spreadsheet works.
They're probably doomed. It's very very hard to make a visual programming language not suck (the closest I ever got involved having large gobs of text inside the visual blobs, which isn't very visual!) because handling scaling of complexity is hard visually.
But that's only the minor reason for trouble. The major reason is that most non-programmers can't program at all in anything because they can't think systematically enough. It seems that relatively few people can, though I don't know whether it is an inborn talent or a learnable skill. Either way, for most of the population computers are magic miracle machines and programmers the priests/wizards. And they're mostly happy with this (and they'd be happier still if programmers were better at working out what to do for them, but that's a whole 'nother story).
Are you kidding? Exchange has had security and IMAP/SMTP/POP3 since before GMail existed.
But then you're hosting a server (or more likely several) yourself, which has a butt-load of downsides. If GMail is seriously in the picture, Exchange isn't. (MS have other products that are more comparable, but you do need to compare like with like.)
For example, I don't know what Uni you're from, but a lot of Universities have faculty and students who are involved in research which might be of a nature where it might not be good to have them sending emails through a third-party.
You're letting undergraduates work on Sensitive material? You've got big problems beyond email there...
Which is to say that outsourcing email for undergrads is fine as the privacy concerns are next to zero from an institutional perspective. OTOH, it might be an idea to keep postgraduates (and staff too) in-house so that you have a better handle on those privacy concerns. Or at the very least run a separate procurement with more stringent requirements (e.g. no non-encrypted access to the system possible).
There was an article a couple years back about a technique for recovering redacted text with pretty high reliability.
It used the fact that most standard fonts have variable spacing, and that once you've determined the font you can model that only certain combinations of letters will actually fit in the space of the redacted word or words.
The Big Black Box approach works really well with numbers, as digits are often all the same width even in variable-width fonts. Add to that the fact that most often you could reorder the digits and still have something equally plausible, and you've got no way to recover; the information is gone.
We are off of the gold standard -- something that wouldn't fluctuate so badly as this. Not saying whether or not going off the gold standard was a bad idea, I just see that basing the US economy on this is just bad.
Oh good grief! A gold-bug!
The primary source of wealth is the effort of people, with fuels of various kinds a secondary source. Gold's only valuable because people value it, and if people were to decide that it isn't worth as much as it used to be, then it would be a bad time to have your fortune in it. The same goes for any other commodity; there's nothing inherently special about gold (other than its history, which isn't really a basis for investment). What's really worthwhile is what you can do with those resources.
You're completely wrong. It's a standard feature of Ubuntu and Vista, and everyone under 25 uses it.
But that's because everyone over 25 (who cares) buys multiple monitors. Why use virtual desktops when you can afford to make your real desktop big enough to hold everything?
While that rule of thumb is a good one, there may in fact be applications today in the graphics and processing world that require insane amounts of memory.
You shouldn't do more than 2x simply because if you've got any single application that is using significantly more than physical memory (or a combination of apps that goes more than twice physical) then your performance will be so terrible that you'd probably be faster going out and buying more memory. (I say this from the perspective of someone who has written apps that had working sets larger than physical memory many years ago; intensely painful!)
Swapping/paging of your working set memory is a guaranteed ticket to slow. If you've got problems there, it's time to stop being cheap and get that upgrade.
It's a marketing phrase, designed to encourage you to offload your computing to the Cloud.
That's not all bad, you know. Sometimes that's actually a good thing. But you've got to keep some level of control over the key things so that you're not beholden to a single supplier or it is indeed a trap.
The Cloud is where someone else controls your information, not you. Stallman says it's a trap. I'm inclined to believe him. When MicroHard starts promoting it? All the more reason to be leery of it.
They're doing it because customers say they want it.
Of course, what we really need are standards for how to work with Clouds. Like that we can avoid vendor lock-in, and possibly get Free implementations too (provided the non-software parts get addressed right that is, and that's where it's hard for everyone anyway). Right now, Clouds are the SOA Wild West, and it's not clear yet who are the main banditos.
No, the definition of "buggy" is not open to interpretation. If your language defines a destructor named toString, then that is a feature of the language, not a bug. Any implementation which does not correctly implement it is therefore buggy, but the language itself is not.
Now, anyone is certainly free to argue whether a destructor named toString, or any particular feature of JavaScript, is a good idea, but saying that the language itself is "buggy" or "broken" is, by definition, incorrect.
While you're correct about "buggy" (which describes a deviation between specification and implementation), you're way wrong about "broken". Things most certainly can be "broken by design", which refers to the state of things when a specification says something that just can't be argued to be correct without the application of hallucinogens.
Whether or not JS fits that bill is a matter of debate. (I'm not too fussed either way there TBH; I just prefer to use other things.)
Just because you can access the source doesn't mean you have license to do anything with it. There own extensions, especially if contained in separate source files, do not need to be covered by the same license.
But if your business model depended on keeping the code confidential you wouldn't send it over the wire to browsers to execute, whatever the license says, since you can be sure that people will poke around and probably half-inch bits and pieces of it. If you want it confidential, you don't send the source to the user.
Alan Turing (how in the Hell is he not on that page?)
Turing was not a programmer. If the list had been of famous computer scientists (or possibly even mathematicians) then he'd have been in there for sure.
Fannie and Freddie are government-created entities, and are not run nor structured like other private companies.
Washington policy, particularly centered around an "ownership society," loosened rules and practically forced some companies to make loans to poor people who couldn't afford them in the mistaken idea that it somehow creates equality.
Several senators - particularly Dodd and Sanders - continually blocked measures by the Bush administration to actually be responsible in their required oversight of Fannie and Freddie.
But that's hardly the whole story. There's a big fat vein of greed involved, and that originated in the private sphere. Or are you claiming that the Feds forced AIG to issue all that dodgy bond insurance?
Yep. A Slightly better phrasing I've seen, every time our old Windows Exchange 4.0 box came up"
Warning: An unexpected condition occured: Exchange started successfully.
As explained, its a race condition calling GetLastError().
It's also wholly correct in every respect, given that I've never had anyone manage to explain to me why Exchange is ever considered part of the solution instead of the problem.
Slashdot Mirror
What size is your project? For small projects with one to three people who all work in the same place yu can use RCS. It is serverless and works inside the file system. For many years I simply NFS mounted the RCS directories onto the development machine. There is almost zero setup and very little learning curve.
I used to do that, but it has one big problem: all it takes is one person who doesn't believe in releasing locks, and everyone else is SOL. CVS (which can also be operated serverless) doesn't have that problem, and it can manage multiple directories at once. (Yes, there are fancier systems, but what there isn't really is a reason to keep on using RCS directly.)
I always thought that Orwell was an optimist.
George Orwell was a boat? That explains... umm, that explains very little at all.
Sounds remarkably a lot like the free market working.
Yes, but not for the power companies.
Nobody ever promised that the free market would work in favor of specific companies or individuals. At best it functions at a "whole system" level by overall encouraging efficient use of resources, but that hides a whole infernal circle of detail-devils.
At the other end of the spectrum are the "wishy-washy" sciences which have no proofs, just uncontrolled observations: climatology, paleontology, social sciences, etc.
Don't forget to add astronomy to that list. After all, nobody's ever managed to conduct an experiment on a galaxy under laboratory conditions...
I fail to see how you can draw any conclusions about the reliability of atmospheric physics papers from a study of biomedical research papers.
It's not much more difficult than extrapolating it to high-energy physics. (It doesn't.)
In other news, researchers have discovered that in the medical sciences, 1/3 == "most". When asked for a comment, a leading mathematician who refused to be named described this as "a crock of shit", and added that the old saw about it being dangerous to let a medic near a calculator remains true.
They sell things which don't work, brainwash the people to whom they sell their things, and harass people whom they can't sell their things to.
There are software companies who'd fit that description :)
There used to be quite a few banks who fit that description too.
I don't want to just poo-poo this idea
Well, I don't mind doing just that!
VM's come in two basic varieties: low-level and high-level. Low-level VMs are really software-implemented microprocessors, and targeting them is like writing another back-end for GCC, though with some odd instructions. High-level VMs are much much easier to generate code for, but tend to be locked to a particular front-end language (or group of semantically-similar languages) because the operations of the VM capture a lot of high-level details.
If someone is peddling a universal VM, they are either doing a new low-level VM (oh great, we've already got x86, JVM and CLR and they have a lot more existing tool support thankyouverymuch) or they're doing a high-level VM (you want my language to change to be yours?!?) It matters not which: both are foolish. (In fact, I'll keep doing my own high-level VM implementations, since then I can make them highly efficient for the key use-cases I care about by adding special-purpose code for just that. That's fine, because I don't claim universality at all.)
Each language is most likely going to require some minor changes in order to support interoperability at the VM level, and of course there will be quirks and gotchas on each VM as well.
I think you underestimate the problem. At the VM level, you're dealing with the deep language semantics only; simple stuff tends to be either syntax or in the language libraries. When you mess with the deep semantics, you have far reaching consequences. For example, consider the differences caused by switching between mutable and immutable values, or between simple variables and vars where accessing them can cause reentrant calls to the VM, or between eager and lazy evaluation of expressions.
Those who argue for the creation of The One VM should go back to school to re-learn their semantics classes, since their position demonstrates deep ignorance.
assume 1 and 2 are there because 3 was still numbered
I still remember Windows 2 with cold shudders. Win3.0 was much much better, both in usability and stability. (Mind you, running a Win2 application under Win3 was better still, since then you also got a decent amount of speed...)
You're missing the point: the visual components isn't a generic purpose programming language. It's a domain specific language tailored to a specific task.
Whether it's visual, or it's just a bunch of XML markup is up the implementers. Sometimes some paradigms are much simpler to present visually, and then visual editing can be used.
You underestimate the degree to which the syntactic idioms constrain things. It takes a lot of work to create a visual programming language's infrastructure, most of which is spent increasing the set of supported idioms. ("What does it mean if A overlaps B in one corner?" and stuff like that.) My experience with real users (yes, I wrote a domain-specific visual programming language) indicates that they tend to want a very large set of idioms. It's a lot of work, and runs the real risk of having the users turn round at the end and go back to textual forms. Don't diss textual DSLs; they work well. (I think this may be because there's only a few basic syntactic classes in language, and you can get a long long way with just two - verbs and nouns.)
My point is that, while it might be possible to beat the linguistic model for DSLs, it's very hard to do so with graphical models, and the effort is probably better spent elsewhere to be honest.
Think of it that way: the DSL and the models they represent don't explain *how* things work, but *what* the major agents in a system are there and their interaction.
They are evolved metadata, an evolved "settings" file, that lets you set more things in the system than normally you're able to.
I've been getting interested in ontological descriptions of systems recently, as you get all sorts of nice reasoning over the metadata "for free" (or rather someone else has done the work for you). I've not got to the bottom of that rabbit hole yet though, so judgement is reserved (except to note that it will be useful for at least one domain of interest: datacenter management).
BTW, if you're doing how things interact them you're (at a higher level of abstraction) doing how things work. That's an inescapable truth.
The basic idea here is that any bigger project can be made more maintainable and flexible at the same time, if the deveopers create a domain specific model for the given task, and let the end-users (for example accountants, drug store chemists, biologists, business owners) model the concrete behaviour of the application by manipulating that simplified and specialized language, often visually, the way an UML diagram or a spreadsheet works.
They're probably doomed. It's very very hard to make a visual programming language not suck (the closest I ever got involved having large gobs of text inside the visual blobs, which isn't very visual!) because handling scaling of complexity is hard visually.
But that's only the minor reason for trouble. The major reason is that most non-programmers can't program at all in anything because they can't think systematically enough. It seems that relatively few people can, though I don't know whether it is an inborn talent or a learnable skill. Either way, for most of the population computers are magic miracle machines and programmers the priests/wizards. And they're mostly happy with this (and they'd be happier still if programmers were better at working out what to do for them, but that's a whole 'nother story).
Are you kidding? Exchange has had security and IMAP/SMTP/POP3 since before GMail existed.
But then you're hosting a server (or more likely several) yourself, which has a butt-load of downsides. If GMail is seriously in the picture, Exchange isn't. (MS have other products that are more comparable, but you do need to compare like with like.)
For example, I don't know what Uni you're from, but a lot of Universities have faculty and students who are involved in research which might be of a nature where it might not be good to have them sending emails through a third-party.
You're letting undergraduates work on Sensitive material? You've got big problems beyond email there...
Which is to say that outsourcing email for undergrads is fine as the privacy concerns are next to zero from an institutional perspective. OTOH, it might be an idea to keep postgraduates (and staff too) in-house so that you have a better handle on those privacy concerns. Or at the very least run a separate procurement with more stringent requirements (e.g. no non-encrypted access to the system possible).
There was an article a couple years back about a technique for recovering redacted text with pretty high reliability.
It used the fact that most standard fonts have variable spacing, and that once you've determined the font you can model that only certain combinations of letters will actually fit in the space of the redacted word or words.
The Big Black Box approach works really well with numbers, as digits are often all the same width even in variable-width fonts. Add to that the fact that most often you could reorder the digits and still have something equally plausible, and you've got no way to recover; the information is gone.
We are off of the gold standard -- something that wouldn't fluctuate so badly as this. Not saying whether or not going off the gold standard was a bad idea, I just see that basing the US economy on this is just bad.
Oh good grief! A gold-bug!
The primary source of wealth is the effort of people, with fuels of various kinds a secondary source. Gold's only valuable because people value it, and if people were to decide that it isn't worth as much as it used to be, then it would be a bad time to have your fortune in it. The same goes for any other commodity; there's nothing inherently special about gold (other than its history, which isn't really a basis for investment). What's really worthwhile is what you can do with those resources.
In short, if voting machines cannot meet the Nevada gaming commission regulations then politicians are at best gambling with our votes.
So... you think there's an element of chance involved in the voting process from the perspective of the politicians?
You know what? That's charmingly naive.
You're completely wrong. It's a standard feature of Ubuntu and Vista, and everyone under 25 uses it.
But that's because everyone over 25 (who cares) buys multiple monitors. Why use virtual desktops when you can afford to make your real desktop big enough to hold everything?
While that rule of thumb is a good one, there may in fact be applications today in the graphics and processing world that require insane amounts of memory.
You shouldn't do more than 2x simply because if you've got any single application that is using significantly more than physical memory (or a combination of apps that goes more than twice physical) then your performance will be so terrible that you'd probably be faster going out and buying more memory. (I say this from the perspective of someone who has written apps that had working sets larger than physical memory many years ago; intensely painful!)
Swapping/paging of your working set memory is a guaranteed ticket to slow. If you've got problems there, it's time to stop being cheap and get that upgrade.
Because this will alienate all the dumb people.
You say this like it's a bad thing. Your priorities are wrong.
It's a marketing phrase, designed to encourage you to offload your computing to the Cloud.
That's not all bad, you know. Sometimes that's actually a good thing. But you've got to keep some level of control over the key things so that you're not beholden to a single supplier or it is indeed a trap.
The Cloud is where someone else controls your information, not you. Stallman says it's a trap. I'm inclined to believe him. When MicroHard starts promoting it? All the more reason to be leery of it.
They're doing it because customers say they want it.
Of course, what we really need are standards for how to work with Clouds. Like that we can avoid vendor lock-in, and possibly get Free implementations too (provided the non-software parts get addressed right that is, and that's where it's hard for everyone anyway). Right now, Clouds are the SOA Wild West, and it's not clear yet who are the main banditos.
No, the definition of "buggy" is not open to interpretation. If your language defines a destructor named toString, then that is a feature of the language, not a bug. Any implementation which does not correctly implement it is therefore buggy, but the language itself is not.
Now, anyone is certainly free to argue whether a destructor named toString, or any particular feature of JavaScript, is a good idea, but saying that the language itself is "buggy" or "broken" is, by definition, incorrect.
While you're correct about "buggy" (which describes a deviation between specification and implementation), you're way wrong about "broken". Things most certainly can be "broken by design", which refers to the state of things when a specification says something that just can't be argued to be correct without the application of hallucinogens.
Whether or not JS fits that bill is a matter of debate. (I'm not too fussed either way there TBH; I just prefer to use other things.)
Just because you can access the source doesn't mean you have license to do anything with it. There own extensions, especially if contained in separate source files, do not need to be covered by the same license.
But if your business model depended on keeping the code confidential you wouldn't send it over the wire to browsers to execute, whatever the license says, since you can be sure that people will poke around and probably half-inch bits and pieces of it. If you want it confidential, you don't send the source to the user.
Alan Turing (how in the Hell is he not on that page?)
Turing was not a programmer. If the list had been of famous computer scientists (or possibly even mathematicians) then he'd have been in there for sure.
Several facts:
Fannie and Freddie are government-created entities, and are not run nor structured like other private companies.
Washington policy, particularly centered around an "ownership society," loosened rules and practically forced some companies to make loans to poor people who couldn't afford them in the mistaken idea that it somehow creates equality.
Several senators - particularly Dodd and Sanders - continually blocked measures by the Bush administration to actually be responsible in their required oversight of Fannie and Freddie.
But that's hardly the whole story. There's a big fat vein of greed involved, and that originated in the private sphere. Or are you claiming that the Feds forced AIG to issue all that dodgy bond insurance?
Yep. A Slightly better phrasing I've seen, every time our old Windows Exchange 4.0 box came up"
Warning: An unexpected condition occured:
Exchange started successfully.
As explained, its a race condition calling GetLastError().
It's also wholly correct in every respect, given that I've never had anyone manage to explain to me why Exchange is ever considered part of the solution instead of the problem.