My resume has sections for paid work and for volunteer work. If I made any contributions to open-source software, I'd probably stick it under volunteer. Once I was part of two or more projects, I'd add another section.
That's the same rationale Bin Ladin used to justify killing civilians in the World Trade Center - they were not protected by the Islamic decree to spare innocents because they were providing the money to fund capitalist evil.
Think if someone with a unix background, who actually reads RFC's
Why do you think that only Unix people read RFCs? They're out there for public consumption. I know Unix programmers who don't read them, and I know Windows programmers who do. One has nothing to do with the other.
Actually, I can't remember whether 'long long' is part of the current standard or not. And there's something about the minimum range of each of these types, but no maximum range. There's nothing preventing the compiler writer from making all integral variables the same.
The point is, 'short' is there because it's always been there, and one of the guidelines that the ISO C group follows is that changes in the standard shouldn't break existing code. Getting rid of short would definitely do this.
Blah. I really am looking for a new job, BTW. I'll be out of town next week, but when I get back I'm going to post my resume (already looking in the paper and the search webites).
Way off topic, but does it bug anybody (who's still listening to this thread) that all the job-search sites are so USA-centric? It sucks to have Canada listed as a state - I don't want jobs in Nova Scotia or Ontario, just here in Winterpeg, Manisnowba.
There are things in Java that will NEVER allow Java to be useful as a general purpose language. The lack of an unsigned datatype is probably the most egregious flaw.
Be careful of making predictions in the computer world. It was once said that only Assembler could ever be used to make an operating system. Compilers would never be able to make code efficient enough. Then along comes these guys, Dennis Ritchie and Ken Thompson who proved them all wrong.
I am currently looking for a new job, in large part due to TPtB ignoring feedback (not about language choice, but things like spam, security, legalities, and other fun stuff).
So if anybody's looking for a slightly-disgruntled programmer in Winnipeg (sorry, can't relocate), let me know;)
That doesn't work if The Powers that Be have decided on a solution ahead of time. If TPtB decide that you must use an in-house language that takes a few thousand lines to code what Perl can do in a few dozen, you can't use the right tool. You have to do what TPtB and the PHB have decreed.
I've been lucky. The management at my previous job was all tech-savvy, so they knew to use the right tool for the job. The management for my current job are completely un-tech-savvy, so they don't know the difference;)
Block content at the user's request. How is that different from call-blocking on telephones (another 'common carrier')?
Give users the option of having spam filters enabled, and let them see the filter configuration (so they know that Aunt Suzie's emails won't get blocked). Does that get around the common-carrier restriction?
Of course, the laws that are created are only good for one given jurisdiction. How can we prevent spammers from moving to spam-friendly countries? I don't like the idea of blocking all traffic from a given country, which seems to be the only way to block it. Any ideas?
The person that killed the Nigerian ambassador confused a scammer with a real official.
The point is, the name Viagra sticks in your head, whether it's the real thing or some fake herbal thing. When the nut goes on a rampage, he'll be able to find Dr. McKinnel, and possibly a large chunk of office staff at Pfizer, but not Joe Spammer.
Careful...this is open to abuse. For example, what if the three complaints are spammers complaining that you've reported their spamming activities (it's happened to me before). Three spammers report your anti-spamming mail-to-admins, and you're gone. Not good.
Some people say that spam should be regulated somehow. The problem with this is how to craft laws that would affect spammers but not regular users of the internet. Ideally, the same laws would protect proper opt-in mailings.
Do you have any thoughts on these laws? I know that, as a non-lawyer, you probably can't do much for the actual wording, but what content would you have if it were totally up to you?
One of the greatest problems with spam-prevention techniques has to do with collateral damage. Can you see any solution to spam that either prevents or minimizes the damage to innocent bystanders, such as other users of a spammer's ISP?
You don't have to listen to all the traffic. Just enough to fingerprint it. Or watch the opening of all the traffic - file transfering protocols have to identify the filename somewhere. If it's a suspicious filename, store the traffic on that stream for later analysis.
Not necessarily. What happens if, instead of listening to traffic on a single protocol, they just listen to all traffic, regardless of the headers? Which they, being in control of the routers, are perfectly capable of doing.
Remember, as long as it's on their network, they can do whatever they want with it. You may not like it, but that's the way it works.
Use the same logic when we're talking about an ISP monitoring you, then see how the crowd reacts...
I, for one, agree with you. Whether it's your university or your ISP, you're using their network, you follow their rules, and they're allowed to enforce it however they want, including sniffing your traffic. Don't like it? Find a new provider or use encryption.
Not if there's a random amount of delay added in every error condition. The current problem is that different error conditions have different timeouts before responding with an error, so you can tell which one you have by whether the delay is short or long. If the delay is random with a large enough range, then a "short" delay may end up longer than a "long" delay sometimes, but not in other cases.
Slashdot Mirror
My resume has sections for paid work and for volunteer work. If I made any contributions to open-source software, I'd probably stick it under volunteer. Once I was part of two or more projects, I'd add another section.
Nope. That's why there are so many submarine patents that we have to worry about.
That's the same rationale Bin Ladin used to justify killing civilians in the World Trade Center - they were not protected by the Islamic decree to spare innocents because they were providing the money to fund capitalist evil.
You do have a "phone number" in a legitimate email. Or at least the internet equivalent of one. It's called a legitimate return address.
Actually, I can't remember whether 'long long' is part of the current standard or not. And there's something about the minimum range of each of these types, but no maximum range. There's nothing preventing the compiler writer from making all integral variables the same. The point is, 'short' is there because it's always been there, and one of the guidelines that the ISO C group follows is that changes in the standard shouldn't break existing code. Getting rid of short would definitely do this.
Blah. I really am looking for a new job, BTW. I'll be out of town next week, but when I get back I'm going to post my resume (already looking in the paper and the search webites).
Way off topic, but does it bug anybody (who's still listening to this thread) that all the job-search sites are so USA-centric? It sucks to have Canada listed as a state - I don't want jobs in Nova Scotia or Ontario, just here in Winterpeg, Manisnowba.
Sorta hard to get the owner fired ;)
Winnipeg the city, not Winnipeg the language. Have I just been trolled?
So if anybody's looking for a slightly-disgruntled programmer in Winnipeg (sorry, can't relocate), let me know ;)
That doesn't work if The Powers that Be have decided on a solution ahead of time. If TPtB decide that you must use an in-house language that takes a few thousand lines to code what Perl can do in a few dozen, you can't use the right tool. You have to do what TPtB and the PHB have decreed.
I've been lucky. The management at my previous job was all tech-savvy, so they knew to use the right tool for the job. The management for my current job are completely un-tech-savvy, so they don't know the difference ;)
Give users the option of having spam filters enabled, and let them see the filter configuration (so they know that Aunt Suzie's emails won't get blocked). Does that get around the common-carrier restriction?
Of course, the laws that are created are only good for one given jurisdiction. How can we prevent spammers from moving to spam-friendly countries? I don't like the idea of blocking all traffic from a given country, which seems to be the only way to block it. Any ideas?
The point is, the name Viagra sticks in your head, whether it's the real thing or some fake herbal thing. When the nut goes on a rampage, he'll be able to find Dr. McKinnel, and possibly a large chunk of office staff at Pfizer, but not Joe Spammer.
Is that the filter that the /. editors run their articles through?
Careful...this is open to abuse. For example, what if the three complaints are spammers complaining that you've reported their spamming activities (it's happened to me before). Three spammers report your anti-spamming mail-to-admins, and you're gone. Not good.
Do you have any thoughts on these laws? I know that, as a non-lawyer, you probably can't do much for the actual wording, but what content would you have if it were totally up to you?
One of the greatest problems with spam-prevention techniques has to do with collateral damage. Can you see any solution to spam that either prevents or minimizes the damage to innocent bystanders, such as other users of a spammer's ISP?
You don't have to listen to all the traffic. Just enough to fingerprint it. Or watch the opening of all the traffic - file transfering protocols have to identify the filename somewhere. If it's a suspicious filename, store the traffic on that stream for later analysis.
Remember, as long as it's on their network, they can do whatever they want with it. You may not like it, but that's the way it works.
I, for one, agree with you. Whether it's your university or your ISP, you're using their network, you follow their rules, and they're allowed to enforce it however they want, including sniffing your traffic. Don't like it? Find a new provider or use encryption.
Pull the values out of /dev/random, the same source of randomness that's used for most cryptologically strong randomness.
Not if there's a random amount of delay added in every error condition. The current problem is that different error conditions have different timeouts before responding with an error, so you can tell which one you have by whether the delay is short or long. If the delay is random with a large enough range, then a "short" delay may end up longer than a "long" delay sometimes, but not in other cases.