and Microsoft Windows has its own way of providing finer rights to its resources, Linux had to put up with the simple but crude user rights known in tech speak as discretionary access control to control user access of files.
A small point, but the access control in Windows is also called "discretionary". They are different models, but they are both discretionary.
One way of thinking about this is that mandatory means "access controlled by a mandatory policy" and discretionary means "access controlled at the discretion of an owner".
Ahhh.. I remember dbase. I used foxpro and dbase tables a bit myself, but ended up having to use Borland's Paradox for most desktop database applications. I didn't get into client-server until much later. Paradox was a bit sucky, I have to say.
It would be interesting to dig them all out again and run them in an emulator or something. I remember there was this whole thing about database 4GLs at the time.
Having re-read, I'm still not sure where we disagree! Are you saying that even if the application wasn't interfacing with an RDBMS, a relational model would be better than taking an OO approach? You do specifically refer to RDBMSs earlier, so that's where I got the database from.
Do you have any examples of a system that doesn't interface with a database but that could still be considered relational in some sense? I don't know any coding systems that are relational outside of databases. Or are you saying that just using structured programming would be better than OO in most cases? Or that anything would be better than OO?!
It's true that you can build appallingly horrible structures in OO, but you can build appalling models using a relational approach too - I've seen lots of examples of both myself. Anyway, as I said, I like both - we'll just have to disagree about which is the one model to rule them all!
I meant that the real world is chaotic, and if you drew lines between concepts we encounter in the real world, you will generally get a bunch of pointers/arrows, Go-To like.
Good points. Although the lack of constraint imposed by goto makes it more of a modeling mechanism than a useful model in its own right, IMHO.
Nested blocks don't reflect the real world, they are just human work aids.
I agree they don't reflect the real world, but wouldn't you agree that the ability to group things that do common tasks and give them names can help in modeling? Local state also provides encapsulation that limits the temptation to use global variables, so it also improves code stability.
I still disagree. Non-trivial OO tends to build data structures built out of objects (OO "composition" for example). These data structures tend to mirror the RDBMS more or less, or at least compete with it.
I think I see where we disagree. You're talking about cases where OO is specifically used to interface with a database oriented application. I agree that OO doesn't fit the relational world very well at all. I still shudder when I remember how much effort it was to create an OO-relational mapping layer for a non-trivial database application back in 2001. So I think I know what you mean here.
The thing about OO is, there are applications and services that don't interface with databases, and wouldn't benefit from doing so. Things where the world really does consist of directed object graphs - then OO really shines, and the relational world struggles.
I believe OO is a subjective preference. It does not work smooth for me. If you can show *objective* evidence it is better, I am all ears/eyes. If you like it personally, fine. Enjoy it. To each their own.
Fair enough - we all have our likes and dislikes, and we all work on different things. I actually like both, but for different things.
I've also never seen a good argument that it models the real world - I've heard some hard-core OO people try to argue that, but I don't agree. By the way, I didn't say it models the entire real world better, just some domains. It's certainly good at modeling some things I've worked on better than structured programming. There are cases where encapsulation and polymorphism is useful! However, the mere fact of aspect-oriented programming shows that there are still plenty of cases where it falls down in trying to model things naturally. Most things don't really naturally fit into a simple hierarchy.
I have to say, I can't see how gotos model anything much at all outside of the programming language itself - they're just jumps to another code location, but I'm prepared to learn, if you can show me what they are good at modeling. Structured blocks can at least be used to model things outside of itself - although it certainly doesn't insist that they do.
I completely agree with you that the mismatch between relational and pretty much any other form of coding - not just OO - causes headaches. It's a mistake to pin that only on OO though, IMHO, although OO does seem to have a particularly rough time with it.
By the way, I've been working heavily with relational databases for about 15 years, and I've just completed a masters dissertation which is mostly about certain practical applications of set theory. It doesn't change the way I think of OO - they are just different models - give it another go!
I would say that almost any formalism that moves the semantic intention of the code closer to the domain it models more maintainable. So in this sense, the move to OO programming is definitely comparable to the move to structured programming. This has nothing to do with whether a database is involved or not.
However, you do raise an important point, in that we have different models for data and code, and thus there is an "impedance mismatch" between them. In this sense, combining OOP and relational is difficult and ends up creating all sorts of complicated artifacts that detract from the intention of the code.
It's not that OOP competes with a database, any more than aspect oriented programming competes with structured programming, or functional programming competes with declarative programming. They are simply different models, that offer their own advantages and disadvantages. Code that has to address more than one model will always introduce artificial and difficult constructs, unless they have some kind of essential compatibility between the models.
I agree that the population simply giving away their power is not a reasonable act, but it happens all the time. It's not so much that fighting abuse of power is a route to maturation, more that the taking of power is a route to infantilization. I guess they go together, and the cycle continues...
When a parent says to a child "It's for your own good", the child knows they won't like it, but probably trusts that it really is for their own good. When political leaders say the same, you also know you won't like it, but you should distrust their motives - it's often, but not always, a way to take more power. When a leader tells you to give up hard-won freedoms for your own good, you know just what it is. Unfortunately, many people are quite happy to go along with it, after being appropriately scared by ghost stories.
Of course, not all power is overtly taken, power also condenses in subtler ways - through inherited wealth, better connections, education, prestigious credentials, etc.
That's an interesting set of ideas. For a while in my youth, I played with the notion that the monarchy were a necessary evil, precisely because they were a powerful unifying symbol that elected "representatives" could not achieve. That is also their danger, of course.
The tendency of power in all societies to become entrenched now seems pretty inevitable to me. I think you're right that the US initially rallied around ideas of freedom and reacted against big government - much like the French revolution, etc. These things pass over time, and once again, power condenses.
The real question is what checks and balances can a system provide against abuse by those in power at any one time. The constitution of the US is a great example of this, as is the Magna Carta. Sadly, none of these are immune against corruption.
Very true. What's the phrase - evil will triumph if good men do nothing?
I think the most important thing is to ensure that the judicial system is separate from the executive. This is the biggest threat at the moment, IMHO. Guantanamo, extroadinary rendition, trial without jury, etc.
Specific laws can be changed, but if the system permits laws to be flouted by those in charge, we're all pretty well doomed. Viva la revolucion!
You make good points, but I do disagree with you. It's not so much that a decision is made not to test, it's just that most places and programmers do not have a culture of creating them. The decision, if a decision is made at all, is usually to unit test in the first place. Not testing is the default position.
I also disagree that test are primarily for finding bugs, and that regression tests diminish in usefulness as they are repeated. Tests do find bugs occasionally, which is nice, but mostly what they do is force the programmer to think about what is valid and what isn't in the code - if they're written along with the code rather than afterwards, that is.
Regression tests give confidence that you haven't broken the code as it changes. It's the repeatability that makes them valuable! If your regression tests never expose a bug introduced by new code, then your programmers are awesome!
Well... OK. But you seem to be saying that the legal rules are those things that powerful people try to get around, which I'd agree with.
If anything, the legal system has become increasingly powerful over the ages, to all our benefit. A great example is the separation of the executive from the judicial systems (which is being undermined in the US and the UK right now).
We might even be moving back to a less legal system (like that which operated in the days of Braveheart). So it doesn't make sense to attack the legal system - that's about the only protection we do have from these rapacious predators. We should be supporting it and strengthening it.
Errr... well, by my star, the fearful, racist and anonymous person I responded to. Of course, I did say asshole. Sorry if that offended you in any way.
In the "real world" you're right, unfortunately. However, you shouldn't discount it out of hand. The "real world" methodologies you use, like structured programming and object oriented programming were once regarded as ridiculous overheads - but the thing is, they actually reduce programming effort overall by making code more robust. I don't think I've used a GOTO in a long time.
Someone once said (can't remember who) that making a program was like piling 100 bricks on top of one another, but using OO programming was like dividing those bricks into 10 piles of 10. It's more stable, but at the cost of additional overhead in setting up those structures. Not only that, by forcing a more structured approach, many untested assumptions get flushed out by the design.
That's why the question posed by this topic is interesting. DbC offers another way to provide better semantics in the code - but it hasn't taken off. Maybe the benefits aren't generally worth it for your average code - I certainly can't speak from experience here.
Interesting, but I don't think it's anything to do with a love of monarchy per se, or the fact that at one point in history you all came from countries with a monarchy.
You're right that it's all to do with whipping up fear so the population can be more easily controlled - it's always been like that, monarchy or no monarchy. Our own monarchy aren't actually that powerful anymore, at least, not overtly. Hence why we refer to "President Blair".
Of course, unlike many of our recent leaders, your leaders are increasingly from a wealthy elite of families - the faces change but the families remain...
Ugggh.... I bow to your legal training based on watching "Braveheart". Especially that bit when the evil dude cut his wife's throat! How corrupt was that! And don't forget the law against taking goats across London Bridge - total evil, evil I tell you! We should all rise up against this corrupt system immediately. You first.
If we insist that a user must make all these choices, then you're absolutely right. There are some other ideas about. One is that applications only have an absolutely minimal set of privileges instead of having access to everything that the user can do. Profiles for common applications can be created and validated by security experts. Users don't have to do much at all, and applications can't do much by default.
No UAC, clueless users remain safe, and even if some malware ends up on their machine, it basically can't do anything. Check out http://www.hpl.hp.com/techreports/2004/HPL-2004-22 1.html for an example of a system like this that runs on XP - it's a bit of a hack, as XPs security model doesn't really permit this sort of thing, but it gives the general idea.
I can easily think of many ways in which a second search didn't actually find what I wanted, but gave a better quality of result in general. But you apparently can't. Right.
You missed two other options that might be useful to have:
4/ Whatever goes on your computer still requires privileges to execute. 5/ Whatever executes on your computer should not require all the privileges you have (e.g. delegate a small set of them to each process instead). Does this tetris game really need low level access to the disk driver? And a network connection? etc. etc.
Total unmitigated speculation. You can't explain something, so you invent something because it feels right to you - but you are just making it up, sunshine. Give me the evidence.
It's a model for long term gain, not short term profit. There are still some people and small companies following this model, but I agree they are dying out.
Market economics will quickly provide competition for short-term profit, but I suspect that markets don't innovate so well when the timescales are longer and the risks appear higher. The established market probably has to collapse in some way first, and some new bottom-up models emerge to fill the gap.
Sort of like an ecosystem that has ecological niches. You can't compete with the quick creatures that are already established if it takes you longer to get there, even if you would be bigger than them if you were allowed the chance.
Hashes aren't "more important" than ciphers. They're used for different things - apples and oranges.
"All hash algorithms will eventually be cracked". What do you mean by "cracked"? How broken does it need to be for it to be "cracked"? Enough that the US government could do it, that a crime ring could do it, that spotty teenages in their bedrooms can do it?
"On the other hand, a good cipher can potentially be technologically unbreakable". The only unbreakable cipher is the one-time pad. We already know that - and even those can be broken if they aren't used carefully. Other ciphers may be more or less resistant to attack than, say, a hash algorithm. More ciphers have been broken (in a practical, exploitable sense) than hash algorithms.
"once quantum computing comes along, today's strongest ciphers will amount to nothing". Not really. Only ciphers that depend on things that quantum computers can solve easily, such as the factorisation problem. So RSA would be useless, but elliptic curve cryptography might be fine. All the standard block ciphers like AES, 3DES and other wouldn't be affected at all, as they don't use the kind of maths that QCs are good at doing.
"for hash algorithms, this holy grail by definition doesn't exist, so researchers will only put enough time and effort to get to the next level of security when the previous level is threatened." There is no difference here between ciphers and hash algorithms (except that more ciphers have been broken than hash algorithms, so more work on ciphers has been done). Now it's time to do some work on hashes is all.
Almost. Banks don't lend money out of the hard cash they hold. In fact, depending on what the central banks allow, they can lend out, say, 10 times the amount of the "hard cash" they have on deposit. As you say, this creates money in the economy (most of which is paid back with interest through value generated elsewhere in the economy).
Slashdot Mirror
and Microsoft Windows has its own way of providing finer rights to its resources, Linux had to put up with the simple but crude user rights known in tech speak as discretionary access control to control user access of files.
A small point, but the access control in Windows is also called "discretionary". They are different models, but they are both discretionary.
One way of thinking about this is that mandatory means "access controlled by a mandatory policy" and discretionary means "access controlled at the discretion of an owner".
Ahhh.. I remember dbase. I used foxpro and dbase tables a bit myself, but ended up having to use Borland's Paradox for most desktop database applications. I didn't get into client-server until much later. Paradox was a bit sucky, I have to say.
It would be interesting to dig them all out again and run them in an emulator or something. I remember there was this whole thing about database 4GLs at the time.
Having re-read, I'm still not sure where we disagree! Are you saying that even if the application wasn't interfacing with an RDBMS, a relational model would be better than taking an OO approach? You do specifically refer to RDBMSs earlier, so that's where I got the database from.
Do you have any examples of a system that doesn't interface with a database but that could still be considered relational in some sense? I don't know any coding systems that are relational outside of databases. Or are you saying that just using structured programming would be better than OO in most cases? Or that anything would be better than OO?!
It's true that you can build appallingly horrible structures in OO, but you can build appalling models using a relational approach too - I've seen lots of examples of both myself. Anyway, as I said, I like both - we'll just have to disagree about which is the one model to rule them all!
I meant that the real world is chaotic, and if you drew lines between concepts we encounter in the real world, you will generally get a bunch of pointers/arrows, Go-To like.
Good points. Although the lack of constraint imposed by goto makes it more of a modeling mechanism than a useful model in its own right, IMHO.
Nested blocks don't reflect the real world, they are just human work aids.
I agree they don't reflect the real world, but wouldn't you agree that the ability to group things that do common tasks and give them names can help in modeling? Local state also provides encapsulation that limits the temptation to use global variables, so it also improves code stability.
I still disagree. Non-trivial OO tends to build data structures built out of objects (OO "composition" for example). These data structures tend to mirror the RDBMS more or less, or at least compete with it.
I think I see where we disagree. You're talking about cases where OO is specifically used to interface with a database oriented application. I agree that OO doesn't fit the relational world very well at all. I still shudder when I remember how much effort it was to create an OO-relational mapping layer for a non-trivial database application back in 2001. So I think I know what you mean here.
The thing about OO is, there are applications and services that don't interface with databases, and wouldn't benefit from doing so. Things where the world really does consist of directed object graphs - then OO really shines, and the relational world struggles.
I believe OO is a subjective preference. It does not work smooth for me. If you can show *objective* evidence it is better, I am all ears/eyes. If you like it personally, fine. Enjoy it. To each their own.
Fair enough - we all have our likes and dislikes, and we all work on different things. I actually like both, but for different things.
I've also never seen a good argument that it models the real world - I've heard some hard-core OO people try to argue that, but I don't agree. By the way, I didn't say it models the entire real world better, just some domains. It's certainly good at modeling some things I've worked on better than structured programming. There are cases where encapsulation and polymorphism is useful! However, the mere fact of aspect-oriented programming shows that there are still plenty of cases where it falls down in trying to model things naturally. Most things don't really naturally fit into a simple hierarchy.
I have to say, I can't see how gotos model anything much at all outside of the programming language itself - they're just jumps to another code location, but I'm prepared to learn, if you can show me what they are good at modeling. Structured blocks can at least be used to model things outside of itself - although it certainly doesn't insist that they do.
I completely agree with you that the mismatch between relational and pretty much any other form of coding - not just OO - causes headaches. It's a mistake to pin that only on OO though, IMHO, although OO does seem to have a particularly rough time with it.
By the way, I've been working heavily with relational databases for about 15 years, and I've just completed a masters dissertation which is mostly about certain practical applications of set theory. It doesn't change the way I think of OO - they are just different models - give it another go!
I would say that almost any formalism that moves the semantic intention of the code closer to the domain it models more maintainable. So in this sense, the move to OO programming is definitely comparable to the move to structured programming. This has nothing to do with whether a database is involved or not.
However, you do raise an important point, in that we have different models for data and code, and thus there is an "impedance mismatch" between them. In this sense, combining OOP and relational is difficult and ends up creating all sorts of complicated artifacts that detract from the intention of the code.
It's not that OOP competes with a database, any more than aspect oriented programming competes with structured programming, or functional programming competes with declarative programming. They are simply different models, that offer their own advantages and disadvantages. Code that has to address more than one model will always introduce artificial and difficult constructs, unless they have some kind of essential compatibility between the models.
I agree that the population simply giving away their power is not a reasonable act, but it happens all the time. It's not so much that fighting abuse of power is a route to maturation, more that the taking of power is a route to infantilization. I guess they go together, and the cycle continues...
When a parent says to a child "It's for your own good", the child knows they won't like it, but probably trusts that it really is for their own good. When political leaders say the same, you also know you won't like it, but you should distrust their motives - it's often, but not always, a way to take more power. When a leader tells you to give up hard-won freedoms for your own good, you know just what it is. Unfortunately, many people are quite happy to go along with it, after being appropriately scared by ghost stories.
Of course, not all power is overtly taken, power also condenses in subtler ways - through inherited wealth, better connections, education, prestigious credentials, etc.
That's an interesting set of ideas. For a while in my youth, I played with the notion that the monarchy were a necessary evil, precisely because they were a powerful unifying symbol that elected "representatives" could not achieve. That is also their danger, of course.
The tendency of power in all societies to become entrenched now seems pretty inevitable to me. I think you're right that the US initially rallied around ideas of freedom and reacted against big government - much like the French revolution, etc. These things pass over time, and once again, power condenses.
The real question is what checks and balances can a system provide against abuse by those in power at any one time. The constitution of the US is a great example of this, as is the Magna Carta. Sadly, none of these are immune against corruption.
Bin Laden ripped me off! I demand compensation - can I get the RIAA or someone to sue the dude on my behalf?
Very true. What's the phrase - evil will triumph if good men do nothing?
I think the most important thing is to ensure that the judicial system is separate from the executive. This is the biggest threat at the moment, IMHO. Guantanamo, extroadinary rendition, trial without jury, etc.
Specific laws can be changed, but if the system permits laws to be flouted by those in charge, we're all pretty well doomed. Viva la revolucion!
You make good points, but I do disagree with you. It's not so much that a decision is made not to test, it's just that most places and programmers do not have a culture of creating them. The decision, if a decision is made at all, is usually to unit test in the first place. Not testing is the default position.
I also disagree that test are primarily for finding bugs, and that regression tests diminish in usefulness as they are repeated. Tests do find bugs occasionally, which is nice, but mostly what they do is force the programmer to think about what is valid and what isn't in the code - if they're written along with the code rather than afterwards, that is.
Regression tests give confidence that you haven't broken the code as it changes. It's the repeatability that makes them valuable! If your regression tests never expose a bug introduced by new code, then your programmers are awesome!
Well... OK. But you seem to be saying that the legal rules are those things that powerful people try to get around, which I'd agree with.
If anything, the legal system has become increasingly powerful over the ages, to all our benefit. A great example is the separation of the executive from the judicial systems (which is being undermined in the US and the UK right now).
We might even be moving back to a less legal system (like that which operated in the days of Braveheart). So it doesn't make sense to attack the legal system - that's about the only protection we do have from these rapacious predators. We should be supporting it and strengthening it.
Errr... well, by my star, the fearful, racist and anonymous person I responded to. Of course, I did say asshole. Sorry if that offended you in any way.
In the "real world" you're right, unfortunately. However, you shouldn't discount it out of hand. The "real world" methodologies you use, like structured programming and object oriented programming were once regarded as ridiculous overheads - but the thing is, they actually reduce programming effort overall by making code more robust. I don't think I've used a GOTO in a long time.
Someone once said (can't remember who) that making a program was like piling 100 bricks on top of one another, but using OO programming was like dividing those bricks into 10 piles of 10. It's more stable, but at the cost of additional overhead in setting up those structures. Not only that, by forcing a more structured approach, many untested assumptions get flushed out by the design.
That's why the question posed by this topic is interesting. DbC offers another way to provide better semantics in the code - but it hasn't taken off. Maybe the benefits aren't generally worth it for your average code - I certainly can't speak from experience here.
Interesting, but I don't think it's anything to do with a love of monarchy per se, or the fact that at one point in history you all came from countries with a monarchy.
You're right that it's all to do with whipping up fear so the population can be more easily controlled - it's always been like that, monarchy or no monarchy. Our own monarchy aren't actually that powerful anymore, at least, not overtly. Hence why we refer to "President Blair".
Of course, unlike many of our recent leaders, your leaders are increasingly from a wealthy elite of families - the faces change but the families remain...
Ugggh.... I bow to your legal training based on watching "Braveheart". Especially that bit when the evil dude cut his wife's throat! How corrupt was that! And don't forget the law against taking goats across London Bridge - total evil, evil I tell you! We should all rise up against this corrupt system immediately. You first.
Well, at least they also won't allow anonymous assholes like you to post your disgusting rubbish.
There's always a silver lining.
Me too. We were never as good as we thought we were, but we were never as pathetic as we are now.
If we insist that a user must make all these choices, then you're absolutely right. There are some other ideas about. One is that applications only have an absolutely minimal set of privileges instead of having access to everything that the user can do. Profiles for common applications can be created and validated by security experts. Users don't have to do much at all, and applications can't do much by default.
2 1.html for an example of a system like this that runs on XP - it's a bit of a hack, as XPs security model doesn't really permit this sort of thing, but it gives the general idea.
No UAC, clueless users remain safe, and even if some malware ends up on their machine, it basically can't do anything. Check out http://www.hpl.hp.com/techreports/2004/HPL-2004-2
I can easily think of many ways in which a second search didn't actually find what I wanted, but gave a better quality of result in general. But you apparently can't. Right.
You missed two other options that might be useful to have:
4/ Whatever goes on your computer still requires privileges to execute.
5/ Whatever executes on your computer should not require all the privileges you have (e.g. delegate a small set of them to each process instead). Does this tetris game really need low level access to the disk driver? And a network connection? etc. etc.
phlogiston phlogiston phlogiston.
Total unmitigated speculation. You can't explain something, so you invent something because it feels right to you - but you are just making it up, sunshine. Give me the evidence.
It's a model for long term gain, not short term profit. There are still some people and small companies following this model, but I agree they are dying out.
Market economics will quickly provide competition for short-term profit, but I suspect that markets don't innovate so well when the timescales are longer and the risks appear higher. The established market probably has to collapse in some way first, and some new bottom-up models emerge to fill the gap.
Sort of like an ecosystem that has ecological niches. You can't compete with the quick creatures that are already established if it takes you longer to get there, even if you would be bigger than them if you were allowed the chance.
Hashes aren't "more important" than ciphers. They're used for different things - apples and oranges.
"All hash algorithms will eventually be cracked". What do you mean by "cracked"? How broken does it need to be for it to be "cracked"? Enough that the US government could do it, that a crime ring could do it, that spotty teenages in their bedrooms can do it?
"On the other hand, a good cipher can potentially be technologically unbreakable". The only unbreakable cipher is the one-time pad. We already know that - and even those can be broken if they aren't used carefully. Other ciphers may be more or less resistant to attack than, say, a hash algorithm. More ciphers have been broken (in a practical, exploitable sense) than hash algorithms.
"once quantum computing comes along, today's strongest ciphers will amount to nothing". Not really. Only ciphers that depend on things that quantum computers can solve easily, such as the factorisation problem. So RSA would be useless, but elliptic curve cryptography might be fine. All the standard block ciphers like AES, 3DES and other wouldn't be affected at all, as they don't use the kind of maths that QCs are good at doing.
"for hash algorithms, this holy grail by definition doesn't exist, so researchers will only put enough time and effort to get to the next level of security when the previous level is threatened." There is no difference here between ciphers and hash algorithms (except that more ciphers have been broken than hash algorithms, so more work on ciphers has been done). Now it's time to do some work on hashes is all.
Almost. Banks don't lend money out of the hard cash they hold. In fact, depending on what the central banks allow, they can lend out, say, 10 times the amount of the "hard cash" they have on deposit. As you say, this creates money in the economy (most of which is paid back with interest through value generated elsewhere in the economy).