10 out of 10 for the theory, but nil-points for putting this into practice...
1. Sobig/F spread as a.pif attachment. Nowadays if you want to stay ahead of viruses, you configure your mail server to reject these before virus scanning. The anti-virus companies themselves have admitted that they can't keep their definitions up-to-date fast enough to cope with the speed with which this sort of thing spreads. It's only going to get worse.
2. It's not unusual for the reject to be done at SMTP time (with appropriate message). The bounce will hence be generated by the last mail relay with that message, not knowing what it's really doing. Whilst there isn't always a previous relay, it's not always the case and most don't do virus scanning anyway.
I'd really like to see a workable solution - unfortunately this does seem to be tending towards just dropping emails on the floor, or stripping out the payload and letting the email continue on.
1. Have the mail filter properly distinguish between worms that falsify the "From:" address and ones that do not and only send a warning message when the "From:" address is likely to be genuine.
I've seen a lot of discussion on various mailing lists concerning that, but it seems to generally be agreed that this isn't really feasible - especially with emails from some of the large providers. It simply isn't possible to say whether a message legitimately came from the email address stated at the moment. And no, the sending mail server and/or domain gives no real clue.
2. Do not send the alerts at all.
Unfortunately this means that the message gets dropped and you end up with lots of aggrieved people who have believe their messages are getting delivered, when they aren't.
I don't believe the numbers of bounces are really that huge a problem compared with the amount of other spam floating around (*ducks*). Perhaps the language should just be modifed to state that a message purporting to come from the senders address was undeliverable. Otherwise, I can't really see a decent solution.
At least if you have had a bit too much to drink, you can get back home without being pulled over. (It being legal to consume alcohol whilst piloting a boat in the UK).
Gee, isn't oil used to reduce friction or something? Not a whole lot of friction going on in that CPU. I canâ(TM)t really think of any cooling system that uses oil to transfer heat the way water does.
Power transformers are usually oil cooled - requires no maintenance, non-corrosive, doesn't need additives to prevent freezing, etc., etc.
I'll bite - I like a good flamefest on a hot day...
I don't believe that just because the exim code is one binary, and qmail has multiple binaries, makes either better than the other. There are pros and cons to both approaches for this type of application. Certainly exim will run on pretty mediocre hardware and handle a very high volume of traffic with no major headaches. To be honest, on an MTA your performance bottlenecks will be elsewhere.
Not everything mentioned on the mailing list gets into exim; however if it solves a problem then it's likely to be made available as an option. Users are free to compile in the bits of code that they require. Although you can use a stock binary, I find it best to roll my own for any serious application (ie. high load applications).
Since when did the number of users of a product determine how good it is? More people use sendmail than much else - it doesn't make it the best MTA on the planet (flames >/dev/null!)
Looking at security advisories for both MTAs, although exim has slightly more reports than qmail, neither has a significant number, and the count is very close. On security, I'd be happy running either.
I don't know of any stats on bugs overall, but certainly there have never been enough in either product to be of any major concern to me.
They're both good products. Personally the choice of which to use would come down to the application I needed it for.
It takes time for me to read through my mail, and time is money - especially if you get paid on results and not on hours spent. Of course it doesn't take me long to sift through mail discarding all the AOL CD's, but there is still a cost. It also costs to have them carted away once they are in the trash.
I'll stick with the more accepted definition of spam - direct mailings which you have not asked to receive. There are plenty of other more acceptable ways to advertise a product. Marketing droids just need to be a bit more innovative about the methods they use.
Yep - all been done before with the almighty Acorn RiscPCRocketship. This machine was put together to demonstrate the expandability of their case, and the computer as a whole. The case design really was brilliant - I've not really seen anything quite like it since.
I'm not aware of anyone porting the drivers to Linux or Windows however.
True, perhaps my example was not a particularly good one. However, the point I was trying to make that there is a place for extended warranties.
Extended warranties sold with the product can represent poor value. There are other companies however that will sell you an extended warranty, and are generally much cheaper in order to be more competitive with ones sold in stores to a captive audience.
Therefore, over the term of the warranty, you're less likely to receive the money you paid for the warranty back in terms of repair cost than not.
But it's not impossible that you will gain on it. If you want certainty in your life, get insurance. If you can afford to take the risk, then you don't have to.
Insurance started out as a way for merchants to cover the costs if one of their shipments sunk at sea. By grouping together and all paying insurance into a fund, if one of their shipments sunk, the merchant could claim on insurance and wouldn't go out of business.
Insurance is really for when you can't afford the consequences of the loss.
With a computer, or a TV you can usually afford to cover the cost of a loss, so, the odds are in your favor to not buy the warranty.
True. If you don't need the computer, or can afford to have it repaired, then you are probably better off without the warranty. However, if the computer is absolutely important as a tool for your job (eg. as a freelance programmer) and you can't afford a replacement if it fails, then you should get the warranty.
Some warranties are overpriced, and some sales tatics are despicable. In fact, here in Europe the European Comission has been investigating extended warranties and how they are sold.
I don't really see the use of the video record; it shows someone being shot by your gun, but not the circumstances surrounding it. Was it for self defence, or was it pre-meditated? Usually a dead body (or gunshot injury) is enough to tell us that a gun got fired. The only use of the video I guess would be to show where the gun got fired.
Also, the development of a smartcard that must be near the gun when it is fired doesn't fill me with confindence that the biometric sensors are up to much!
Having GPS and video for military applications could be useful - by I imagine the military already have something along these lines with the development of all the next generation soldier programmes that have been going on.
It will be interesting to see if DRM makes an appearance in other office suites, especially the ones available for Linux.
Make no mistake - corporates will like this functionality. If Linux wants to compete on the desktop in an corporate environment, then some form of DRM may have to make an appearance.
On the other hand, as evidenced by the comments here, most open source advocates hate the idea of DRM in documents or other files.
I'm afraid that DRM may well start making an appearance in packages we know and love. I'm sure the implementation will be well done, but I believe that it will inevitably make an appearance, no matter how flawed everyone thinks the idea is.
In Europe, I can leave the UK and travel to damn near any other European country, and use the same phone. If you want to phone me, in Romania, dial the international dialling code for Romania then my mobile number.
Wrong. If you have a UK phone, and travel abroad, callers still dial your UK number (ie. the UK country code). They don't have to take account of what country you are in (and frequently will not even know!).
I believe the US use 1900MHz because they are in ITU region 1, and 1800MHz over there is assigned to something else (Europe is ITU region 2). Tri-band phones are so common now that the exact frequencies used are pretty irrelevant (1800 and 1900Mhz signals having roughly the same properties).
It would be useful for the US to be completly GSM based, as then everyone can move back and forth more easily. I see GSM a bit like the PC standard - it may not be the best system possible, but by been so common the hardware/software costs are very low. However, the US is a large enough market to support it's own standards and realise economy of scale (although having 4 standards is perhaps going a bit far!)
In Europe we have regulations to prevent this - stipulation on maximum working week etc. However, in the way the regulations were implemented in the UK, it's standard practice for everyone to sign a contract that allows overtime working with no fixed maximum.
So, if it did get too much, you would have to quit and probably work your termination period. There would probably be little to gain trying to argue the contract in court at that point.
I suspect that, even if there is a similar law in the US (or elsewhere), it would always have been implemented in an "optional" way to appease the large corporates.
I agree. I'd also add though that this type of legal case will go on for a number of years (perhaps even before reaching court). At that point, MS will be making so much cash out of DRM from charges to copyright owners that the size of the settlement will seem small in comparison to their profits.
Hence, although MS will be taking it seriously, I don't think they are panicing at all.
You have assumed that a commerical company will support you for the ten year lifecycle of the project. However, it is very likely that the commerical company will fold or discontinue the product during those ten years. After that you will be unable to fix problems or add features as you will not have access to the source code.
Only an open source product is guaranteed to be supportable for the full ten years of the project. Even if the development team for the product get bored and leave, anyone sufficiently skilled will be able to step in at anytime and make modifications or changes.
The community that uses the product will quite likely start supporting it themselves (if they aren't already). Or of course your employee may be able to make small changes even if they are not the greatest developer on the planet.
So, from your list, in order to fulfill your brief correctly, you should really be looking only at open source products (commerical or free).
I do wonder if some people have ever worked in the real world. When developing an application, performance is only one factor. In fact, usually it's quite far down the list of wants when choosing a platform.
If the performance isn't great, then you can (within reason) add more hardware. Given the cost of hardware, it's not too expensive to do that.
However, if the application is difficult to maintain, or the skills aren't there to do so (or only available at a large premium), then significant effort (and therefore money) will have to be spent over the lifetime of the system. On any reasonably sized system, these costs will easily surpass the hardware/software costs.
It all goes back to that lovely 90's acronym - TCO. I'm not arguing for either side, just stating that performance isn't really a major consideration in the areas that EJB and similar systems are deployed.
I'm sure you are correct for the US, but for the UK they do have a phone number - and, in my experience, it's better than the email support.
I recently ordered some video tapes, and one was blank after the first five minutes. Initially I tried their email support, but spent a week receiving just form emails that didn't answer the question.
So I gave them a call (expecting to be on hold for ages) but got answered within a minute and had new tapes sent over next day.
Next time I have a problem of course, I'll call first rather than email - which won't do much for their bottom line.
I agree. I've gone from working on the technical side through to being a Project Manager.
Good "Technical Project Managers" are always in demand - their projects tend to run smoother and be more successful. I've know how important technical design, testing time, code review and education are - and will always fight for that whenever budgets/schedule is discussed. A good Technical Project Manager can foresee much better the problems that are going to be encountered, and ensure that they get resolved as early as possible.
We do also have some traditional Project Managers who work with Technical Leaders - it works to an extent, but it's not as good.
The downside is that you will have to spend a lot of time keeping up with the technology, as well as your training in managing projects. It's a tougher job with more responsibility - but the salaries are correspondingly higher.
The McConnell books are good. The Rapid Application Development book is quite a good read for picking up useful techniques and tips. The case studies are especially a good laugh as we've all seen them before:-)
...on what you are writing. I use Java for a lot of work, but I wouldn't use it for anything that needed a *lot* of speed, or low level hardware access. However, Java does have a rich API and good portability.
The best solution is ultimately probably using two languages - perhaps Java for interface work / portability, but also C for anything that needs to interface to hardware, or needs the performance. I'm only using Java and C as examples - but other languages are the same.
Most languages can't do everything. Pick the best for the task required and the skills available.
1. This is engineering; the solution should be developed as a whole - ie. the hardware and software should be selected from the best available to solve the problem. The solution should then be developed, tested and deployed without changing the game halfway through.
2. Too often developers and their companies see themselves as subservient to their clients. This is the wrong attitude - development should be done as a partnership between client and supplier with both equal. Both client and supplier are much better for it if the supplier is honest with the client. The client is employing you for your skills and knowledge - if they don't at least consider your recommendations, then they are wasting their money.
The client may have good reasons for choosing Windows - but testing on Windows and then changing to Unix is quite clearly a recipe for disaster.
Sorry, but I can see right now that this is very likely to be a project that is going to go wrong. The system has to be tested as a whole - that means using the same users, hardware and software throughout development, testing, deployment and into maintenance.
I agree - I think its a scam: > $ telnet eternity.cs.umass.edu > Trying 128.119.41.46... > Connected to eternity.cs.umass.edu. > Escape character is '^]'. > > > Digital UNIX (eternity.cs.umass.edu) (ttyp3) > > login:...nice one guys, but its not April Fool for a while yet;-)
Slashdot Mirror
10 out of 10 for the theory, but nil-points for putting this into practice...
.pif attachment. Nowadays if you want to stay ahead of viruses, you configure your mail server to reject these before virus scanning. The anti-virus companies themselves have admitted that they can't keep their definitions up-to-date fast enough to cope with the speed with which this sort of thing spreads. It's only going to get worse.
1. Sobig/F spread as a
2. It's not unusual for the reject to be done at SMTP time (with appropriate message). The bounce will hence be generated by the last mail relay with that message, not knowing what it's really doing. Whilst there isn't always a previous relay, it's not always the case and most don't do virus scanning anyway.
I'd really like to see a workable solution - unfortunately this does seem to be tending towards just dropping emails on the floor, or stripping out the payload and letting the email continue on.
I've seen a lot of discussion on various mailing lists concerning that, but it seems to generally be agreed that this isn't really feasible - especially with emails from some of the large providers. It simply isn't possible to say whether a message legitimately came from the email address stated at the moment. And no, the sending mail server and/or domain gives no real clue.
Unfortunately this means that the message gets dropped and you end up with lots of aggrieved people who have believe their messages are getting delivered, when they aren't.
I don't believe the numbers of bounces are really that huge a problem compared with the amount of other spam floating around (*ducks*). Perhaps the language should just be modifed to state that a message purporting to come from the senders address was undeliverable. Otherwise, I can't really see a decent solution.
At least if you have had a bit too much to drink, you can get back home without being pulled over. (It being legal to consume alcohol whilst piloting a boat in the UK).
Gee, isn't oil used to reduce friction or something? Not a whole lot of friction going on in that CPU. I canâ(TM)t really think of any cooling system that uses oil to transfer heat the way water does.
Power transformers are usually oil cooled - requires no maintenance, non-corrosive, doesn't need additives to prevent freezing, etc., etc.
I'll bite - I like a good flamefest on a hot day...
/dev/null!)
I don't believe that just because the exim code is one binary, and qmail has multiple binaries, makes either better than the other. There are pros and cons to both approaches for this type of application. Certainly exim will run on pretty mediocre hardware and handle a very high volume of traffic with no major headaches. To be honest, on an MTA your performance bottlenecks will be elsewhere.
Not everything mentioned on the mailing list gets into exim; however if it solves a problem then it's likely to be made available as an option. Users are free to compile in the bits of code that they require. Although you can use a stock binary, I find it best to roll my own for any serious application (ie. high load applications).
Since when did the number of users of a product determine how good it is? More people use sendmail than much else - it doesn't make it the best MTA on the planet (flames >
Looking at security advisories for both MTAs, although exim has slightly more reports than qmail, neither has a significant number, and the count is very close. On security, I'd be happy running either.
I don't know of any stats on bugs overall, but certainly there have never been enough in either product to be of any major concern to me.
They're both good products. Personally the choice of which to use would come down to the application I needed it for.
Part four has a car called a "Ford Prefect" :-) Was that in the original script then?
It takes time for me to read through my mail, and time is money - especially if you get paid on results and not on hours spent. Of course it doesn't take me long to sift through mail discarding all the AOL CD's, but there is still a cost. It also costs to have them carted away once they are in the trash.
I'll stick with the more accepted definition of spam - direct mailings which you have not asked to receive. There are plenty of other more acceptable ways to advertise a product. Marketing droids just need to be a bit more innovative about the methods they use.
I'm not aware of anyone porting the drivers to Linux or Windows however.
Extended warranties sold with the product can represent poor value. There are other companies however that will sell you an extended warranty, and are generally much cheaper in order to be more competitive with ones sold in stores to a captive audience.
I don't really see the use of the video record; it shows someone being shot by your gun, but not the circumstances surrounding it. Was it for self defence, or was it pre-meditated? Usually a dead body (or gunshot injury) is enough to tell us that a gun got fired. The only use of the video I guess would be to show where the gun got fired.
Also, the development of a smartcard that must be near the gun when it is fired doesn't fill me with confindence that the biometric sensors are up to much!
Having GPS and video for military applications could be useful - by I imagine the military already have something along these lines with the development of all the next generation soldier programmes that have been going on.
It will be interesting to see if DRM makes an appearance in other office suites, especially the ones available for Linux.
Make no mistake - corporates will like this functionality. If Linux wants to compete on the desktop in an corporate environment, then some form of DRM may have to make an appearance.
On the other hand, as evidenced by the comments here, most open source advocates hate the idea of DRM in documents or other files.
I'm afraid that DRM may well start making an appearance in packages we know and love. I'm sure the implementation will be well done, but I believe that it will inevitably make an appearance, no matter how flawed everyone thinks the idea is.
In Europe, I can leave the UK and travel to damn near any other European country, and use the same phone. If you want to phone me, in Romania, dial the international dialling code for Romania then my mobile number.
Wrong. If you have a UK phone, and travel abroad, callers still dial your UK number (ie. the UK country code). They don't have to take account of what country you are in (and frequently will not even know!).
I believe the US use 1900MHz because they are in ITU region 1, and 1800MHz over there is assigned to something else (Europe is ITU region 2). Tri-band phones are so common now that the exact frequencies used are pretty irrelevant (1800 and 1900Mhz signals having roughly the same properties).
It would be useful for the US to be completly GSM based, as then everyone can move back and forth more easily. I see GSM a bit like the PC standard - it may not be the best system possible, but by been so common the hardware/software costs are very low. However, the US is a large enough market to support it's own standards and realise economy of scale (although having 4 standards is perhaps going a bit far!)
US, Europe, somewhere else?
In Europe we have regulations to prevent this - stipulation on maximum working week etc. However, in the way the regulations were implemented in the UK, it's standard practice for everyone to sign a contract that allows overtime working with no fixed maximum.
So, if it did get too much, you would have to quit and probably work your termination period. There would probably be little to gain trying to argue the contract in court at that point.
I suspect that, even if there is a similar law in the US (or elsewhere), it would always have been implemented in an "optional" way to appease the large corporates.
I agree. I'd also add though that this type of legal case will go on for a number of years (perhaps even before reaching court). At that point, MS will be making so much cash out of DRM from charges to copyright owners that the size of the settlement will seem small in comparison to their profits.
Hence, although MS will be taking it seriously, I don't think they are panicing at all.
You have assumed that a commerical company will support you for the ten year lifecycle of the project. However, it is very likely that the commerical company will fold or discontinue the product during those ten years. After that you will be unable to fix problems or add features as you will not have access to the source code.
Only an open source product is guaranteed to be supportable for the full ten years of the project. Even if the development team for the product get bored and leave, anyone sufficiently skilled will be able to step in at anytime and make modifications or changes.
The community that uses the product will quite likely start supporting it themselves (if they aren't already). Or of course your employee may be able to make small changes even if they are not the greatest developer on the planet.
So, from your list, in order to fulfill your brief correctly, you should really be looking only at open source products (commerical or free).
I do wonder if some people have ever worked in the real world. When developing an application, performance is only one factor. In fact, usually it's quite far down the list of wants when choosing a platform.
If the performance isn't great, then you can (within reason) add more hardware. Given the cost of hardware, it's not too expensive to do that.
However, if the application is difficult to maintain, or the skills aren't there to do so (or only available at a large premium), then significant effort (and therefore money) will have to be spent over the lifetime of the system. On any reasonably sized system, these costs will easily surpass the hardware/software costs.
It all goes back to that lovely 90's acronym - TCO. I'm not arguing for either side, just stating that performance isn't really a major consideration in the areas that EJB and similar systems are deployed.
I'm sure you are correct for the US, but for the UK they do have a phone number - and, in my experience, it's better than the email support.
I recently ordered some video tapes, and one was blank after the first five minutes. Initially I tried their email support, but spent a week receiving just form emails that didn't answer the question.
So I gave them a call (expecting to be on hold for ages) but got answered within a minute and had new tapes sent over next day.
Next time I have a problem of course, I'll call first rather than email - which won't do much for their bottom line.
I agree. I've gone from working on the technical side through to being a Project Manager.
:-)
Good "Technical Project Managers" are always in demand - their projects tend to run smoother and be more successful. I've know how important technical design, testing time, code review and education are - and will always fight for that whenever budgets/schedule is discussed. A good Technical Project Manager can foresee much better the problems that are going to be encountered, and ensure that they get resolved as early as possible.
We do also have some traditional Project Managers who work with Technical Leaders - it works to an extent, but it's not as good.
The downside is that you will have to spend a lot of time keeping up with the technology, as well as your training in managing projects. It's a tougher job with more responsibility - but the salaries are correspondingly higher.
The McConnell books are good. The Rapid Application Development book is quite a good read for picking up useful techniques and tips. The case studies are especially a good laugh as we've all seen them before
...on what you are writing. I use Java for a lot of work, but I wouldn't use it for anything that needed a *lot* of speed, or low level hardware access. However, Java does have a rich API and good portability.
The best solution is ultimately probably using two languages - perhaps Java for interface work / portability, but also C for anything that needs to interface to hardware, or needs the performance. I'm only using Java and C as examples - but other languages are the same.
Most languages can't do everything. Pick the best for the task required and the skills available.
1. This is engineering; the solution should be developed as a whole - ie. the hardware and software should be selected from the best available to solve the problem. The solution should then be developed, tested and deployed without changing the game halfway through.
2. Too often developers and their companies see themselves as subservient to their clients. This is the wrong attitude - development should be done as a partnership between client and supplier with both equal. Both client and supplier are much better for it if the supplier is honest with the client. The client is employing you for your skills and knowledge - if they don't at least consider your recommendations, then they are wasting their money.
The client may have good reasons for choosing Windows - but testing on Windows and then changing to Unix is quite clearly a recipe for disaster.
Sorry, but I can see right now that this is very likely to be a project that is going to go wrong. The system has to be tested as a whole - that means using the same users, hardware and software throughout development, testing, deployment and into maintenance.
I agree - I think its a scam: > $ telnet eternity.cs.umass.edu > Trying 128.119.41.46... > Connected to eternity.cs.umass.edu. > Escape character is '^]'. > > > Digital UNIX (eternity.cs.umass.edu) (ttyp3) > > login: ...nice one guys, but its not April Fool for a while yet ;-)