And I'm pretty sure that I'm aware of that. If you re-read my original post, you'll see that the point I was making is that T, like Parnas's notation, ignored on rather important requirement of an operating system - that it work reasonably efficiently. The overhead of the microkernel, according to to Linus (and with which I agree), means that the microkernel isn't generally suitable for a general purpose operating system. Yes, what I just said was a gross generalisation, and oversimplification, and I'm aware of that. But Linus point is well taken, I think, and absolutly correct.
Where my example falls down is that T pooh-poohs performance considerations ("just give it faster hardware"), whereas Parnas never claimed that his notation was for anything other than a notation to prove PROGRAMME correctness, and made NO claims about establishing the SUITABILITY of a programme for any given task whatsoever, as far as I know.
It's also interesting to note that T is still saying that all you have to do is throw faster hardware at it and the problem will go away..... but you know what? He said the problem would go away back in 1992 when this first came up, when he was expecting 200 MIPS processors the next year..... and the problem is still with us.
Basically, what you're saying is that Parnas' calculus was only strong enough to determine if program X correctly produces the output expected by algorithm Y, without respect to the actual complexity. Is that correct?
No, actually, you're not. I don't think I made it quite clear, because Parnas' notation was not the main point in my original post.
Parnas' notation dealt with proving that the *implimentation* was mathamatically correct, not the algorythm.
Without re-creating his papers, this is basically how it worked:
Each statement could be reduced to a mathamatical construct that was either true or false for each possible input. Each branching construct had it's own notation. To probe that an IF statement was correct, you would first prove the contents of each branch, and then apply the those results to the branch itself. If the true branch was proved correct, and the false branch was proved correct, then by proving that the IF statment would send control to the proper block for all possible inputs, you could prove that the IF statment was correct.
You would do this for each routine, proving the invididual blocks of code. Then, given a description of all possible inputs for a given subroutine or function, you could prove that IT was correct, using the previous proofs as "black boxes", if you will.
So you started at the bottom of the programme, rolling the statements up as you went along. Block is proven, branch is proven, routine is proven, and so on, reducing the expressions along the way. The final result of this particular project was a series of mathamatical statements that were a few pages total, that were deomonstrably mathamatically correct.... therefore, the programme was correct.
That's a practical description of what he had, anyway - it was a long time, and I'm a programmer, not an computer scientist, so please, people, forget the lack of rigor. I'm just an old fart with a shitty memory:-)
But, then, who said real-time programming when millions of lives are on the line was meant to be fun?
Certainly not the #@(&$@$*#@ sadist that invented the IV&V, that's for sure:-)
Today most of the software that is used to fly planes (both fighter jets and passenger) is based on a microkernel architecture. So microkernels are not just lab toys, real and mission critical systems are run by microkernel architectures.
And where did I say that microkernels were unusable? I've personally used QNX and VRTX myself. For small, simple (for the O/s) systems, they're beautifull. As a general purpose coputing platform, they tend not to be.
The speed problem can often be solved just buy getting a faster hardware. The main reason Linus rejected microkernels back in the day was because the cost of context switches was prohibitive. Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines.
Disingenuous, but wrong. Modern computers do a lot more now, typically, then they did then - and so need faster CPUs for the WORKLOAD. I don't care what the application is.... for MOST things, telling somebody that theyr'e going to take a 10-20% hit off the top before they do ANYTHING, compared to the alternatives, is going to get you nothing but doors slammed in your face
Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k. It can already take up to a year to check the correctness of a 8k lines of code microkernel and there will be an exponential demand for resources as the code size increases. So in reality it will not be possible to check the linux kernel for correctness.
Again.... disingenuous, and again, wrong.
Linus has this nice little kernel with 2.6 million lines of code in it
Linus refactors his code so that device drivers, filesystems, etc are outside the kernel, and he has a nice mini-me Linux
What do we have? We STILL have 2.6 million lines of code, but some of them are in the kernel, and the rest of them are OUTSIDE the kernel. SO what magically happens to those bits that were moved out to userland? Did they suddenly become flawless? Of course not - the errors and flaws are still there. Because you do't really CARE about any arbitrary distinction betweeen kernel/userland, do you, as long as you can read from the disk, write to the network, etc. it's the SYSTEM that counts..... and the SYSTEM still has 2.6 million lines of code.
Secondly, a lot of the things that you're claiming for microkernels - lack of complexity, etc - can be acheived just as simply by how you organise the sorce code FOR the kernel. It used to be called compartmentalisation. Ever hear of it?
Tovarisch Gorshkov, to prove that the program is correct ("covert channel analysis" and such.) might take up to a year and that is only if there are less than 10k lines of code and no more, but that doesn't mean that the program will _run_ slow. The time and methods used to prove correctness don't necessarily say anything about the speed of the program during runtime.
You're right, it *doesn't* say anything about the code efficiency, or the runtime per se..... but then again, neither did I. Just as some algorythms are faster than others O(n) vs O(log n), etc, some designs are inherently slower than others. And what is a kernel, if not the expression of an (albiet complex) algorythm to accomplish a task (provide system services)?
The microkernel may be more elegant, more pristine in the lab..... but it's slow by design. There is only so much you can do to speed it up - the limitations are inherent in the message passing mechanisms.
I'm sorry, I'm with Linux on this one.
Provably correct doesn't mean "good".... and "I haven't bothered proving the sucker" doesn't mean crash and burn.
Also, there is nothing about a microkernel that makes it more inherently provably correct than a monolithic kernel. Even going back to Parnas' notation that we used years ago, and thinking about the structure of the Linux kernel, it would be pretty easy to go through the exercise and prove it correct/incorrect.... and no easier to do so with with Minix, or BeOS, or any other microkernel.
Sort of. In the scanerio you describe, the program was, in fact, not proved to be correct because the people who did the proof failed to take into account the real requirements for the system.
If you don't even know your requirements, no methodology to implement those requirements is going to work reliably.
I agree absolutly.
The point I was trying to make - and this is where I see the parallel - is that T seems to be trying to say that microkernel good, monolithic bad based only on elegant design, and theoretical simplicity. No doubt, it appeals to the academic in him (Go figure)
But he is ignoring the "time domain" of an operating system, if you will - it's practicality, it's ability to do usefull work in a reasonable period, and it's usability in the real world - just as Parnas' notation did.
I make no claim as to whether or not Parnas *intended* for his notation to be used for a hard real-time system - I know he was retained as a consultant on the project, but I personally neither saw nor heard of/from him during the entire time. And let me be perfectly clear - his notation was absolutly *gorgeous* and extremly usefull. I, on the other hand, having been the idiot who raised the point in the first place, wound up having to do the timing analysis based on best/worst case sensor timings, and instruction-by-instruction counting of the clock cycles required for each ISR, etc. I plugged the numbers into a programme I wrote for the purpose, and basically did nothing more than an exhaustive analysis of all possible combinations of timings. Not as elegant by far, but what the hell. Who cares if it takes two days to run, if it means you don't have to worry about glowing in the dark?
Years ago, I was a lead analyst on an IV&V for the shutdown system for a nuclear reactor - specifically, Darlington II in Ontario, Canada.
This was the first time Ontario Hydro wanted to use a computer system for shutdown, instead of the old sensor-relay thingie. This made AECB (Atomic Energy Control Board) rather nervous, as you can understand, so they mandated the IV&V.
I forget his first name - but Parnas from Queen's University in Kingston had developed a calculus to prove the correctness of a programme. It was susinct, it was precice, it was elegant, and it worked wonderfully.
ummmmm..... well, kind of. About 3/4 of the way through the process, I asked a question that nobody else had thought of.
OK, so we prove that the programme is correct, and it'll do what it's supposed to do.... but how long will it take?
You see, everybody had kinda/sorta forgot that this particular programme not only had to be correct, but it had to tell you that the reactor was gonna melt down BEFORE it did, not a week afterwards.
The point is, that there is often much more involved in whether or not a programme (or operating system) is usefull than it's "correctness"
I thought the Canadain way was to use it, and then apologise to the developer for wanting a feature that obviously wasn't necessary, or he would have already written it?
This is absolutly a non-story.... with the plugin for Word/Office/whatever, the ability of ODF applications to work with assistance devices will be - by defination - *exeactly* as good as what it currently is in word.
Not to put to fine a point on it... but as strongly as they feel about their cause, I wonder if they realise that what they're doing - if used by poeple inside those countries - could get people killed?
I can't help but wonder how zealous they will be if they have to think about the potential blood on their hands.
Doing what you can to help from your end is one thing. Helping somebody become a martyr is another.
To my mind, it's like giving dynamite to a suicide bomber, without thinking about either the bomber or any of his victems.
Dunno about that. Just the time it takes to bring up a socket and get some syn/ack going chews up a good portion of a second. Maybe he was searching a local password database.
Good point, but you forgot something
He was operating on a 56k dialup line. Wanna drop those numbers a little?:-)
Agreed. I was just trying to make the *general* point. Too many people worry about the l33t way of doing things without taking into consideration the people who will be viewing their pages.... which is the whole point to having a page in the first place.
I think whaty ou've done is entirely appropriate for your application. But let's face it - if you put up a tutorial web page and used that as an example, it would only be a few days before we'd be flooded by 500 meg java pages that did nothing more than change the colour on some background somewhere.
Cohn said ISPs would better serve users by quarantining suspect spam messages in special mailboxes. That way, recipients would have the option of checking for false positives. If an ISP does block an e-mail, she says the sender and recipient should be notified and told why.
This is bullshit on so many levels
a) If you return it to the sender, what your'e gonna do is flood some poor schmuck who's email address was picked as random as the "sender" of the email, and really, REALLY piss off the mail server admin for that particular domain.
b) How is it better that instead of me just hitting the del key for spam email that DOES get through, I - as the user - would now have to click on the link in the notice, hit delete to delete the spam email I'm being notified about, and then click delete on the notice itself?
Now, let's assume that 2/3 of all email IS spam (an estimate used in the article)
a) You just tripled the amount of disk space the ISP needs on it's mail servers.
b) You just greatly increased the amount of bandwidth the ISP has to dedicate for email. If they don't block, they accept - more bandwidth. Then they send you the notice that it's there in quarrentine - more bandwidth. Then you have to download and read the email - More bandwidth. THen you have to go to that inbox, and delete the email. More bandwidth.
Methinks the fumes that guy's smelling from having his head stuck so far up his arse is affecting is brain function.
I know this doesn't probably apply to you, given your target audience. But what you've done, I think, is generally a bad idea.
Reality check: most of the world (about 80%, if I remember corectly) is still on dialup.
That page comes in at 43K. The same page in HTML would probably be 2/3 less. When you're trying to sell stuff and keep people on your site, the difference between a 2-3 second download and a 8 second download is huge.
Would it necessarily be as "pretty" as the javascript (or php, ajax, or "buzzword") page? Maybe, maybe not - but that's not the point. It doesn't matter wtf the page looks like if nobody's looking.
oh - you're talking about blockign INCOMING port 80.
Look - I'm sorry, folks, but when somebody says "block port XX", I read that it's blocked, in AND out. If you mean incoming, or outgoing please say so?
Many people still use Word97 and are perfectly happy with it and see absolutely no reason to upgrade. If Microsoft wants to introduce a new file format (Office XML) and a new interface at the same time, I see a huge opportunity for OpenOffice to pick up the ball.
Word97? Let's be honest here, folks - 99.99999% of all "documents" are still standard memos & letters that except for the typefaces, don't look any different than they did in the 1980s when the IBM Selectric was the big thing, and CP/M was something that geeks couldn't wait to get their hands on.
And those 99.99999% of all documents could STILL be generated just as efficiently on Wordstar under CP/M, on a Z80 with 64K of memory, as what it is today on a 3.2Ghz XP machine with 2 gig of memory the secretary plays solitaire on during her lunch hour.
OK - this is the 2nd one like this I've received in the last 5 minites. Could somebody please point out to me where I said ANYTHING about incoming port 25? Please?
MY experience - as I've already stated - is that the ISP's that do block, block both incoming AND outgoing - I've already said that. If your ISP is different, well, they need better administrators.
I know blocking incoming port 25 does nothing. I know blocking outgoing port 25 does a shitload and a half.
Wrong. Blocking incoming port 25 does absolutely nothing to prevent spam. Spam has nothing to do with port blocking by many major ISPs. (If they actually cared they would block OUTBOUND port 25 not inbound but only a few do that.)
That's already been addressed in this thread, although it may be below where you've been reading so far.
As a matter of fact......... yes. I'm gonna have to start paying attention to who's writing what - I didn't expect quite this much of a to-and-fro, and I'll confess it caught me off-guard:-)
Not sure if you noticed, but blocking port 25 doesn't seem to be helping much. All it does is restrict me from recieving email to my personal mail server, not sending it. If you noticed, you can always sent out on 25(generation of spam) but they block incoming 25. So there's no way this will combat spam.
In my experience, most of the ISP's that block port 25 block both incoming AND outgoing, except to their designated smtp servers. That's certainly the way it's been done with any ISP I've used. (Sympatico, Rogers, Cogeco, and Bell here in Canada).
If they don't do it that way, then you're right, it won't do a damned thing - they're just wasting their time
Outside of companies/organisations, the ratio of "people who don't know what a mail server is" to "people who want to run their own" is probably on the order of about 100,000 to 1. For you "1's" out there, for most ISPs, the cost of accomodating you doesn't come anywhere close to the cost of the administrative headaches that arise from the other 99,999. So it's blocked.
The ISP's are not "changing the definition of the internet". They're just making an administrative decision to not support something that the vast majority of their users don't want to save themselves the administrative headache.
And they're providers, not resellers.
Why not? There's nothing restricting this technically, other than the bandwidth available to me and IBM. As far as services go, I certainly can offer anything IBM can put online, assuming I'm smart enough.
No, there isn't any technical reason why you can't - I didn't say there was. I was making the point that just because something is *possible*, doesn't mean that it has to be made available. It's simply a matter of added value for added coin.
Individual users can spam you with viruses whether or not port 25 is open, so your suggested solution is bollocks.
The discussion wasn't about your *receiving* spam, but the ability of spammers to use other machines to SEND spam. SO yes, blocking port 25 does in fact deal with it. No prarie oysters here.
There are some ISP's that will kill your port 25 access if you've got an open relay, but there are a lot of us out there that not only run mail servers from home internet connections with dynamic IP addresses, but we do it much better than some large corporations with so-called "business accounts."
Yes, there are. ANd there are ISPs that don't/wont block them at all, and others that have said screw it - port 25 is blocked for everybody. That's their decision to make.
You're obviously not capable of doing it yourself, but there are a lot of us that are perfectly responsible with our mail servers. I don't need the ISP to limit my access just because someone like you isn't bright enough to handle the responsibility.
I've been administering mail systems, internet gateways, web servers, etc since around 1990 as a major part of my job. I DO take responsibility for my servers - and I expect ISPs to do the same for theirs. If they have determined that blocking port 25 is the most effieient way for them to do that, I'm not going to argue with them. It's their choice.
Wow, this is wrong on so many levels. It appears that you don't understand how the internet works. ISPs get put on blacklists usually because they actively support spammers. Sure, there are some screwed-up blacklists that ban ISPs for ludicrous reasons, but that's the nature of the blacklist community and is a problem with the blacklists, not the ports that are available to users. ISPs should be monitoring their networks anyway, so I don't see that as an increased cost.
Actually, I'm very familiar with how the internet works - I've been on the 'net in one form or another since 1982, before it was CALLED the internet, and fast email was two days from here to Paris, if you managed to hit all the hops just right.
Contrary to what you've said, very *few* ISPs activly support spammers - more often than not, it's passive acceptance - refusal to deal with them. If it was just a matter of a "few active supporters", spam wouldn't be a problem - those ISPs would be blocked and the problem would be solved.
As for monitoring their networks, network administrators have many things to do - and monitoring WHAT traffic is going over their lines should be way down on their priority lists. They *should* be spending their time monitoring routing, throughput, QoS, etc, and not trying to figure out who's sending the letters from Nigeria this week. For a large ISP, the volumne can require the hiring of additional network admins just to deal with those issues.... and that is a real cost. So is the amount of bandwidth that's consumed. And yes, it shows up in higher prices for you, and more aggrivation for me. I just did a quick check on yesterday's mail logs. The proportion of rejected/returned messages to those that I actually accept is almost 6 to 1 - and this is *after* I block open relays from connecting to me at all after the first attempt.
But my biggest beef here is that you make the blanket assumption that no single user need their own mail server.
I wasn't saying that at all. What I said was that there was no NEED for an individual to have one - I didn't say they SHOULDN'T hav
Uh. The whole point of this thread is that having a server is the reason why some people would like to have port 25 open.
No - the reason for this whole thread is that it was said that any ISP that *doesn't* open port 25 shouldn't call themselves an ISP.
Wow. That's a whole heap of wrong speculation.
1. I'm not currently running a mail server.
2. If I did, I doubt it would be on a "vanity-domain."
3. My ISP doesn't block port 25.
4. There is no spew of spam coming from their other customers.
5. You really should calm down.
Then I guess that what's been discussed here doesn't apply to you. And calm isn't an issue.
Slashdot Mirror
And I'm pretty sure that I'm aware of that. If you re-read my original post, you'll see that the point I was making is that T, like Parnas's notation, ignored on rather important requirement of an operating system - that it work reasonably efficiently. The overhead of the microkernel, according to to Linus (and with which I agree), means that the microkernel isn't generally suitable for a general purpose operating system. Yes, what I just said was a gross generalisation, and oversimplification, and I'm aware of that. But Linus point is well taken, I think, and absolutly correct.
..... but you know what? He said the problem would go away back in 1992 when this first came up, when he was expecting 200 MIPS processors the next year ..... and the problem is still with us.
Where my example falls down is that T pooh-poohs performance considerations ("just give it faster hardware"), whereas Parnas never claimed that his notation was for anything other than a notation to prove PROGRAMME correctness, and made NO claims about establishing the SUITABILITY of a programme for any given task whatsoever, as far as I know.
It's also interesting to note that T is still saying that all you have to do is throw faster hardware at it and the problem will go away
Basically, what you're saying is that Parnas' calculus was only strong enough to determine if program X correctly produces the output expected by algorithm Y, without respect to the actual complexity. Is that correct?
.... therefore, the programme was correct.
:-)
:-)
No, actually, you're not. I don't think I made it quite clear, because Parnas' notation was not the main point in my original post.
Parnas' notation dealt with proving that the *implimentation* was mathamatically correct, not the algorythm.
Without re-creating his papers, this is basically how it worked:
Each statement could be reduced to a mathamatical construct that was either true or false for each possible input. Each branching construct had it's own notation. To probe that an IF statement was correct, you would first prove the contents of each branch, and then apply the those results to the branch itself. If the true branch was proved correct, and the false branch was proved correct, then by proving that the IF statment would send control to the proper block for all possible inputs, you could prove that the IF statment was correct.
You would do this for each routine, proving the invididual blocks of code.
Then, given a description of all possible inputs for a given subroutine or function, you could prove that IT was correct, using the previous proofs as "black boxes", if you will.
So you started at the bottom of the programme, rolling the statements up as you went along. Block is proven, branch is proven, routine is proven, and so on, reducing the expressions along the way. The final result of this particular project was a series of mathamatical statements that were a few pages total, that were deomonstrably mathamatically correct
That's a practical description of what he had, anyway - it was a long time, and I'm a programmer, not an computer scientist, so please, people, forget the lack of rigor. I'm just an old fart with a shitty memory
But, then, who said real-time programming when millions of lives are on the line was meant to be fun?
Certainly not the #@(&$@$*#@ sadist that invented the IV&V, that's for sure
Today most of the software that is used to fly planes (both fighter jets and passenger) is based on a microkernel architecture. So microkernels are not just lab toys, real and mission critical systems are run by microkernel architectures.
.... for MOST things, telling somebody that theyr'e going to take a 10-20% hit off the top before they do ANYTHING, compared to the alternatives, is going to get you nothing but doors slammed in your face
.... disingenuous, and again, wrong.
..... and the SYSTEM still has 2.6 million lines of code.
And where did I say that microkernels were unusable? I've personally used QNX and VRTX myself. For small, simple (for the O/s) systems, they're beautifull. As a general purpose coputing platform, they tend not to be.
The speed problem can often be solved just buy getting a faster hardware. The main reason Linus rejected microkernels back in the day was because the cost of context switches was prohibitive. Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines.
Disingenuous, but wrong. Modern computers do a lot more now, typically, then they did then - and so need faster CPUs for the WORKLOAD. I don't care what the application is
Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k. It can already take up to a year to check the correctness of a 8k lines of code microkernel and there will be an exponential demand for resources as the code size increases. So in reality it will not be possible to check the linux kernel for correctness.
Again
Linus has this nice little kernel with 2.6 million lines of code in it
Linus refactors his code so that device drivers, filesystems, etc are outside the kernel, and he has a nice mini-me Linux
What do we have? We STILL have 2.6 million lines of code, but some of them are in the kernel, and the rest of them are OUTSIDE the kernel. SO what magically happens to those bits that were moved out to userland? Did they suddenly become flawless? Of course not - the errors and flaws are still there. Because you do't really CARE about any arbitrary distinction betweeen kernel/userland, do you, as long as you can read from the disk, write to the network, etc. it's the SYSTEM that counts
Secondly, a lot of the things that you're claiming for microkernels - lack of complexity, etc - can be acheived just as simply by how you organise the sorce code FOR the kernel. It used to be called compartmentalisation. Ever hear of it?
Tovarisch Gorshkov, to prove that the program is correct ("covert channel analysis" and such.) might take up to a year and that is only if there are less than 10k lines of code and no more, but that doesn't mean that the program will _run_ slow. The time and methods used to prove correctness don't necessarily say anything about the speed of the program during runtime.
..... but then again, neither did I. Just as some algorythms are faster than others O(n) vs O(log n), etc, some designs are inherently slower than others. And what is a kernel, if not the expression of an (albiet complex) algorythm to accomplish a task (provide system services)?
..... but it's slow by design. There is only so much you can do to speed it up - the limitations are inherent in the message passing mechanisms.
.... and "I haven't bothered proving the sucker" doesn't mean crash and burn.
.... and no easier to do so with with Minix, or BeOS, or any other microkernel.
You're right, it *doesn't* say anything about the code efficiency, or the runtime per se
The microkernel may be more elegant, more pristine in the lab
I'm sorry, I'm with Linux on this one.
Provably correct doesn't mean "good"
Also, there is nothing about a microkernel that makes it more inherently provably correct than a monolithic kernel. Even going back to Parnas' notation that we used years ago, and thinking about the structure of the Linux kernel, it would be pretty easy to go through the exercise and prove it correct/incorrect
Sort of. In the scanerio you describe, the program was, in fact, not proved to be correct because the people who did the proof failed to take into account the real requirements for the system.
If you don't even know your requirements, no methodology to implement those requirements is going to work reliably.
I agree absolutly.
The point I was trying to make - and this is where I see the parallel - is that T seems to be trying to say that microkernel good, monolithic bad based only on elegant design, and theoretical simplicity. No doubt, it appeals to the academic in him (Go figure)
But he is ignoring the "time domain" of an operating system, if you will - it's practicality, it's ability to do usefull work in a reasonable period, and it's usability in the real world - just as Parnas' notation did.
I make no claim as to whether or not Parnas *intended* for his notation to be used for a hard real-time system - I know he was retained as a consultant on the project, but I personally neither saw nor heard of/from him during the entire time. And let me be perfectly clear - his notation was absolutly *gorgeous* and extremly usefull. I, on the other hand, having been the idiot who raised the point in the first place, wound up having to do the timing analysis based on best/worst case sensor timings, and instruction-by-instruction counting of the clock cycles required for each ISR, etc. I plugged the numbers into a programme I wrote for the purpose, and basically did nothing more than an exhaustive analysis of all possible combinations of timings. Not as elegant by far, but what the hell. Who cares if it takes two days to run, if it means you don't have to worry about glowing in the dark?
Provably correct systems will always be better.
..... well, kind of. About 3/4 of the way through the process, I asked a question that nobody else had thought of.
.... but how long will it take?
Well, I could certainly argue THAT one.
Years ago, I was a lead analyst on an IV&V for the shutdown system for a nuclear reactor - specifically, Darlington II in Ontario, Canada.
This was the first time Ontario Hydro wanted to use a computer system for shutdown, instead of the old sensor-relay thingie. This made AECB (Atomic Energy Control Board) rather nervous, as you can understand, so they mandated the IV&V.
I forget his first name - but Parnas from Queen's University in Kingston had developed a calculus to prove the correctness of a programme. It was susinct, it was precice, it was elegant, and it worked wonderfully.
ummmmm
OK, so we prove that the programme is correct, and it'll do what it's supposed to do
You see, everybody had kinda/sorta forgot that this particular programme not only had to be correct, but it had to tell you that the reactor was gonna melt down BEFORE it did, not a week afterwards.
The point is, that there is often much more involved in whether or not a programme (or operating system) is usefull than it's "correctness"
I thought the Canadain way was to use it, and then apologise to the developer for wanting a feature that obviously wasn't necessary, or he would have already written it?
This is absolutly a non-story .... with the plugin for Word/Office/whatever, the ability of ODF applications to work with assistance devices will be - by defination - *exeactly* as good as what it currently is in word.
I used edlin and xedit on control data mainframes, way back in the dark ages. Somewhere around '80-'82 or somesuch.
Not to put to fine a point on it ... but as strongly as they feel about their cause, I wonder if they realise that what they're doing - if used by poeple inside those countries - could get people killed?
I can't help but wonder how zealous they will be if they have to think about the potential blood on their hands.
Doing what you can to help from your end is one thing. Helping somebody become a martyr is another.
To my mind, it's like giving dynamite to a suicide bomber, without thinking about either the bomber or any of his victems.
Dunno about that. Just the time it takes to bring up a socket and get some syn/ack going chews up a good portion of a second. Maybe he was searching a local password database.
:-)
Good point, but you forgot something
He was operating on a 56k dialup line. Wanna drop those numbers a little?
Agreed. I was just trying to make the *general* point. Too many people worry about the l33t way of doing things without taking into consideration the people who will be viewing their pages .... which is the whole point to having a page in the first place.
I think whaty ou've done is entirely appropriate for your application. But let's face it - if you put up a tutorial web page and used that as an example, it would only be a few days before we'd be flooded by 500 meg java pages that did nothing more than change the colour on some background somewhere.
I know about return receipts .... that's why I have them disabled.
Spammers often try to use them to verify the validity of an email address.
Cohn said ISPs would better serve users by quarantining suspect spam messages in special mailboxes. That way, recipients would have the option of checking for false positives. If an ISP does block an e-mail, she says the sender and recipient should be notified and told why.
This is bullshit on so many levels
a) If you return it to the sender, what your'e gonna do is flood some poor schmuck who's email address was picked as random as the "sender" of the email, and really, REALLY piss off the mail server admin for that particular domain.
b) How is it better that instead of me just hitting the del key for spam email that DOES get through, I - as the user - would now have to click on the link in the notice, hit delete to delete the spam email I'm being notified about, and then click delete on the notice itself?
Now, let's assume that 2/3 of all email IS spam (an estimate used in the article) a) You just tripled the amount of disk space the ISP needs on it's mail servers.
b) You just greatly increased the amount of bandwidth the ISP has to dedicate for email. If they don't block, they accept - more bandwidth. Then they send you the notice that it's there in quarrentine - more bandwidth. Then you have to download and read the email - More bandwidth. THen you have to go to that inbox, and delete the email. More bandwidth.
Methinks the fumes that guy's smelling from having his head stuck so far up his arse is affecting is brain function.
I know this doesn't probably apply to you, given your target audience. But what you've done, I think, is generally a bad idea.
Reality check: most of the world (about 80%, if I remember corectly) is still on dialup.
That page comes in at 43K. The same page in HTML would probably be 2/3 less. When you're trying to sell stuff and keep people on your site, the difference between a 2-3 second download and a 8 second download is huge.
Would it necessarily be as "pretty" as the javascript (or php, ajax, or "buzzword") page? Maybe, maybe not - but that's not the point. It doesn't matter wtf the page looks like if nobody's looking.
oh - you're talking about blockign INCOMING port 80.
Look - I'm sorry, folks, but when somebody says "block port XX", I read that it's blocked, in AND out. If you mean incoming, or outgoing please say so?
Many people still use Word97 and are perfectly happy with it and see absolutely no reason to upgrade. If Microsoft wants to introduce a new file format (Office XML) and a new interface at the same time, I see a huge opportunity for OpenOffice to pick up the ball.
Word97? Let's be honest here, folks - 99.99999% of all "documents" are still standard memos & letters that except for the typefaces, don't look any different than they did in the 1980s when the IBM Selectric was the big thing, and CP/M was something that geeks couldn't wait to get their hands on.
And those 99.99999% of all documents could STILL be generated just as efficiently on Wordstar under CP/M, on a Z80 with 64K of memory, as what it is today on a 3.2Ghz XP machine with 2 gig of memory the secretary plays solitaire on during her lunch hour.
Who the hell blocks port 80?
OK - this is the 2nd one like this I've received in the last 5 minites. Could somebody please point out to me where I said ANYTHING about incoming port 25? Please?
MY experience - as I've already stated - is that the ISP's that do block, block both incoming AND outgoing - I've already said that. If your ISP is different, well, they need better administrators.
I know blocking incoming port 25 does nothing. I know blocking outgoing port 25 does a shitload and a half.
Can I make this any more clear?
Wrong. Blocking incoming port 25 does absolutely nothing to prevent spam. Spam has nothing to do with port blocking by many major ISPs. (If they actually cared they would block OUTBOUND port 25 not inbound but only a few do that.)
That's already been addressed in this thread, although it may be below where you've been reading so far.
As a matter of fact ......... yes. I'm gonna have to start paying attention to who's writing what - I didn't expect quite this much of a to-and-fro, and I'll confess it caught me off-guard :-)
Not sure if you noticed, but blocking port 25 doesn't seem to be helping much. All it does is restrict me from recieving email to my personal mail server, not sending it. If you noticed, you can always sent out on 25(generation of spam) but they block incoming 25. So there's no way this will combat spam.
In my experience, most of the ISP's that block port 25 block both incoming AND outgoing, except to their designated smtp servers. That's certainly the way it's been done with any ISP I've used. (Sympatico, Rogers, Cogeco, and Bell here in Canada).
If they don't do it that way, then you're right, it won't do a damned thing - they're just wasting their time
Outside of companies/organisations, the ratio of "people who don't know what a mail server is" to "people who want to run their own" is probably on the order of about 100,000 to 1. For you "1's" out there, for most ISPs, the cost of accomodating you doesn't come anywhere close to the cost of the administrative headaches that arise from the other 99,999. So it's blocked.
The ISP's are not "changing the definition of the internet". They're just making an administrative decision to not support something that the vast majority of their users don't want to save themselves the administrative headache. And they're providers, not resellers.
Why not? There's nothing restricting this technically, other than the bandwidth available to me and IBM. As far as services go, I certainly can offer anything IBM can put online, assuming I'm smart enough.
.... and that is a real cost. So is the amount of bandwidth that's consumed. And yes, it shows up in higher prices for you, and more aggrivation for me. I just did a quick check on yesterday's mail logs. The proportion of rejected/returned messages to those that I actually accept is almost 6 to 1 - and this is *after* I block open relays from connecting to me at all after the first attempt.
No, there isn't any technical reason why you can't - I didn't say there was. I was making the point that just because something is *possible*, doesn't mean that it has to be made available. It's simply a matter of added value for added coin.
Individual users can spam you with viruses whether or not port 25 is open, so your suggested solution is bollocks.
The discussion wasn't about your *receiving* spam, but the ability of spammers to use other machines to SEND spam. SO yes, blocking port 25 does in fact deal with it. No prarie oysters here.
There are some ISP's that will kill your port 25 access if you've got an open relay, but there are a lot of us out there that not only run mail servers from home internet connections with dynamic IP addresses, but we do it much better than some large corporations with so-called "business accounts."
Yes, there are. ANd there are ISPs that don't/wont block them at all, and others that have said screw it - port 25 is blocked for everybody. That's their decision to make.
You're obviously not capable of doing it yourself, but there are a lot of us that are perfectly responsible with our mail servers. I don't need the ISP to limit my access just because someone like you isn't bright enough to handle the responsibility. I've been administering mail systems, internet gateways, web servers, etc since around 1990 as a major part of my job. I DO take responsibility for my servers - and I expect ISPs to do the same for theirs. If they have determined that blocking port 25 is the most effieient way for them to do that, I'm not going to argue with them. It's their choice.
Wow, this is wrong on so many levels. It appears that you don't understand how the internet works. ISPs get put on blacklists usually because they actively support spammers. Sure, there are some screwed-up blacklists that ban ISPs for ludicrous reasons, but that's the nature of the blacklist community and is a problem with the blacklists, not the ports that are available to users. ISPs should be monitoring their networks anyway, so I don't see that as an increased cost.
Actually, I'm very familiar with how the internet works - I've been on the 'net in one form or another since 1982, before it was CALLED the internet, and fast email was two days from here to Paris, if you managed to hit all the hops just right.
Contrary to what you've said, very *few* ISPs activly support spammers - more often than not, it's passive acceptance - refusal to deal with them. If it was just a matter of a "few active supporters", spam wouldn't be a problem - those ISPs would be blocked and the problem would be solved.
As for monitoring their networks, network administrators have many things to do - and monitoring WHAT traffic is going over their lines should be way down on their priority lists. They *should* be spending their time monitoring routing, throughput, QoS, etc, and not trying to figure out who's sending the letters from Nigeria this week. For a large ISP, the volumne can require the hiring of additional network admins just to deal with those issues
But my biggest beef here is that you make the blanket assumption that no single user need their own mail server.
I wasn't saying that at all. What I said was that there was no NEED for an individual to have one - I didn't say they SHOULDN'T hav
Uh. The whole point of this thread is that having a server is the reason why some people would like to have port 25 open.
No - the reason for this whole thread is that it was said that any ISP that *doesn't* open port 25 shouldn't call themselves an ISP.
Wow. That's a whole heap of wrong speculation.
1. I'm not currently running a mail server.
2. If I did, I doubt it would be on a "vanity-domain."
3. My ISP doesn't block port 25.
4. There is no spew of spam coming from their other customers.
5. You really should calm down.
Then I guess that what's been discussed here doesn't apply to you. And calm isn't an issue.