This statement, from the 'more about Hskell' link:
"Furthermore, malloc is fairly expensive, so programmers often malloc a single large chunk of store, and then allocate "by hand" out of this."
I've seen this type of statement elsewhere in defense of non-C languages. And yet I've very rarely seen this done in code that wasn't either in 1) an embedded system or 2) a device driver or kernel module.
In those cases where I have seen this in application code, it has been accompanied by lots of other newbie gaffes. I'd question the sanity of anyone who thinks that a user-level app will benefit from a hand-coded heap manager.
But perhaps there are exceptions...does anyone actually do this routinely?
That's a good summary of the principles of American capitalism. But it doesn't apply in much of the rest of the world, where national economies are run not on economic ideology but pragmatic self-interest. If other countries played by the rules that you describe, that might work---but they don't. Hence the WTO, which is an (ugly) attempt to impose a level playing field.
It is perfectly rational to assume that a prime goal of a national economy is to provide a good standard of living for citizens. (I agree that consumer choice is a way to acheive it, but there's no reason it can't be part of public policy as well)
It is totally irrational to assert that America's best and highest calling is to function as a petri dish for unfettered capitalism, with American workers taking the blows when it doesn't work out.
I asked this very same question a few years back in an Extreme Programming class. The answer we got to after discussion was something like:
Refactor the design to handle the state of a transaction in a pluggable way; then create test transaction objects (that implement an abstracted transaction interface) and use those as part of the testing framework. That way the tested code is isolated from the state of the database.
This really intrigued me as it turns the "UI at the top, db at the bottom" model inside out. I've never tried it on anything larger than a little app; it worked well there but I don't think it would scale to a complex transactional application, especially if transactions aggregate or show other dependencies.
Believe it or not, there are corporate IT shops that shy away from anything open-source---even if you can show a support contract. In a place like that, any movement of Java to open-source is a negative, not a positive. And since those shops are exactly where Java is popular, Sun is not stupid to go slow.
These corporate IT shops think they have leverage over the big-$$ vendors by virtue of the fat checks that they can hold back (sometimes true, sometimes not). No check, no leverage, no support.
The reality is that much of IT is about budgets, not technology. Senior managers still work with money long after whatever technical skills they had are gone, so that's the club they use on vendors.
I believe that a secure system is one where "giving would-be intruders the blueprints" does not weaken the protection. This should be provable on paper and could be backed up with practice if necessary.
Foisting crappy code on the public and hoping that nobody breaks it is a very Darwinian head-in-the-sand approach. I can see your point that "we're against obscurity" provides a justification for that approach.
It puts the cart before the horse and shouldn't raise anyone's confidence in the code. Proving that one could do so, however, should raise confidence in the code.
I think you are overreaching here. As far as I'm concerned, the phrase "security through obscurity" means obscurity of system design. If you don't tell anyone about your unprotected resource, that's security through obscurity. All I need to do is discover your resource.
Most security is based on secrets of one kind or another---that doesn't make it "obscurity."
The comment I responded to was proposing individual certs for users. I agree that certs at the domain level are probably reasonable, and I generally think this problem is best addressed at the MTA level not the user level, just as the original article is proposing.
Trusted third party schemes (which is what OCSP pushes a PKI to) don't and won't scale to worldwide deployment either. If you take a look at the existing internet, pretty much all security schemes are multiple layers of technology in combination with human factors. The proposed solution fits the layered model.
I don't claim to be a PKI expert, and don't plan on becoming one---I just don't believe that the basic concepts of conventional PKIs map well to human behavior, decision-making, or politics, outside of specific domains such the military.
Most of your reasons are in fact why signed email WON'T work. B. CRLs don't scale. Period. There's a reason why PKIs hardly ever get past 100K users. C. Someone to sue...only in the US is that an attractive feature. D. Sure, but most users are unlikely to get savvy enough to understand the distinction. The proposed scheme takes that decision out of the user's hand. E. Sure, for that.001% of transactions where conventional forms of contract aren't good enough. Most people wouldn't sign a binding contract without legal advice, at which point they have access to a notary, etc., and the signature feature on email has no value.
My take is that this is a problem that is hard enough to address even partially---adding the burden of a massive worldwide PKI deployment would make it impossible. Verisign or Thawte would love it.
Exactly. The article author makes it sound as though all the tactical jockeying that you describe (for better or worse) requires political organizations to be agile in a way that wasn't possible prior to the Internet. Which is BS, it's been happening for decades all around the world, and for decades in the US at the local level.
Here in the US we are having our own wave of gerrymandering, all designed to lock up the majority of the vote so the two parties can fight over the 10% in the middle. And that has everything to do with large, bureaucratic organizations applying vast resources to their advantage---the "old school" system the author says is dying. I don't see it dying soon.
So an economist's theory from seventy years ago explains the inevitability of American two-party politics, and the upcoming decline of those politics. Sounds good, but...
What about other countries? America is virtually alone in having only two viable political parties. Most of the rest of the world's democracies have more, and some have embraced a much more dynamic multi-party coalition form of government. Was their "cost of information" a lot lower?
I think the author's analysis discounts many other factors. American politics is affected by American's much weaker community affiliation, propensity for movement, high economic mobility, etc. Under these conditions the cost of information may be important.
In countries where (for instance) tribal or religious ties are strong, you could lower the cost of information/political organizing all you want and have no significant effect.
Then again maybe I should be over on k5 with this...:)
I've been to European cities a number of times. They don't need microphones and noise studies. Here's my comprehensive plan: 1. PUT SOME FRICKIN' MUFFLERS ON THEIR MOPEDS.
'K, point taken. I never went down the path of wrapping it to make it look like a file system; instead I've just created higher-level functions for tweaking whatever I needed. AppConfig::setPortNumber(int port), that sort of thing. That way I can (and have) use a factory pattern to add subclasses that use ini files instead.
So unusable? How? It's been a while, but the main oddities I recall from the registry API were inconsistent behaviors across platforms, and the standard "vanilla" vs. "vanillaEx" naming convention stuff that MS uses to extend their C apis.
But otherwise, it uses handles that are waitable, notification registration, etc. Just like a modern FS.
Did you object to the complexity of API or the functionality?
The/. editors have not yet mastered the fact that in an 80-word summary, one might want to indicate where the goofy facts stop and the made-up humor starts, so readers can actually recognize it as such.
Instead they just look like a bunch of tards who make shit up (or approve it) and then hit the post button.
So...it doesn't matter what his money does, it only matters what percentage of his net worth it represents?
Assuming the 168 mil will make a difference---and I assume that it would---the people who don't die from malaria as a direct result of his charity would no doubt love to argue this point with you.
If he spent a far greater amount of his net worth on something idiotic like historic golf course preservation, I'd have to assume you'd feel he was more "generous."
I've gone through this too. Invariably, upon looking back on it, I've realized that I spent a bunch of time on organizing my inbox/personal network share/hard drive/car trunk/sock drawer that didn't really pay off...mostly because the system doesn't last if you only enforce it when your environment gets to be a pigsty.
The other thing I've noticed is that while it can't be justified on its own, that type of activity, for me anyway, usually means I am putting time into "getting organized" which usually has some other payoff.
For instance, I might remember some important due date while I shuffle crap on my desk trying to get "organized." The item I remembered usually has nothing to do with what is in my hand.
First off, the point of elaborating was to get past "AD sucks."
Export of passwords? Hmmm, given that the big metadirectory solutions have a problem doing this with non-AD servers, why should AD be different? They're called "salted hashes", by the way, and everyone does them a little differently. Exporting the clear password would be a horrible security problem.
How to push authentication credentials? If you mean importing accounts, then the above answer applies. You can always go over SSL as well. Do you mean implementing cross-domain trust?
And the reason you can authenticate Windows logins against OpenLDAP is that AD supports LDAP protocols, but Windows clients don't use it exclusively. AD may or may not be a great LDAP server, but I don't know that anyone has ever claimed that Windows boxes are vanilla LDAP clients.
AD is a MS product that has reasonable support for LDAP, not a great general-purpose LDAP server (then again I don't think openLDAP fits the bill either). My point was that some of the general-purpose LDAP servers have interoperability issues as well.
The standard stuff is fairly standard. inetOrgPerson is available as an add-on (which I think is lame, but you can get there from here). Many of the other "compliant" directories have their own blind spots too.
The nonstandard stuff is sometimes doc'd, sometimes not; for instance, if you are expecting full docs on how GPOs are represented in the database, you will be disappointed. Then again, why would you code to their goofy extension?
One thing I think is *lame* is the 5k size limit on number of users in static groups. We are using dynamic groups/roles for some stuff, but static groups are a useful adjunct to that. 5k is just pathetic.
Vanilla LDAP != inherently better than AD. There are some crappy LDAP servers out there. Whatever you can say about openLDAP, the management and administration side of it is primitive.
I consider AD to be a viable general-purpose LDAP server for certain applications. I'm using it for a 20K user directory right now...but I wouldn't go over 250K with it, especially one that required any kind of master-hub-replica architecture to scale.
I do believe certain types of intellectual training provide perspectives that are very hard for "regular folks" to adopt easily. Higher math and physics, certainly, as well as some philosophy. Then again, some academic disciplines seem designed to be specialized / hard-to-understand without actually having much value....
Agreed. Funny that some of what humans see as non-random (e.g., the nice spherical shape of planets, the ticking of a wristwatch) can have random properties at the micro or macro scales, whereas what appears to humans to be random (growth pattern of trees, crystals, coastlines) can have a strong order to it that only mathematicians can appreciate.
I've done this multiple times. It's easy to do when you write from scratch with this approach, much harder to retrofit, but it comes down to the same issue....CLI apps tend to have a scriptlike UI, whereas decent GUI apps *demand* that multiple actions be available to the user at any time.
This requires that the application logic be converted into an event-driven state-machine model. Some CLI apps just can't make the transition without a rewrite.
Once the transition is done, though, you are right...you can make an app support almost any UI, including supporting a CGI interface for the web (assuming that's appropriate).
Some of the campus smartcards that I have seen are NOT credit-card style (screened logo and raised lettering). Instead, they look like driver's licenses, with a color photo under tamper-resistant plastic laminate that has a hole for the smartcard contacts.
Just as with a regular driver's license, with enough abuse the plastic will delaminate, causing shredding of the card where the reader's contact fingers try to touch the chip contacts. Wonky plastic bits in the contact path cannot be good for reliability.
Slashdot Mirror
This statement, from the 'more about Hskell' link:
"Furthermore, malloc is fairly expensive, so programmers often malloc a single large chunk of store, and then allocate "by hand" out of this."
I've seen this type of statement elsewhere in defense of non-C languages. And yet I've very rarely seen this done in code that wasn't either in 1) an embedded system or 2) a device driver or kernel module.
In those cases where I have seen this in application code, it has been accompanied by lots of other newbie gaffes. I'd question the sanity of anyone who thinks that a user-level app will benefit from a hand-coded heap manager.
But perhaps there are exceptions...does anyone actually do this routinely?
That's a good summary of the principles of American capitalism. But it doesn't apply in much of the rest of the world, where national economies are run not on economic ideology but pragmatic self-interest. If other countries played by the rules that you describe, that might work---but they don't. Hence the WTO, which is an (ugly) attempt to impose a level playing field.
It is perfectly rational to assume that a prime goal of a national economy is to provide a good standard of living for citizens. (I agree that consumer choice is a way to acheive it, but there's no reason it can't be part of public policy as well)
It is totally irrational to assert that America's best and highest calling is to function as a petri dish for unfettered capitalism, with American workers taking the blows when it doesn't work out.
I asked this very same question a few years back in an Extreme Programming class. The answer we got to after discussion was something like:
Refactor the design to handle the state of a transaction in a pluggable way; then create test transaction objects (that implement an abstracted transaction interface) and use those as part of the testing framework. That way the tested code is isolated from the state of the database.
This really intrigued me as it turns the "UI at the top, db at the bottom" model inside out. I've never tried it on anything larger than a little app; it worked well there but I don't think it would scale to a complex transactional application, especially if transactions aggregate or show other dependencies.
Believe it or not, there are corporate IT shops that shy away from anything open-source---even if you can show a support contract. In a place like that, any movement of Java to open-source is a negative, not a positive. And since those shops are exactly where Java is popular, Sun is not stupid to go slow.
These corporate IT shops think they have leverage over the big-$$ vendors by virtue of the fat checks that they can hold back (sometimes true, sometimes not). No check, no leverage, no support.
The reality is that much of IT is about budgets, not technology. Senior managers still work with money long after whatever technical skills they had are gone, so that's the club they use on vendors.
I believe that a secure system is one where "giving would-be intruders the blueprints" does not weaken the protection. This should be provable on paper and could be backed up with practice if necessary.
Foisting crappy code on the public and hoping that nobody breaks it is a very Darwinian head-in-the-sand approach. I can see your point that "we're against obscurity" provides a justification for that approach.
It puts the cart before the horse and shouldn't raise anyone's confidence in the code. Proving that one could do so, however, should raise confidence in the code.
I think you are overreaching here. As far as I'm concerned, the phrase "security through obscurity" means obscurity of system design. If you don't tell anyone about your unprotected resource, that's security through obscurity. All I need to do is discover your resource.
Most security is based on secrets of one kind or another---that doesn't make it "obscurity."
The comment I responded to was proposing individual certs for users. I agree that certs at the domain level are probably reasonable, and I generally think this problem is best addressed at the MTA level not the user level, just as the original article is proposing.
Trusted third party schemes (which is what OCSP pushes a PKI to) don't and won't scale to worldwide deployment either. If you take a look at the existing internet, pretty much all security schemes are multiple layers of technology in combination with human factors. The proposed solution fits the layered model.
I don't claim to be a PKI expert, and don't plan on becoming one---I just don't believe that the basic concepts of conventional PKIs map well to human behavior, decision-making, or politics, outside of specific domains such the military.
Most of your reasons are in fact why signed email WON'T work. .001% of transactions where conventional forms of contract aren't good enough. Most people wouldn't sign a binding contract without legal advice, at which point they have access to a notary, etc., and the signature feature on email has no value.
B. CRLs don't scale. Period. There's a reason why PKIs hardly ever get past 100K users.
C. Someone to sue...only in the US is that an attractive feature.
D. Sure, but most users are unlikely to get savvy enough to understand the distinction. The proposed scheme takes that decision out of the user's hand.
E. Sure, for that
My take is that this is a problem that is hard enough to address even partially---adding the burden of a massive worldwide PKI deployment would make it impossible. Verisign or Thawte would love it.
Exactly. The article author makes it sound as though all the tactical jockeying that you describe (for better or worse) requires political organizations to be agile in a way that wasn't possible prior to the Internet. Which is BS, it's been happening for decades all around the world, and for decades in the US at the local level.
Here in the US we are having our own wave of gerrymandering, all designed to lock up the majority of the vote so the two parties can fight over the 10% in the middle. And that has everything to do with large, bureaucratic organizations applying vast resources to their advantage---the "old school" system the author says is dying. I don't see it dying soon.
So an economist's theory from seventy years ago explains the inevitability of American two-party politics, and the upcoming decline of those politics. Sounds good, but...
What about other countries? America is virtually alone in having only two viable political parties. Most of the rest of the world's democracies have more, and some have embraced a much more dynamic multi-party coalition form of government. Was their "cost of information" a lot lower?
I think the author's analysis discounts many other factors. American politics is affected by American's much weaker community affiliation, propensity for movement, high economic mobility, etc. Under these conditions the cost of information may be important.
In countries where (for instance) tribal or religious ties are strong, you could lower the cost of information/political organizing all you want and have no significant effect.
Then again maybe I should be over on k5 with this...:)
I've been to European cities a number of times. They don't need microphones and noise studies. Here's my comprehensive plan:
1. PUT SOME FRICKIN' MUFFLERS ON THEIR MOPEDS.
'K, point taken. I never went down the path of wrapping it to make it look like a file system; instead I've just created higher-level functions for tweaking whatever I needed. AppConfig::setPortNumber(int port), that sort of thing. That way I can (and have) use a factory pattern to add subclasses that use ini files instead.
So unusable? How? It's been a while, but the main oddities I recall from the registry API were inconsistent behaviors across platforms, and the standard "vanilla" vs. "vanillaEx" naming convention stuff that MS uses to extend their C apis.
But otherwise, it uses handles that are waitable, notification registration, etc. Just like a modern FS.
Did you object to the complexity of API or the functionality?
The /. editors have not yet mastered the fact that in an 80-word summary, one might want to indicate where the goofy facts stop and the made-up humor starts, so readers can actually recognize it as such.
Instead they just look like a bunch of tards who make shit up (or approve it) and then hit the post button.
So...it doesn't matter what his money does, it only matters what percentage of his net worth it represents?
Assuming the 168 mil will make a difference---and I assume that it would---the people who don't die from malaria as a direct result of his charity would no doubt love to argue this point with you.
If he spent a far greater amount of his net worth on something idiotic like historic golf course preservation, I'd have to assume you'd feel he was more "generous."
I've gone through this too. Invariably, upon looking back on it, I've realized that I spent a bunch of time on organizing my inbox/personal network share/hard drive/car trunk/sock drawer that didn't really pay off...mostly because the system doesn't last if you only enforce it when your environment gets to be a pigsty.
The other thing I've noticed is that while it can't be justified on its own, that type of activity, for me anyway, usually means I am putting time into "getting organized" which usually has some other payoff.
For instance, I might remember some important due date while I shuffle crap on my desk trying to get "organized." The item I remembered usually has nothing to do with what is in my hand.
First off, the point of elaborating was to get past "AD sucks."
Export of passwords? Hmmm, given that the big metadirectory solutions have a problem doing this with non-AD servers, why should AD be different? They're called "salted hashes", by the way, and everyone does them a little differently. Exporting the clear password would be a horrible security problem.
How to push authentication credentials? If you mean importing accounts, then the above answer applies. You can always go over SSL as well. Do you mean implementing cross-domain trust?
And the reason you can authenticate Windows logins against OpenLDAP is that AD supports LDAP protocols, but Windows clients don't use it exclusively. AD may or may not be a great LDAP server, but I don't know that anyone has ever claimed that Windows boxes are vanilla LDAP clients.
AD is a MS product that has reasonable support for LDAP, not a great general-purpose LDAP server (then again I don't think openLDAP fits the bill either). My point was that some of the general-purpose LDAP servers have interoperability issues as well.
Proprietary crap? Please elaborate.
The standard stuff is fairly standard. inetOrgPerson is available as an add-on (which I think is lame, but you can get there from here). Many of the other "compliant" directories have their own blind spots too.
The nonstandard stuff is sometimes doc'd, sometimes not; for instance, if you are expecting full docs on how GPOs are represented in the database, you will be disappointed. Then again, why would you code to their goofy extension?
One thing I think is *lame* is the 5k size limit on number of users in static groups. We are using dynamic groups/roles for some stuff, but static groups are a useful adjunct to that. 5k is just pathetic.
Vanilla LDAP != inherently better than AD. There are some crappy LDAP servers out there. Whatever you can say about openLDAP, the management and administration side of it is primitive.
I consider AD to be a viable general-purpose LDAP server for certain applications. I'm using it for a 20K user directory right now...but I wouldn't go over 250K with it, especially one that required any kind of master-hub-replica architecture to scale.
...and funnier too. That Verity Stob, she's a chuckler.
Oh come on, you know what I meant...:)
I do believe certain types of intellectual training provide perspectives that are very hard for "regular folks" to adopt easily. Higher math and physics, certainly, as well as some philosophy. Then again, some academic disciplines seem designed to be specialized / hard-to-understand without actually having much value....
Agreed. Funny that some of what humans see as non-random (e.g., the nice spherical shape of planets, the ticking of a wristwatch) can have random properties at the micro or macro scales, whereas what appears to humans to be random (growth pattern of trees, crystals, coastlines) can have a strong order to it that only mathematicians can appreciate.
I've done this multiple times. It's easy to do when you write from scratch with this approach, much harder to retrofit, but it comes down to the same issue....CLI apps tend to have a scriptlike UI, whereas decent GUI apps *demand* that multiple actions be available to the user at any time.
This requires that the application logic be converted into an event-driven state-machine model. Some CLI apps just can't make the transition without a rewrite.
Once the transition is done, though, you are right...you can make an app support almost any UI, including supporting a CGI interface for the web (assuming that's appropriate).
Some of the campus smartcards that I have seen are NOT credit-card style (screened logo and raised lettering). Instead, they look like driver's licenses, with a color photo under tamper-resistant plastic laminate that has a hole for the smartcard contacts.
Just as with a regular driver's license, with enough abuse the plastic will delaminate, causing shredding of the card where the reader's contact fingers try to touch the chip contacts. Wonky plastic bits in the contact path cannot be good for reliability.