And double-check your other IDs as well. I have seen student IDs double as a debit card for college services. (This was at Dartmouth College, I am sure they are not alone.) There were incidences of people's cards being stolen and substantial charges being racked up.
All in all, if you have some piece of plastic that can hand out your money, you should know the liability rules and what protection you have on that piece of plastic.
The details vary according to your country's consumer protection laws, but if your credit card is stolen and used, you are not directly liable for more than a certain amount. ($50 in the USA.) Who is? The credit card company! The cost of that liability is a risk they bear, and comes back to merchants and consumers through costs for setting up credit cards.
This is why credit card companies put so much energy into keeping profiles of consumers, and will yank your card as soon as you no longer fit your profile. It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
Just another right that people have and don't appreciate...
An unfortunate tendancy that I see is that a lot of people think that anyone who who likes what they do must be smart, and anyone smart must agree with them.
Both assumptions tend to be very wrong.
As Alexander Pope's saying goes about the first:
Great minds think alike But fools seldom differ
People leave out the second line, but I generally find it relevant because it is so much easier to find fools than not.
The second point is even worse. Contrary to popular assumptions, I have seen essentially no correlation between programming skill and religious position. For instance Larry Wall, who is about as involved with Perl as you can get, is very strongly Christian.
OK, he has ditched the obvious stupidities (eg literal Creationism) but there is no question about the sincerity or depth of his faith.
So no, just having people learn your favorite religion and becoming good at logic won't make them agree with you and won't make them intelligent.
Cheers, Ben
PS Disclaimer. I am both a Perl programmer and an atheist. (The atheism came first.) I just found that I disagreed with the remark...
AFAIK this parody was written recently for that comic. And when I searched/. for the last several weeks I could not find it, nor did I see anything obvious in a search of articles with the word "parody" in the story.
Depending on your definition of "experienced", what I said is correct. While slices are great, some people don't use them much, and people who do use them are far more likely to take array slices than they are hash slices.
At least in my experience.
Cheers, Ben
Since /. apparently can't laugh at itself..
on
Humpday Quickies
·
· Score: 4
Allow me to mention the best parody of/. that I know of out there.
It may make more sense if you read the associated cartoon. Even if you don't like the parody, read a few cartoons anyways...they are good.:-)
Cheers, Ben
PS I know several people who submitted this to/., and it got rejected every time...which is why I am posting like this.
My point still stands. Most programmers would have little trouble learning what 2 of the 3 do. The last one is a concept that most people don't need whose equivalent in other languages winds up with substantially worse syntax. In fact Python actually does not support an equivalent. Its scoping rules are simply not sufficient to the task of defining true closures.
And you criticize Perl for providing that concept under a syntax you don't like? A concept that most programmers don't require, and which is worse or non-existent in many other languages? Besides which, in Perl what it gives is perfectly predictable if you understand references. (Which are easier than pointers - however unlike C you can actually get useful stuff done without using them.) You \ something to get a reference, and then you can use the reference as if it were that thing. What could be easier?
Yes, there is a lot of syntax to Perl. By and large though it follows a very predictable grammar. Sure, most experienced Perl programmers may not know you can do something like
@foo{'bar1', 'bar2'};
but anyone with who is familiar with the language will have little trouble guessing what that should do. (Return a list based on multiple hash lookups in a hash.)
Complaining that you can write obfuscated code in Perl is like complaining that it is hard to correctly parse the correct English sentence, "Buffalo buffalo buffalo buffalo buffalo" and punctuate it appropriately. (Trivia, the word "Buffalo", repeated an arbitrary number of times, can always be parsed as a grammatically correct English sentence. This relies on the fact that it can mean either the animal or "to bewilder and confuse".)
Yes, you can obfuscate any language. You can also write clearly. And you can do either in Perl. Well I can at least...
The localtime() documentation has been part of Perl for years. You will find it repeated in books, Perl's Y2K statement, etc. If you read the documentation rather than use the "try and guess" approach you would have known what that function returned.
As the saying goes, Assume means "Make an Ass of U and Me."
And so, after not reading Perl's documentation, not reading Y2K statements, not testing your own code (despite hearing "Y2K" being chanted for months), you do not think that the existing problem was your fault?
Furthermore if you read the documentation, those Y2K statements, etc, you will find out that the decision was made not in the design of Perl, but in the design of C. Perl chose to imitate what C did a good 10 years ago, and C chose the format for that struct over 20 years ago. Personally I think that a 4 digit year would have made more sense than year-1900. But year-1900 makes a lot more sense than a 2 digit year! (Do you like coding in windowing logic to guess the century? Me neither!)
Oh, and a pointed question. Those scripts that began returning 19100? How many of them would have returned 1900 if the year was returned as a 2 digit year like you asked? Oh really? And you have cause to complain???
Sincerely, Ben Tilly
PS Your proposed "solution" is not even correct Perl code. I leave conclusions as to your competence to the reader.
At issue is the difference between a string, a reference to a function, and calling a function.
Now I grant that "Programming Perl" is not the easist way to learn the distinction between the three. Most Perl programmers don't need to use references (unlike, say, C and pointers), so the middle one is likely to leave a lot of them scratching heads, and is buried pretty well in Chapter 4.
However how many C programmers would have trouble with pointers to functions? And how long would it take the average non-C programmer to figure out what a piece of code that produced one was doing given a standard reference? More than that, how big is the gap between learning how pointers work in C and figuring out what the heck something like
I honestly believe that Bruce agrees with you absolutely when it comes to participating in the bazaar of ideas. You don't get a reputation by begging, you get a reputation by contributing something that others recognize as good.
That said, if you want to run a business based on selling open source (based) products, you had better be adding some value to your version of the product. That takes technical skill. For an outside investor the simplest way to judge that skill is to look at past contributions of your employees. If you have none, and no real product, that is a danger sign. Either your employees should have a history or you should have a demonstrated product. Both would be nice.
So go ahead and prove yourself in the software bazaar. And go ahead and try to prove yourself in the free market bazaar as well. But if someone in the free market bazaar is trying to sell you open source software doesn't meet the BS test for what makes good software development, then don't be a sucker.
Note that what LinuxOne is doing is allowed. But to fall for it is idiotic. And warning people that it is idiotic is an appropriate thing to do.
Coffee is an outstanding case of a legal decision made for good reasons which is blasted by people who don't want to bother understanding.
Yes, the woman did something wrong.
Yes, the award was large.
But the award had a purpose. The purpose of that award was to force McDonalds to reconsider the temperature of its coffee. McDonalds produced coffee that was considerably hotter than the other fast food chains. They knew that the result was that normal accidents and spills caused serious injuries, while the same accidents did not injure customers of other chains. For instance hot coffee spilled in the lap of an elderly woman. With other chains that would have been unpleasant, or a mild scald. Instead she had third degree burns.
Given this the award was made very large. And as a result McDonalds reconsidered their policy and now their coffee is the same temperature as the coffee that other chains make. The result? Fewer injuries.
Now, with these additional facts about the purpose of the settlement, was it wrong to give the woman a large settlement?
I am criticizing Card, not for being a good author, but for failing to clearly draw a line in the sand when a work is done. I see other authors writing similar stories (eg Zelazny) but no matter how clearly the characters are essentially repeats, the story itself is different.
Card is the only one that I know of who publishes the same exact story, same people, places, and plot, several times. And for me personally the result is incredibly frustrating to read.
Incidentally I mentioned Brust as an extreme counter-example. Brust plays games with his stories, so much so that frequently you would swear that his stories are written by different authors!
Also the games are themselves interesting. Remember that deja vu that I complain about from Card? Read To Reign in Hell from Brust. There is about a page-and-a-half in there that is repeated. Exactly. It isn't a mistake, it was a deliberate way to emphasize that a small confrontation near the beginning of the story is the same as the major war at the climax. Did I get irritated? You bet! So irritated that I went back and verified that it was a word-for-word repeat, then I read the lead-in to each section and verified that it was deliberate.
You see, Brust understood how irritating deja vu can be, and so used it for an artistic device. Card does not and so has permanently irritated me. Which is why I will read Brust instead of Card any time I can...
Anything is as compressible as you want with lossy compression.:-)
That said, our visual perception of white noise is itself a highly lossy form of compression, therefore it is easy to fool.
Incidentally wavelets are widely used for "denoising" because they are able to handle both smooth regions and sharp boundaries. Therefore they are much better at concentrating the sharp edges into a relatively small number of big components, so that you can distinguish a sharp edge from white noise. Fourier transforms don't do a good job of telling the two apart, and are therefore frequently unsuitable for denoising.
He has this attitude, "If it was worth selling once, it is worth selling twice."
Many times he has written essentially the same story and sold it as a short story and a novella, or as a novella and a novel. The story is usually pretty good, but reading the second version always leaves me with this irritating deja vu since I know that I have read this before, but I know it wasn't quite this...so I re-read the whole story but I am irritated all the way through.
OK, so turning a book into a movie is standard, but it is too close to a habit of his that eventually made me stop reading him.
Now if only Steven Brust will come out with another few stories...:-)
However the compression technique has to "understand" your binary, wavelets would not be a good choice.
Just so that people understand. A compressed file is a concise description of the original file. A compression technique is an agreed upon way of describing things. And, just as you would use different methods of description for describing a book and a painting, different compression techniques are appropriate to each kind of signal.
And to clear up another piece of confusion. Lossless compression means that you have a complete description, you can recover the original exactly. Lossy compression means that you have an incomplete description. You have a description of an approximation of the original, the distinguishing details got filed in the circular file.
It doesn't matter if some of the pixels match if which ones do is random, so it is at least as hard to specify per pixel what it matches as it is to say per pixel what it is.
Understanding it that way could be complex, let me give the direct definition for a binary signal.
A source of a stream of 1's and 0's is a white noise generator if each digit is randomly (50-50 odds) and independently a 1 or a 0. The resulting signal carries the maximal information/pixel possible, and hence there can exist no compression method that is an overall win in compressing white noise.
What does this look like? Start tossing a coin and record what comes up! (OK, that is not perfect but it is close enough.)
As an image it looks like..static.
When played, the noise sounds like..static.
Any signal with a large amount of information/bit looks like white noise and hence looks like..static.
It is a fundamental fact of information theory that white noise (which resembles static) is identical with a perfectly encrypted signal is identical with a perfectly compressed signal.
Many things that look like white noise are not, but white noise itself?
Incidentally static is what white noise sounds like, and any efficiently compressed signal looks like white noise, which is why a modem sounds like static.:-)
Another interesting fact - a compressed file is a pretty good source of random data, and a compressed encrypted file is substantially more secure than a file just encrypted with the same algorithm. OTOH an encrypted compressed file is a PoS. The encryption messes up the attempted compression.
I have to say that their answers were much better than I expected. I really liked their answer to mine. And I think that you hit some nails pretty solidly.
I would just like to back up your comment on Remote Call Procedures. Microsoft had this thing called OLE, then they moved to COM, now DCOM. The next iteration is called SOAP and it works using XML over http. Everyone accepts http, so it is a great way to get remote call procedures, right?
Wrong.
The issues with remote call procedures are inherent in the nature of what you are doing. Microsoft is addressing the mechanism of doing it, and not also the substance of the security issue. All that they will succeed in doing is make it easier to unkowingly create something with serious security holes that is sent by http. And to make it better they are also encouraging creating customized SOAP applications in Office, which just means that there are a lot of new applications wandering around there that can also be security holes.
When Sun created Java it not only addressed how you call it remotely, it also attempted to address security concerns. Microsoft has not learned that lesson, and I dread what it will take to teach people that security is inherent in what you are trying to do, and not in how you are doing it.
(See likewise some of Tom Christiansen's rants about executable content in email.)
Cheers, Ben
PS Off to my sister's, away from the web for a bit. Glad I caught L0pht's response before I went though!
That is the common decision, and then they make a new type named something like long-long which is 64 bit.
Why?
Because there is too much code out there that does stupid things like walks an array or malloc()ing data knowing that a long is 4 bytes, or talks over a network, sending longs out in protocols that have to interoperate with 32-bit machines.
The resulting porting nightmare is so bad that effort is taken to protect the average program from knowing that you are in a 64-bit environment.
Unless, of course, the KDE crowd secretly plans to release something called Y2KDE Saturday, in which caseyour post is the only one here that is ON-topic, and I owe you a most abject apology.;-)
Well a good chunk of the KDE crowd is in Germany, and Germany's abbreviation is DE, so the time that midnight arrives for them is by definition Y2K DE.
Those are the two most likely errors IMO to be missed in testing. 19K because the people looking at them thought, "4-digit year, that is OK", and 100 vs 00 because until now it has always been easiest to look for a 2-digit year and produce a year that will go from 2 to 3 digits...
Slashdot Mirror
And double-check your other IDs as well. I have seen student IDs double as a debit card for college services. (This was at Dartmouth College, I am sure they are not alone.) There were incidences of people's cards being stolen and substantial charges being racked up.
All in all, if you have some piece of plastic that can hand out your money, you should know the liability rules and what protection you have on that piece of plastic.
Cheers,
Ben
The details vary according to your country's consumer protection laws, but if your credit card is stolen and used, you are not directly liable for more than a certain amount. ($50 in the USA.) Who is? The credit card company! The cost of that liability is a risk they bear, and comes back to merchants and consumers through costs for setting up credit cards.
This is why credit card companies put so much energy into keeping profiles of consumers, and will yank your card as soon as you no longer fit your profile. It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
Just another right that people have and don't appreciate...
Cheers,
Be
Military script kiddies!
"Dare we use our superior forces against our enemies to demonstrate how l33t we are? Is that fair?"
"Hell if I know, r00t the bastards!"
:-/
Ben
Both assumptions tend to be very wrong.
As Alexander Pope's saying goes about the first:
People leave out the second line, but I generally find it relevant because it is so much easier to find fools than not.
The second point is even worse. Contrary to popular assumptions, I have seen essentially no correlation between programming skill and religious position. For instance Larry Wall, who is about as involved with Perl as you can get, is very strongly Christian.
OK, he has ditched the obvious stupidities (eg literal Creationism) but there is no question about the sincerity or depth of his faith.
So no, just having people learn your favorite religion and becoming good at logic won't make them agree with you and won't make them intelligent.
Cheers,
Ben
PS Disclaimer. I am both a Perl programmer and an atheist. (The atheism came first.) I just found that I disagreed with the remark...
AFAIK this parody was written recently for that comic. And when I searched /. for the last several weeks I could not find it, nor did I see anything obvious in a search of articles with the word "parody" in the story.
So while it may have been featured, I doubt it..
Cheers,
Ben
Most people who call themselves Perl programmers don't deserve to be called programmers.
Place your bar appropriately...
Cheers,
Ben
I say what I mean and I mean what I say.
Most of the time.
Depending on your definition of "experienced", what I said is correct. While slices are great, some people don't use them much, and people who do use them are far more likely to take array slices than they are hash slices.
At least in my experience.
Cheers,
Ben
Allow me to mention the best parody of /. that I know of out there.
:-)
/., and it got rejected every time...which is why I am posting like this.
It may make more sense if you read the associated cartoon. Even if you don't like the parody, read a few cartoons anyways...they are good.
Cheers,
Ben
PS I know several people who submitted this to
My point still stands. Most programmers would have little trouble learning what 2 of the 3 do. The last one is a concept that most people don't need whose equivalent in other languages winds up with substantially worse syntax. In fact Python actually does not support an equivalent. Its scoping rules are simply not sufficient to the task of defining true closures.
And you criticize Perl for providing that concept under a syntax you don't like? A concept that most programmers don't require, and which is worse or non-existent in many other languages? Besides which, in Perl what it gives is perfectly predictable if you understand references. (Which are easier than pointers - however unlike C you can actually get useful stuff done without using them.) You \ something to get a reference, and then you can use the reference as if it were that thing. What could be easier?
Yes, there is a lot of syntax to Perl. By and large though it follows a very predictable grammar. Sure, most experienced Perl programmers may not know you can do something like
@foo{'bar1', 'bar2'};
but anyone with who is familiar with the language will have little trouble guessing what that should do. (Return a list based on multiple hash lookups in a hash.)
Complaining that you can write obfuscated code in Perl is like complaining that it is hard to correctly parse the correct English sentence, "Buffalo buffalo buffalo buffalo buffalo" and punctuate it appropriately. (Trivia, the word "Buffalo", repeated an arbitrary number of times, can always be parsed as a grammatically correct English sentence. This relies on the fact that it can mean either the animal or "to bewilder and confuse".)
Yes, you can obfuscate any language. You can also write clearly. And you can do either in Perl. Well I can at least...
Sincerely,
Ben
Let me see.
The localtime() documentation has been part of Perl for years. You will find it repeated in books, Perl's Y2K statement, etc. If you read the documentation rather than use the "try and guess" approach you would have known what that function returned.
As the saying goes, Assume means "Make an Ass of U and Me."
And so, after not reading Perl's documentation, not reading Y2K statements, not testing your own code (despite hearing "Y2K" being chanted for months), you do not think that the existing problem was your fault?
Furthermore if you read the documentation, those Y2K statements, etc, you will find out that the decision was made not in the design of Perl, but in the design of C. Perl chose to imitate what C did a good 10 years ago, and C chose the format for that struct over 20 years ago. Personally I think that a 4 digit year would have made more sense than year-1900. But year-1900 makes a lot more sense than a 2 digit year! (Do you like coding in windowing logic to guess the century? Me neither!)
Oh, and a pointed question. Those scripts that began returning 19100? How many of them would have returned 1900 if the year was returned as a 2 digit year like you asked? Oh really? And you have cause to complain???
Sincerely,
Ben Tilly
PS Your proposed "solution" is not even correct Perl code. I leave conclusions as to your competence to the reader.
At issue is the difference between a string, a reference to a function, and calling a function.
Now I grant that "Programming Perl" is not the easist way to learn the distinction between the three. Most Perl programmers don't need to use references (unlike, say, C and pointers), so the middle one is likely to leave a lot of them scratching heads, and is buried pretty well in Chapter 4.
However how many C programmers would have trouble with pointers to functions? And how long would it take the average non-C programmer to figure out what a piece of code that produced one was doing given a standard reference? More than that, how big is the gap between learning how pointers work in C and figuring out what the heck something like
(this->*(facts_supported[i].factfunc))();
means?
Regards,
Ben
I honestly believe that Bruce agrees with you absolutely when it comes to participating in the bazaar of ideas. You don't get a reputation by begging, you get a reputation by contributing something that others recognize as good.
That said, if you want to run a business based on selling open source (based) products, you had better be adding some value to your version of the product. That takes technical skill. For an outside investor the simplest way to judge that skill is to look at past contributions of your employees. If you have none, and no real product, that is a danger sign. Either your employees should have a history or you should have a demonstrated product. Both would be nice.
So go ahead and prove yourself in the software bazaar. And go ahead and try to prove yourself in the free market bazaar as well. But if someone in the free market bazaar is trying to sell you open source software doesn't meet the BS test for what makes good software development, then don't be a sucker.
Note that what LinuxOne is doing is allowed. But to fall for it is idiotic. And warning people that it is idiotic is an appropriate thing to do.
Cheers,
Ben
Coffee is an outstanding case of a legal decision made for good reasons which is blasted by people who don't want to bother understanding.
Yes, the woman did something wrong.
Yes, the award was large.
But the award had a purpose. The purpose of that award was to force McDonalds to reconsider the temperature of its coffee. McDonalds produced coffee that was considerably hotter than the other fast food chains. They knew that the result was that normal accidents and spills caused serious injuries, while the same accidents did not injure customers of other chains. For instance hot coffee spilled in the lap of an elderly woman. With other chains that would have been unpleasant, or a mild scald. Instead she had third degree burns.
Given this the award was made very large. And as a result McDonalds reconsidered their policy and now their coffee is the same temperature as the coffee that other chains make. The result? Fewer injuries.
Now, with these additional facts about the purpose of the settlement, was it wrong to give the woman a large settlement?
Regards,
Ben Tilly
I always like getting book recommendations..particularly if I decide I like the author! :-)
Cheers,
Ben
I am criticizing Card, not for being a good author, but for failing to clearly draw a line in the sand when a work is done. I see other authors writing similar stories (eg Zelazny) but no matter how clearly the characters are essentially repeats, the story itself is different.
Card is the only one that I know of who publishes the same exact story, same people, places, and plot, several times. And for me personally the result is incredibly frustrating to read.
Incidentally I mentioned Brust as an extreme counter-example. Brust plays games with his stories, so much so that frequently you would swear that his stories are written by different authors!
Also the games are themselves interesting. Remember that deja vu that I complain about from Card? Read To Reign in Hell from Brust. There is about a page-and-a-half in there that is repeated. Exactly. It isn't a mistake, it was a deliberate way to emphasize that a small confrontation near the beginning of the story is the same as the major war at the climax. Did I get irritated? You bet! So irritated that I went back and verified that it was a word-for-word repeat, then I read the lead-in to each section and verified that it was deliberate.
You see, Brust understood how irritating deja vu can be, and so used it for an artistic device. Card does not and so has permanently irritated me. Which is why I will read Brust instead of Card any time I can...
Cheers,
Ben
Anything is as compressible as you want with lossy compression. :-)
That said, our visual perception of white noise is itself a highly lossy form of compression, therefore it is easy to fool.
Incidentally wavelets are widely used for "denoising" because they are able to handle both smooth regions and sharp boundaries. Therefore they are much better at concentrating the sharp edges into a relatively small number of big components, so that you can distinguish a sharp edge from white noise. Fourier transforms don't do a good job of telling the two apart, and are therefore frequently unsuitable for denoising.
Cheers,
Ben
He has this attitude, "If it was worth selling once, it is worth selling twice."
:-)
Many times he has written essentially the same story and sold it as a short story and a novella, or as a novella and a novel. The story is usually pretty good, but reading the second version always leaves me with this irritating deja vu since I know that I have read this before, but I know it wasn't quite this...so I re-read the whole story but I am irritated all the way through.
OK, so turning a book into a movie is standard, but it is too close to a habit of his that eventually made me stop reading him.
Now if only Steven Brust will come out with another few stories...
Cheers,
Ben
Compiled binaries can indeed be compressed.
However the compression technique has to "understand" your binary, wavelets would not be a good choice.
Just so that people understand. A compressed file is a concise description of the original file. A compression technique is an agreed upon way of describing things. And, just as you would use different methods of description for describing a book and a painting, different compression techniques are appropriate to each kind of signal.
And to clear up another piece of confusion. Lossless compression means that you have a complete description, you can recover the original exactly. Lossy compression means that you have an incomplete description. You have a description of an approximation of the original, the distinguishing details got filed in the circular file.
Cheers,
Ben
It doesn't matter if some of the pixels match if which ones do is random, so it is at least as hard to specify per pixel what it matches as it is to say per pixel what it is.
Understanding it that way could be complex, let me give the direct definition for a binary signal.
A source of a stream of 1's and 0's is a white noise generator if each digit is randomly (50-50 odds) and independently a 1 or a 0. The resulting signal carries the maximal information/pixel possible, and hence there can exist no compression method that is an overall win in compressing white noise.
What does this look like? Start tossing a coin and record what comes up! (OK, that is not perfect but it is close enough.)
As an image it looks like..static.
When played, the noise sounds like..static.
Any signal with a large amount of information/bit looks like white noise and hence looks like..static.
It is a fundamental fact of information theory that white noise (which resembles static) is identical with a perfectly encrypted signal is identical with a perfectly compressed signal.
Cheers,
Ben
White noise, by definition, has no redundancy.
:-)
Many things that look like white noise are not, but white noise itself?
Incidentally static is what white noise sounds like, and any efficiently compressed signal looks like white noise, which is why a modem sounds like static.
Another interesting fact - a compressed file is a pretty good source of random data, and a compressed encrypted file is substantially more secure than a file just encrypted with the same algorithm. OTOH an encrypted compressed file is a PoS. The encryption messes up the attempted compression.
Cheers,
Ben
I have to say that their answers were much better than I expected. I really liked their answer to mine. And I think that you hit some nails pretty solidly.
I would just like to back up your comment on Remote Call Procedures. Microsoft had this thing called OLE, then they moved to COM, now DCOM. The next iteration is called SOAP and it works using XML over http. Everyone accepts http, so it is a great way to get remote call procedures, right?
Wrong.
The issues with remote call procedures are inherent in the nature of what you are doing. Microsoft is addressing the mechanism of doing it, and not also the substance of the security issue. All that they will succeed in doing is make it easier to unkowingly create something with serious security holes that is sent by http. And to make it better they are also encouraging creating customized SOAP applications in Office, which just means that there are a lot of new applications wandering around there that can also be security holes.
When Sun created Java it not only addressed how you call it remotely, it also attempted to address security concerns. Microsoft has not learned that lesson, and I dread what it will take to teach people that security is inherent in what you are trying to do, and not in how you are doing it.
(See likewise some of Tom Christiansen's rants about executable content in email.)
Cheers,
Ben
PS Off to my sister's, away from the web for a bit. Glad I caught L0pht's response before I went though!
That is the common decision, and then they make a new type named something like long-long which is 64 bit.
Why?
Because there is too much code out there that does stupid things like walks an array or malloc()ing data knowing that a long is 4 bytes, or talks over a network, sending longs out in protocols that have to interoperate with 32-bit machines.
The resulting porting nightmare is so bad that effort is taken to protect the average program from knowing that you are in a 64-bit environment.
Cheers,
Ben
Unless, of course, the KDE crowd secretly plans to release something called Y2KDE Saturday, in which caseyour post is the only one here that is ON-topic, and I owe you a most abject apology. ;-)
:-)
Well a good chunk of the KDE crowd is in Germany, and Germany's abbreviation is DE, so the time that midnight arrives for them is by definition Y2K DE.
I think you owe an apology.
Cheers,
Ben
Then I went searching.
It looks like you are right. NT is good for a few centuries, VMS for a few tens of thousands of years...
Unix of (AFAICT) all flavors, 32-bit or 64-bit, dies in 2038. (Despite many uninformed comments the the contrary.)
*sigh*
Ben
Those are the two most likely errors IMO to be missed in testing. 19K because the people looking at them thought, "4-digit year, that is OK", and 100 vs 00 because until now it has always been easiest to look for a 2-digit year and produce a year that will go from 2 to 3 digits...
Cheers,
Ben