Yes, we need to know what the effects of our actions will be, if we're going to apply our effort in the best possible way, without undesirable side-effects. Yes, knowing what the effects of our actions will be would tend to require that we understand the system sufficiently to know what the causes of present effects could be; however, that's not entirely required.
We don't require that doctors know who the masked gunman was when we ask them to save the patient; their trade gives them insight into possible solutions to the problem at hand without having a full grasp on the circumstances of the trauma. Furthermore, radical intervention is more and more warranted as the risks involved in non-action increase; if your patient is dying anyway, you're willing to try just about anything, despite the decreasing chances of success and increasing chances of side-effects.
The people pushing for any action are serving a useful purpose in the end; they give the nay-sayers a reason (fear) to push for more research to make sure the right sort of change happens, for the right reasons. Without them, it's not just change that would be less likely, it's research, too.
I know this wasn't your point, so don't take this the wrong way; your comment about aether reminded me of a talk I heard once about evolution, given at a church (!); to paraphrase one particularly fun segment: "science changes its mind all the time, so it's essentially always wrong; you should instead rely on the Bible, which never changes its mind." It's wrong on so many levels, I needn't go into it directly; I should however point out that the talk was given by someone who styled himself a scientist, collected dinosaur bones, and was asking for money from the church so he could go buy more dinosaur bones, so he could put them in a museum display intended to prove that evolution (and history in general) never actually happened.
Analyzing data is hard. Asking the right questions, with the right assumptions, arriving at the right conclusions, and communication all of this clearly and fully to anyone else... is hard. And even then, we still get it wrong, at least for a while. Cherish your differences!
Don't assume that counter-data is a counter-argument: in mathematics, finding an exception to the rule is a sure sign that something's wrong; in applied sciences, it's only an exception to the rule if you meet all sorts of criteria about the circumstances of the event. Saying "CO2 has risen before" is not the same as saying any of: a) it is not rising right now b) this event has the same cause has previous events c) this event will have the same effects d) same effects at different points in time are equivalent
I'm pretty sure that was meant as an example only. The point being that GroupThink can hold us back. One of the arguments for capitalism is that you have N people all trying to find the best way to solve a problem, being rewarded when they do -- we're betting that it's more efficient in the long run to waste resources in the short term exploring different options and seeing which ones survive. When you see a whole group of players "give up" in a sense, and use the existing solution, you've got to be worried that there was some innovation there that just won't happen anytime soon now -- and if the idea is instilled that you should always go with the short-term efficiency of using off-the-shelf solutions, then you've got a long-term problem to deal with: entire generations raised to go with COTS rather than innovating. The bet here is that in the long term, it's more profitable to at least have some trained R&D people than an entire population of "users", dependent on others, and you can't have that without sometimes saying "no" to the salespeople.
I have yet to meet anybody that said their new web-based app whipped the llama's azz compared to the old thin-client or mainframe app
Unsurprising. Even with AJAX techniques to avoid refreshing the page fully, and even using JSON (maybe gzip'ed) instead of XML to reduce the traffic, and even with HTTP keep-alive to reduce the connection times, the technology used in web-apps today is still more "expensive" in terms of performance/latency than the older client/server methods. You build a 2-tier Win32 client with a direct connection to the database, and you've got a pure binary stream, composed of useful data and little else (vs. verbose XML, particularly); you don't have extra layers of webservers, you don't have a connection that starts/stops constantly, etc. You have the ability for the server to notify the client that something has changed, whereas with web-apps, you at best have something like Comet, and more likely have some sort of polling AJAX call. And the client's probably compiled, running natively, using hWnd's and whatnot; with web-apps, you may have the wonder that is javascript performing DOM updates that have to be interpreted and re-rendered by a multipurpose browser.
Of course it's less efficient. But as others have pointed out, that's not always the point. It's about control, it's about standardization, and... oh, right, it's about control.
... and stuff like wxWidgets, too. Multiple languages, multiple platforms, looks and acts like the running environment. No VM required. (Yes, I know, gcj exists...)
Would ya'll please stop misusing this? Semantics are about content, syntax about presentation. Semantic differences are important (though the degree is variable,) syntactic ones are essentially not.
Pedantic note: collision of matter and antimatter does not produce a net nothingness; it should produce massive amounts of radiation. Conservation of mass and energy still applies.
Well, it's easy enough to build up a database of SHA1 hashes for kiddie porn and such.
... which will quickly be defeated by "nearly-the-same" images, the result of a tool that modifies all images on a drive, changing them in visibly imperceptible (or at least unobtrusive) ways, but leaving the files with radically different hashes -- without even having a copy of the list of hashes the authorities already have.
As for Firebird, it fared better in terms of ease of setup than PostgreSQL (early on, the gap was huge!), and in terms of platform support (Windows support is not new, for example.) But its security model made it difficult to run on a shared host; you couldn't easily grant a user the right to create his own private database, which required admin privs, without granting him access to other private databases; also, the usernames were visible and unique across the whole set of databases, and you didn't really want your customers seeing each others' usernames, even if you couldn't use that to hack into anything. There are ways around that, but for shared server situations, it's a hurdle.
Both were lightyears ahead of MySQL in terms of features and stability and developer friendliness (I won't go into speed benchmarks, as that's not my primary concern in a database engine), but as others point out, that's not always what determines a market. I remember quite a few Linux install CD's that came with MySQL prepackaged -- nobody else, just MySQL. So of course people would try that out, and then just stay with it out of sheer laziness or ignorance, or a little later, out of concern for application integration, now that several of your favorite apps all support MySQL (for their own, similar, reasons) and nothing else. And then you've got a form of lock-in, only it's with open-source. It's not so much about what you can do, as what's convenient to do.
There are no real checks and balances in a free market. I believe some would argue that the free market, as a whole, is a set of checks and balances. But I don't think I was intending to drag us into a discussion of the economic free market (I'm much more of a social libertarian than an economic one, but in all things even more concerned with consent than ideology;) the point was that the economic free market (whatever its many problems) still provides more of an "out" than the political market does today. Perhaps the belief that one needs regulation should lead to believing that the other should too, but what does that mean? Some international movement to restrict a state's ability to oppress minorities? A forced redistribution of land among existing or new political entities? (We've had something like that, but not for that purpose, when splitting up countries, particularly in the near east.)
It reminds me of the manner in which the debate over states' rights is handled in the US: if someone thinks they can impose a law across the country, they'll go for it; if it looks like their opponent might succeed, they'll claim it should be a state-level measure and fight it state-by-state. Our approach to jurisdiction is greedy, rather than consensual. That which you gain by force, you hardly agree to give up by choice.
By inherent oppression in any free market system, for those without money, do you mean "those without resources lack the capital with which to create new products (which they could then not afford to buy)"? Or do you mean "a free market leaves no non-violent means for the destitute to acquire resources"? But even the poorest of the poor generally still have services they can render -- although we like to make some of those services illegal (another topic entirely.) Just because the two systems share some traits, and we argue about both systems using similar arguments, doesn't mean the two are equated; freedom and prosperity are still separate concerns, with their own niche problems. Furthermore, the presence of corner cases in politics differs from corner cases in hard sciences. We do not repeal free speech because some free speech is intolerable; we just create exceptions for those situations. The poor, we deal with in a special way -- a financial safety net. What about the minority? We're still figuring that one out. The courts aren't entirely sure if that's their job or not.
My comment had nothing to do with getting land for free. Nor civilization for free. Nor about pristine areas. I merely like to point out that all "go elsewhere if you don't like it" positions fail to admit that there's not always somewhere else to go, which reveals the oppression built into the argument. No other country is required to accept you. Noone is required to sell you land, so you have somewhere to move to. Noone is required to buy your land, helping you get out of where you are. If you are born into a country, make a living there, buy land there, and some day discover that your neighbors, by a majority vote, have made your place of residence a hell-hole by their ineptitude, you are, through no fault of your own, screwed. You and your 49% of brethren are left with no method of non-violently reorganizing yourself away from the crazies. We have not devised a true free market for governments, by which we can acquire or create the governments we want and can afford. Democracy is better than tyranny, but I think we could take the concepts of freedom and free market a little further. Where's the long tail when you need it?
To be more exact: god may be a good fit for what we observe, but not a useful fit. You can always adjust religion to fit new facts (and even make the adjustment an expected part of the religion) so you don't have any unexplained bits dangling about, but that says nothing about the predictive nature of the explanation. Science isn't about explaining history, it just happens to use history and therefore also explains it -- it's about usefully predicting the future, for our own betterment. In the end, science really only cares about showing that the planets move in a precisely predictable manner, not about proving that it is or isn't God doing it: nobody cares. And really, that's not a "how" so much as a very, very precise "what". What's going on out there, exactly? What can we use it for?
Where's all this unclaimed land you speak of? Even Antarctica got sliced up like a huge frozen pie! Now, if you mean areas where no governmental (is that the same as civilization?) control is truly enforced, that's a different matter. (Somalia?)
Have you read Catch 22? I like how you've taken what some would consider a symptom of insanity -- the desire to commit suicide -- and turned it into a proof of insanity: the idea that all who commit suicide are obviously, by the very act, insane. My free will ends where your sympathy and imagination end? Hell no.
We are more than logical thinking machines; all of our decisions, even the ones we think most obvious and logical, are filtered through a squishy chemical mess of a thing we call a brain. When we second-guess someone's decision, we need to realize we don't have all the information: we don't have a copy of all those emotions, those chemical biases, those secondary concerns and stresses and memories and expectations and beliefs and habits and lessons-learned. All you can say is "I would not make that choice for myself, where I am today." Well, good for you. But I doubt he wants your pity, your judgment, or your diagnosis.
As to those whining about how suicides hurt family members -- yeah. So does any sudden death. Or a slow death, for that matter. So does your decision not to take out the trash when you should. So does your obsession with playing Magic the Gathering. So does your inability to comprehend your teen daughter's lesbian tendencies. So does the fact that you like to think there's an extra 2 gallons at the end of your gas tank that mysteriously never comes to the rescue in the middle of nowhere.
We are constantly affecting the ones we love, all the time, in everything we do -- but that doesn't mean that it's their decision to make, whether we should live or die. The last thing someone needs in a situation like this is to be told that, on top of everything that's already built up to cause them to feel this is necessary, oh, by the way, you're also hurting your family, and you're a bad person for it.
You want to know what's really selfish and immature? That kind of whining. Complaining that someone killed themselves, and hurt you in so doing. Boo-f'ing-hoo. You want pain? You want suffering? Try figuring out what caused them to kill themselves, and see what you could have done to prevent it. Those suffering from depression need love, not bitching and moaning. Go give someone a big hug.
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 3, Informative
From what I've seen (not used it) the new Windows PowerShell (Monad) is designed around "piping" data between apps that actually exchange.Net objects, including lists, maps, etc. of objects -- rather than character streams. There seem to be generic commands that provide sql-like "select / where" filtering clauses, etc., too. You might explore that, see if it fits your needs. It looks awfully verbose to me though, I'd have to find a way to set aliases for most everything. Just a thought.
Why would we burn Earth oil to get Titan oil? We go there, we set up the required refineries, we transform the oil locally, and we use it to extract more of itself. Sure, we'll waste 90% of the oil there on extraction and transmission, but in the end, you still get a trickle of oil coming from Titan, which is more than it currently provides, which makes it oil-positive. You have the initial investment cost of getting equipment there, but that's what you should weigh it against -- not in proportion to itself. If it costs less to send equipment than you will eventually get out of mining Titan, it's worth it, even if it only nets you 10% of the resources that exist there.
Ah, I see what you mean, though it's more specific than that; what we'd like to say is: - if the changes you're trying to commit conflict with changes already prepared elsewhere, you must fail; - if the changes you're trying to commit rely on changes that have been prepared but not commited, you must still fail.
Therefore, the rule is that deferred constraints checked during PREPARE must succeed: - within the context of your transaction, plus all committed transactions (that is, even if the other prepared transaction rolls back, yours can still succeed, standing on its own), and - within the context of your transaction, plus all committed transactions, plus all prepared transaction (that is, if you all commit, the sum of your changes is still valid)
I believe that satisfies both of our requirements.
Thanks for talking through this, it's been constructive (at least for me). Good luck with getting the range constraint implemented, sounds useful. Spatial indexing is certainly an area FB falls behind PG on.
I think I disagree on 'rollback prepared'; PREPARE signals intent to COMMIT, and a successful PREPARE is a promise that nothing will impede a later COMMIT. It's a right-of-way issue; whoever PREPAREs first wins the game of "chicken", all other transactions will be forced to yield if database constraints can't be verified for them. Someone has to give, and it won't be whoever has already PREPAREd. It's similar to a lock -- just because someone rolls back a transaction that was holding a lock doesn't mean they're "wrong" for having held the lock in the first place and prevented you from performing your activity, it's just a natural part of the system. The worst case scenario is that another transaction attempts to commit, gets stuck in limbo, you can't commit because between the two of you, if you both succeeded, database constraints would be violated, so you're not allowed to commit; they later rollback from limbo, and assuming you're still around, you can now commit (they're no longer prepared, so the constraints won't have a problem with what you're doing, at least not because of the other guy.) That's not so bad, I think.
Yes, guessing what constraints need to be checked is certainly a problem; the way I'm using Firebird's on-commit trigger is specifically that: I create my own (carefully-crafted) list of things to check, and the trigger runs procedures to go through and verify all those items. I still have to do all of that work, but I have an opportunity to do so. Providing the ability for those constraints to see across transaction boundaries would mean it could be even more correct than it is; the changes made by other prepared/committed transactions no longer need to be verified, as their on-commit triggers have already succeeded, I only need to check my own, but I can now see both my modified data and everybody else's just for a moment, right before I commit. It doesn't require the database to be any smarter about constraints and what can cause them to fail; so long as you have the ability to run read-only code with visibility locally to all prepared/committed data, as part of the PREPARE action (and therefore no other transactions can PREPARE while this code is running), where it can raise an exception if anything's wrong... I think you're good to go. It'll still be a pain to setup temporary tables, lists of things to check, etc. but at least it'd be doable. And if nothing else, it could reverify "everything" (no list of things to check, just run a query joining between tables, looking for anything wrong). Not necessarily the most efficient method, but I'm only worrying about correctness today.
Are you free to elaborate on your overlap constraint implementation? Even finding overlaps isn't a terribly efficient operation, unless you're also using a form of spatial indexing on your custom datatype (date ranges are just 1-d "boxes", and can be treated as rectangles in a euclidean space, thus k-d trees and other such indexing methods should be helpful.)
You realize that you can't allow concurrent inserts if you have a check like that, right? Sadly, very much so, yes. Currently the only constraints that can be verified across transaction boundaries (that is, the constraint can "see" more than the transaction itself can) are primary, unique, and foreign key constraints, and that's mostly thanks to voodoo in the indexing components of the database system. At the risk of being proven wrong again-ish (and this would be a good thing!) I know of no RDBMS that allows you to write arbitrary (check) constraints that are verified at commit time, but against both your transaction and any prepared-or-committed transactions nearby, ensuring that at the end of the day, when everyone's committed what they're going to commit, the database is in a safe state.
(Debate: should we want it to allow transactions to commit when they can't tell, from looking just at the data visible to them, primarily when running in serializable mode, that everything is going to be okay when they commit? This would allow you to insert a row referencing another row, which is being inserted by another transaction, so long as the other one commits [prepare is sufficient] first; should constraints require that both the transaction itself, and the database as a whole, both validate?)
Until we get that feature (what a day!), all such complex constraints are going to involve some locking, or else suffer from local-to-transaction-only constraints which can be violated by any two transactions working in tandem, ill-intended or not.
The main risk I see in implementing such a feature would be that the check constraints could be malicious, doing more than just preventing the transaction from committing -- such as reveleaing data from another transaction (not so bad -- if you've written a work-around for serializable mode, it's your own fault) or modifying data (should be preventable, given other areas where this is necessary.)
Maybe that's still in our short-term future. But given how easily people give up on writing good, correct constraints, there doesn't seem to be much push in the database community for even more constraints -- they'd rather be writing the stored procedures and views that get the business people off their backs, and just trust that their code, fate, etc. align to keep the database sane. It seems much cheaper.
Thanks for the link, I hadn't seen those. (I did specify "that I know of", right?)
Looking at the docs, yes, they could be used for some of the same things as on-commit triggers, in the case of enforcing constraints. You could probably hack them into doing what you needed for on-commit triggers in the general sense, so long as you can find a table somewhere that will always be touched during the session. (Firebird has an on-start-transaction trigger as well, which could help with that, but we're talking about PG -- so I don't know what you'd do to ensure that.)
In the case of verifying a relationship like "every master row must have between 5 and 7 child rows", either system would require you to jump through a few hoops, but it looks entirely doable: (I haven't seen an example yet of an Oracle deferred CHECK constraint with the ability to run a sub-select against another table, only ever simple foreign keys, but maybe that works as well?)
Firebird: create a global temporary table of master rows (just PK's) that need to be checked; triggers on master and child tables both put the master's PK into the table; a procedure exists which can check the master and remove it from the list if all is well; an on-commit trigger runs the procedure for each row in the temporary table (this lets you force the constraint to be checked whenever you like, explicitly, by calling the procedure when you're ready.)
Postgres: you could put the deferred-trigger-constraint on the master table, ensure that all changes to a child 'update' (no-op, such as PK=PK) the parent; I'm not sure how you would go about forcing a check early though, if you needed it.
(I'm thinking of migration triggers I've written where I have such a constraint that I can check often, but not immediately; I'd still prefer to check it as soon as possible and throw an exception early, rather than wait until the entire batch import finishes, possibly far later, and with less opportunity for debugging.)
I'm also using on-commit triggers for a form of lazy-evaluation (not exactly constraint-checking); variables are marked as 'invalid', and recalculated as needed (not immediately, to prevent recalculating the same one multiple times), but I want them recalculated by the end of the transaction, too. Looks like I'd have to rethink that process entirely with PG, unless maybe a constraint-trigger is also allowed to modify data, thus "making" it valid, effectively? Again, if you can make sure there's always at least a one column table somewhere you can slap a constraint trigger on, I suppose you could use them that way.
As to Oracle, I've seen some people try to use triggers on materialized views to perform on-commit operations, but as I recall that's not foolproof.
Slashdot Mirror
Yes, we need to know what the effects of our actions will be, if we're going to apply our effort in the best possible way, without undesirable side-effects. Yes, knowing what the effects of our actions will be would tend to require that we understand the system sufficiently to know what the causes of present effects could be; however, that's not entirely required.
We don't require that doctors know who the masked gunman was when we ask them to save the patient; their trade gives them insight into possible solutions to the problem at hand without having a full grasp on the circumstances of the trauma. Furthermore, radical intervention is more and more warranted as the risks involved in non-action increase; if your patient is dying anyway, you're willing to try just about anything, despite the decreasing chances of success and increasing chances of side-effects.
The people pushing for any action are serving a useful purpose in the end; they give the nay-sayers a reason (fear) to push for more research to make sure the right sort of change happens, for the right reasons. Without them, it's not just change that would be less likely, it's research, too.
I know this wasn't your point, so don't take this the wrong way; your comment about aether reminded me of a talk I heard once about evolution, given at a church (!); to paraphrase one particularly fun segment: "science changes its mind all the time, so it's essentially always wrong; you should instead rely on the Bible, which never changes its mind." It's wrong on so many levels, I needn't go into it directly; I should however point out that the talk was given by someone who styled himself a scientist, collected dinosaur bones, and was asking for money from the church so he could go buy more dinosaur bones, so he could put them in a museum display intended to prove that evolution (and history in general) never actually happened.
Analyzing data is hard. Asking the right questions, with the right assumptions, arriving at the right conclusions, and communication all of this clearly and fully to anyone else ... is hard. And even then, we still get it wrong, at least for a while. Cherish your differences!
Don't assume that counter-data is a counter-argument: in mathematics, finding an exception to the rule is a sure sign that something's wrong; in applied sciences, it's only an exception to the rule if you meet all sorts of criteria about the circumstances of the event. Saying "CO2 has risen before" is not the same as saying any of:
a) it is not rising right now
b) this event has the same cause has previous events
c) this event will have the same effects
d) same effects at different points in time are equivalent
I'm pretty sure that was meant as an example only. The point being that GroupThink can hold us back. One of the arguments for capitalism is that you have N people all trying to find the best way to solve a problem, being rewarded when they do -- we're betting that it's more efficient in the long run to waste resources in the short term exploring different options and seeing which ones survive. When you see a whole group of players "give up" in a sense, and use the existing solution, you've got to be worried that there was some innovation there that just won't happen anytime soon now -- and if the idea is instilled that you should always go with the short-term efficiency of using off-the-shelf solutions, then you've got a long-term problem to deal with: entire generations raised to go with COTS rather than innovating. The bet here is that in the long term, it's more profitable to at least have some trained R&D people than an entire population of "users", dependent on others, and you can't have that without sometimes saying "no" to the salespeople.
I have yet to meet anybody that said their new web-based app whipped the llama's azz compared to the old thin-client or mainframe app
Unsurprising. Even with AJAX techniques to avoid refreshing the page fully, and even using JSON (maybe gzip'ed) instead of XML to reduce the traffic, and even with HTTP keep-alive to reduce the connection times, the technology used in web-apps today is still more "expensive" in terms of performance/latency than the older client/server methods. You build a 2-tier Win32 client with a direct connection to the database, and you've got a pure binary stream, composed of useful data and little else (vs. verbose XML, particularly); you don't have extra layers of webservers, you don't have a connection that starts/stops constantly, etc. You have the ability for the server to notify the client that something has changed, whereas with web-apps, you at best have something like Comet, and more likely have some sort of polling AJAX call. And the client's probably compiled, running natively, using hWnd's and whatnot; with web-apps, you may have the wonder that is javascript performing DOM updates that have to be interpreted and re-rendered by a multipurpose browser.
Of course it's less efficient. But as others have pointed out, that's not always the point. It's about control, it's about standardization, and ... oh, right, it's about control.
... and stuff like wxWidgets, too. Multiple languages, multiple platforms, looks and acts like the running environment. No VM required. (Yes, I know, gcj exists ...)
[posting to cancel accidental moderation]
Would ya'll please stop misusing this? Semantics are about content, syntax about presentation. Semantic differences are important (though the degree is variable,) syntactic ones are essentially not.
Pedantic note: collision of matter and antimatter does not produce a net nothingness; it should produce massive amounts of radiation. Conservation of mass and energy still applies.
For more on the monopoly status of USPS, please see http://en.wikipedia.org/wiki/American_Letter_Mail_Company set up by Lysander Spooner.
Well, it's easy enough to build up a database of SHA1 hashes for kiddie porn and such.
As for Firebird, it fared better in terms of ease of setup than PostgreSQL (early on, the gap was huge!), and in terms of platform support (Windows support is not new, for example.) But its security model made it difficult to run on a shared host; you couldn't easily grant a user the right to create his own private database, which required admin privs, without granting him access to other private databases; also, the usernames were visible and unique across the whole set of databases, and you didn't really want your customers seeing each others' usernames, even if you couldn't use that to hack into anything. There are ways around that, but for shared server situations, it's a hurdle.
Both were lightyears ahead of MySQL in terms of features and stability and developer friendliness (I won't go into speed benchmarks, as that's not my primary concern in a database engine), but as others point out, that's not always what determines a market. I remember quite a few Linux install CD's that came with MySQL prepackaged -- nobody else, just MySQL. So of course people would try that out, and then just stay with it out of sheer laziness or ignorance, or a little later, out of concern for application integration, now that several of your favorite apps all support MySQL (for their own, similar, reasons) and nothing else. And then you've got a form of lock-in, only it's with open-source. It's not so much about what you can do, as what's convenient to do.
Driving within the speed limits saves on gas too. /. discussion: Fuel efficiency and slow driving?
Please see previous
There are no real checks and balances in a free market. I believe some would argue that the free market, as a whole, is a set of checks and balances. But I don't think I was intending to drag us into a discussion of the economic free market (I'm much more of a social libertarian than an economic one, but in all things even more concerned with consent than ideology;) the point was that the economic free market (whatever its many problems) still provides more of an "out" than the political market does today. Perhaps the belief that one needs regulation should lead to believing that the other should too, but what does that mean? Some international movement to restrict a state's ability to oppress minorities? A forced redistribution of land among existing or new political entities? (We've had something like that, but not for that purpose, when splitting up countries, particularly in the near east.)
It reminds me of the manner in which the debate over states' rights is handled in the US: if someone thinks they can impose a law across the country, they'll go for it; if it looks like their opponent might succeed, they'll claim it should be a state-level measure and fight it state-by-state. Our approach to jurisdiction is greedy, rather than consensual. That which you gain by force, you hardly agree to give up by choice.
By inherent oppression in any free market system, for those without money, do you mean "those without resources lack the capital with which to create new products (which they could then not afford to buy)"? Or do you mean "a free market leaves no non-violent means for the destitute to acquire resources"? But even the poorest of the poor generally still have services they can render -- although we like to make some of those services illegal (another topic entirely.) Just because the two systems share some traits, and we argue about both systems using similar arguments, doesn't mean the two are equated; freedom and prosperity are still separate concerns, with their own niche problems. Furthermore, the presence of corner cases in politics differs from corner cases in hard sciences. We do not repeal free speech because some free speech is intolerable; we just create exceptions for those situations. The poor, we deal with in a special way -- a financial safety net. What about the minority? We're still figuring that one out. The courts aren't entirely sure if that's their job or not.
My comment had nothing to do with getting land for free. Nor civilization for free. Nor about pristine areas. I merely like to point out that all "go elsewhere if you don't like it" positions fail to admit that there's not always somewhere else to go, which reveals the oppression built into the argument. No other country is required to accept you. Noone is required to sell you land, so you have somewhere to move to. Noone is required to buy your land, helping you get out of where you are. If you are born into a country, make a living there, buy land there, and some day discover that your neighbors, by a majority vote, have made your place of residence a hell-hole by their ineptitude, you are, through no fault of your own, screwed. You and your 49% of brethren are left with no method of non-violently reorganizing yourself away from the crazies. We have not devised a true free market for governments, by which we can acquire or create the governments we want and can afford. Democracy is better than tyranny, but I think we could take the concepts of freedom and free market a little further. Where's the long tail when you need it?
To be more exact: god may be a good fit for what we observe, but not a useful fit. You can always adjust religion to fit new facts (and even make the adjustment an expected part of the religion) so you don't have any unexplained bits dangling about, but that says nothing about the predictive nature of the explanation. Science isn't about explaining history, it just happens to use history and therefore also explains it -- it's about usefully predicting the future, for our own betterment. In the end, science really only cares about showing that the planets move in a precisely predictable manner, not about proving that it is or isn't God doing it: nobody cares. And really, that's not a "how" so much as a very, very precise "what". What's going on out there, exactly? What can we use it for?
Tintin, too!
Where's all this unclaimed land you speak of? Even Antarctica got sliced up like a huge frozen pie! Now, if you mean areas where no governmental (is that the same as civilization?) control is truly enforced, that's a different matter. (Somalia?)
Have you read Catch 22? I like how you've taken what some would consider a symptom of insanity -- the desire to commit suicide -- and turned it into a proof of insanity: the idea that all who commit suicide are obviously, by the very act, insane. My free will ends where your sympathy and imagination end? Hell no.
We are more than logical thinking machines; all of our decisions, even the ones we think most obvious and logical, are filtered through a squishy chemical mess of a thing we call a brain. When we second-guess someone's decision, we need to realize we don't have all the information: we don't have a copy of all those emotions, those chemical biases, those secondary concerns and stresses and memories and expectations and beliefs and habits and lessons-learned. All you can say is "I would not make that choice for myself, where I am today." Well, good for you. But I doubt he wants your pity, your judgment, or your diagnosis.
As to those whining about how suicides hurt family members -- yeah. So does any sudden death. Or a slow death, for that matter. So does your decision not to take out the trash when you should. So does your obsession with playing Magic the Gathering. So does your inability to comprehend your teen daughter's lesbian tendencies. So does the fact that you like to think there's an extra 2 gallons at the end of your gas tank that mysteriously never comes to the rescue in the middle of nowhere.
We are constantly affecting the ones we love, all the time, in everything we do -- but that doesn't mean that it's their decision to make, whether we should live or die. The last thing someone needs in a situation like this is to be told that, on top of everything that's already built up to cause them to feel this is necessary, oh, by the way, you're also hurting your family, and you're a bad person for it.
You want to know what's really selfish and immature? That kind of whining. Complaining that someone killed themselves, and hurt you in so doing. Boo-f'ing-hoo. You want pain? You want suffering? Try figuring out what caused them to kill themselves, and see what you could have done to prevent it. Those suffering from depression need love, not bitching and moaning. Go give someone a big hug.
From what I've seen (not used it) the new Windows PowerShell (Monad) is designed around "piping" data between apps that actually exchange .Net objects, including lists, maps, etc. of objects -- rather than character streams. There seem to be generic commands that provide sql-like "select / where" filtering clauses, etc., too. You might explore that, see if it fits your needs. It looks awfully verbose to me though, I'd have to find a way to set aliases for most everything. Just a thought.
Why would we burn Earth oil to get Titan oil? We go there, we set up the required refineries, we transform the oil locally, and we use it to extract more of itself. Sure, we'll waste 90% of the oil there on extraction and transmission, but in the end, you still get a trickle of oil coming from Titan, which is more than it currently provides, which makes it oil-positive. You have the initial investment cost of getting equipment there, but that's what you should weigh it against -- not in proportion to itself. If it costs less to send equipment than you will eventually get out of mining Titan, it's worth it, even if it only nets you 10% of the resources that exist there.
Ah, I see what you mean, though it's more specific than that; what we'd like to say is:
- if the changes you're trying to commit conflict with changes already prepared elsewhere, you must fail;
- if the changes you're trying to commit rely on changes that have been prepared but not commited, you must still fail.
Therefore, the rule is that deferred constraints checked during PREPARE must succeed:
- within the context of your transaction, plus all committed transactions (that is, even if the other prepared transaction rolls back, yours can still succeed, standing on its own), and
- within the context of your transaction, plus all committed transactions, plus all prepared transaction (that is, if you all commit, the sum of your changes is still valid)
I believe that satisfies both of our requirements.
Thanks for talking through this, it's been constructive (at least for me). Good luck with getting the range constraint implemented, sounds useful. Spatial indexing is certainly an area FB falls behind PG on.
I think I disagree on 'rollback prepared'; PREPARE signals intent to COMMIT, and a successful PREPARE is a promise that nothing will impede a later COMMIT. It's a right-of-way issue; whoever PREPAREs first wins the game of "chicken", all other transactions will be forced to yield if database constraints can't be verified for them. Someone has to give, and it won't be whoever has already PREPAREd. It's similar to a lock -- just because someone rolls back a transaction that was holding a lock doesn't mean they're "wrong" for having held the lock in the first place and prevented you from performing your activity, it's just a natural part of the system. The worst case scenario is that another transaction attempts to commit, gets stuck in limbo, you can't commit because between the two of you, if you both succeeded, database constraints would be violated, so you're not allowed to commit; they later rollback from limbo, and assuming you're still around, you can now commit (they're no longer prepared, so the constraints won't have a problem with what you're doing, at least not because of the other guy.) That's not so bad, I think.
Yes, guessing what constraints need to be checked is certainly a problem; the way I'm using Firebird's on-commit trigger is specifically that: I create my own (carefully-crafted) list of things to check, and the trigger runs procedures to go through and verify all those items. I still have to do all of that work, but I have an opportunity to do so. Providing the ability for those constraints to see across transaction boundaries would mean it could be even more correct than it is; the changes made by other prepared/committed transactions no longer need to be verified, as their on-commit triggers have already succeeded, I only need to check my own, but I can now see both my modified data and everybody else's just for a moment, right before I commit. It doesn't require the database to be any smarter about constraints and what can cause them to fail; so long as you have the ability to run read-only code with visibility locally to all prepared/committed data, as part of the PREPARE action (and therefore no other transactions can PREPARE while this code is running), where it can raise an exception if anything's wrong ... I think you're good to go. It'll still be a pain to setup temporary tables, lists of things to check, etc. but at least it'd be doable. And if nothing else, it could reverify "everything" (no list of things to check, just run a query joining between tables, looking for anything wrong). Not necessarily the most efficient method, but I'm only worrying about correctness today.
Are you free to elaborate on your overlap constraint implementation? Even finding overlaps isn't a terribly efficient operation, unless you're also using a form of spatial indexing on your custom datatype (date ranges are just 1-d "boxes", and can be treated as rectangles in a euclidean space, thus k-d trees and other such indexing methods should be helpful.)
You realize that you can't allow concurrent inserts if you have a check like that, right?
Sadly, very much so, yes. Currently the only constraints that can be verified across transaction boundaries (that is, the constraint can "see" more than the transaction itself can) are primary, unique, and foreign key constraints, and that's mostly thanks to voodoo in the indexing components of the database system. At the risk of being proven wrong again-ish (and this would be a good thing!) I know of no RDBMS that allows you to write arbitrary (check) constraints that are verified at commit time, but against both your transaction and any prepared-or-committed transactions nearby, ensuring that at the end of the day, when everyone's committed what they're going to commit, the database is in a safe state.
(Debate: should we want it to allow transactions to commit when they can't tell, from looking just at the data visible to them, primarily when running in serializable mode, that everything is going to be okay when they commit? This would allow you to insert a row referencing another row, which is being inserted by another transaction, so long as the other one commits [prepare is sufficient] first; should constraints require that both the transaction itself, and the database as a whole, both validate?)
Until we get that feature (what a day!), all such complex constraints are going to involve some locking, or else suffer from local-to-transaction-only constraints which can be violated by any two transactions working in tandem, ill-intended or not.
The main risk I see in implementing such a feature would be that the check constraints could be malicious, doing more than just preventing the transaction from committing -- such as reveleaing data from another transaction (not so bad -- if you've written a work-around for serializable mode, it's your own fault) or modifying data (should be preventable, given other areas where this is necessary.)
Maybe that's still in our short-term future. But given how easily people give up on writing good, correct constraints, there doesn't seem to be much push in the database community for even more constraints -- they'd rather be writing the stored procedures and views that get the business people off their backs, and just trust that their code, fate, etc. align to keep the database sane. It seems much cheaper.
Thanks for the link, I hadn't seen those. (I did specify "that I know of", right?)
Looking at the docs, yes, they could be used for some of the same things as on-commit triggers, in the case of enforcing constraints. You could probably hack them into doing what you needed for on-commit triggers in the general sense, so long as you can find a table somewhere that will always be touched during the session. (Firebird has an on-start-transaction trigger as well, which could help with that, but we're talking about PG -- so I don't know what you'd do to ensure that.)
In the case of verifying a relationship like "every master row must have between 5 and 7 child rows", either system would require you to jump through a few hoops, but it looks entirely doable: (I haven't seen an example yet of an Oracle deferred CHECK constraint with the ability to run a sub-select against another table, only ever simple foreign keys, but maybe that works as well?)
Firebird: create a global temporary table of master rows (just PK's) that need to be checked; triggers on master and child tables both put the master's PK into the table; a procedure exists which can check the master and remove it from the list if all is well; an on-commit trigger runs the procedure for each row in the temporary table (this lets you force the constraint to be checked whenever you like, explicitly, by calling the procedure when you're ready.)
Postgres: you could put the deferred-trigger-constraint on the master table, ensure that all changes to a child 'update' (no-op, such as PK=PK) the parent; I'm not sure how you would go about forcing a check early though, if you needed it.
(I'm thinking of migration triggers I've written where I have such a constraint that I can check often, but not immediately; I'd still prefer to check it as soon as possible and throw an exception early, rather than wait until the entire batch import finishes, possibly far later, and with less opportunity for debugging.)
I'm also using on-commit triggers for a form of lazy-evaluation (not exactly constraint-checking); variables are marked as 'invalid', and recalculated as needed (not immediately, to prevent recalculating the same one multiple times), but I want them recalculated by the end of the transaction, too. Looks like I'd have to rethink that process entirely with PG, unless maybe a constraint-trigger is also allowed to modify data, thus "making" it valid, effectively? Again, if you can make sure there's always at least a one column table somewhere you can slap a constraint trigger on, I suppose you could use them that way.
As to Oracle, I've seen some people try to use triggers on materialized views to perform on-commit operations, but as I recall that's not foolproof.