While I am always inclined to root for wrinklies befuddled by technology, I think this objection is a non-starter. I don't want to receive spam at all - even if it is sent from someone's grandmother's computer. This warranty situation would work fantastically as once Granny's computer has been compromised the hacker would only be able to send a few emails before running out of escarow funds - and simultaneously open himself up for criminal prosecution for wire fraud. Sure it would be inconvenient to loose the escarow funds - but this has to be balanced against Granny feeling confident that none of her actions (no matter how ill conceived) have inadvertently annoyed her neighbours.
I see a potential problem with viruses emptying escarow accounts. However, if collecting from escarow accounts in cash requires a personal appearance, this offers a golden opportunity for law enforcement to arrest the criminal conspirator. In addition I can see that such a system would be extremely helpful in bringing pressure to bear on operating system vendors to take security seriously - especially if disgruntled customers could seek realistic damages for negligent practices among suppliers.
I disagree with your position. The fundamentally different thing about this warranty idea is that it presents a payment system which would permit cost free maintenance of legitimate mailing lists. When a user wishes to subscribe to a mailing list they send an email with warranty to the list maintainer, who claims (or puts this sum in permanent limbo) the warranty funds, which should exceed the warranty demands of the subscriber. The subscriberwould then remain subscribed at no additional cost until such time as they either request to unsubscribe (under which circumstances the funds are released back to them) or they claim the warranty on an email sent on the list... which would be detected by the list maintainer and effect a termination of the subscription. I personally suspect a very low warranty value would prove remarkably effective... $1 associated with each of millions of spam messages would get expensive, whereas tying up $20 for a typical user with only a handful of messages in limbo at any one time is unlikely to be a significant burden.
I agree that the infrastructure would be considerable - but I for one, remembering how useful email was a decade ago, would be willing to pay whatever it takes to establish a system in which any individual can contact me easily but where a few dozen arrogant cretins don't bother me every few hours with their typically criminal mass mailed proposals. I like the idea of warranties far more than I like the idea of micro-payments which (in my opinion) are likely to prove a far more significant burden for honest email users.
I've got the latest OO.org development build - but Word spelling/grammar tools beat it hands down - unfortunately - as in many other respects I find OO.org superior. I was lead to believe that both the Opera and Mozilla mail clients had no equivalent spelling/grammar support to that in Outlook/Word - and feel doubtful about the support for Exchange. Sure - with any exchange alternative things would be less restrictive - but for the foreseeable future many are "shackled-to-history."
While risking a lampooning from the Slashdot crowd - I use both IE and Outlook - though I have to admit that as a result of this story I've been tempted to try Firebird again. To be honest, it has improved greatly and I'm now giving it another shot.
Outlook is less easy to replace... I've a target platform of XP, and need to interact with an exchange server. While I hate the clunky configuration, gaping security flaws and slow bloated memory-hogging Outlook, I have to admit that I find Word a very effective productivity tool when writing prose - even though it is a sledgehammer to crack a nut. I only want to send ASCII mail, but I want real-time spelling and grammar checking. When will open source catch up on this front?
If I were to put on my devils advocate hat, I'd have to ask if you think this would be a smart way for SCO management to pay off a SCO employee for other services rendered?
I wholeheartedly agree - I can't see the benefit in sending someone with lax morals to a prison where the only likely outcome I can envision is to provide an education in other criminal activity. Wouldn't it be best to associate the punishment with the crime? The real crime here is the wilful manner in which spammers misappropriate resources and waste users' time. I would advocate a fine equivalent to first class postage for each individual instance of spam, combined with a one-minute community service order - hence, the offender would contribute back to society on a scale directly related to the original misdeed. Under this scheme, a spammer sending 1000 emails in the UK would have a GBP 280 fine and have to perform community service work for two days. Conversely, a spammer sending a million messages would get a fine of GBP 280,000 and serve the community for about 5 years - which seems perfectly reasonable to me.
I see where you are coming from, however I felt more forgiving about the second point - maybe because the recommendation was more vague. The original poster (grammar aside) suggested that SQL generation should be separated from UI interaction - and this is, IMHO, usually a very good idea. No-one suggested "all SQL should be done at the back end;" Only you seem to think that six times the volume of code would necessarily be required for such a separation; only you suggest that a boss would disagree - and I doubt, at this stage, anyone needs their "sorry ass" fired.
When considering complex systems, architecture is important. Sure, it is often possible to cut corners on trivial systems, but a good programmer will always remember that the system should be easily explicable in order for it to remain maintainable. While 3-tier architectures could be just as poorly implemented as single tier or client-server solutions, there is a wealth of empirical evidence to suggest that 3-tier designs have been a significant benefit in many complex systems. In my opinion, as a rule of thumb, it is a good idea to separate UI implementation from SQL interaction - particularly for applications to be used in adversarial environments. Even ignoring your distaste for the 3-tier paradigm (which I admit is by no means a cure-all design) there remain many other techniques to logically separate SQL generation from UI interactions. I have never in practice seen the need to expose all of the functionality of the often bloated and complex SQL implementations to code primarily concerned with UI interaction... I frequently see myriad benefits in encapsulation.
While I agree with point 2, I can only say that point 1 is at best misguided nonsense and at worst a troll. If an attacker is able to overrun a buffer by a few bytes, then they are likely able to over-run by more than the 1K for which you've allowed. This technique is likely to give a false sense of confidence in an implementation as well as cause bloat - hence negating at least some of the advantages of the costly decision to implement at a low level permitting pointer arithmetic. There are much better ways to tackle such problems. In many cases C/C++ programmers should take a leaf from Java programmers and avoid pointer arithmetic in mainline code. It is trivial to code an ADT for arrays/strings in C, and C++ programmers should really consider STL containers. Only extremely low level code ever need directly manipulate pointers - and the cost of interacting at this level should be a moral obligation to show, using appropriate techniques such as pre-condition/post-condition inductive proofs, that buffer overruns are not possible.
(Yes I suck when I speedy-drafts: like I blow at speed-chess 8-)
A herd of monkeys would be able to produce the complete works of Shakespeare substantially more quickly if they were to use Word instead of their outdated typewriters!
I'm sad to say I'll to remain a Word advocate until OO supports grammar checking. While I agree that OO is usable, I really miss the squiggly green lines when I edit a paragraph (in a rush) and scramble it to nonsense. A gobbledegook indicatior vastly improves the quality of first draft documents and, to me is a must-have feature.
While I guess most may suggest blatant advertising isn't OK, I'd be very intrigued to know who's selling this kind of cheap box here in the UK.
I'm looking for a supplier of cheap, but reliable, PCs for use as redundant servers - minimum spec:
800Mhz+ VIA/Duron etc. (Processor speed not very important)
256Mb PC133 RAM (or better)
30+Gb H/D (Pref 7200, but 5400 would be OK)
USB support
100Mbps Ethernet
PCI slot for ADSL/Modem/2nd Ethernet card.
CDRW drive.
I don't need a keyboard/mouse/monitor... I am interested in reliability and size.. and would prefer pre-built. My instinct suggests that this should be available for c. £200, but I'm yet to find a credible supplier.
I've often wondered about the most effective ways to lay-out files on a block device. While there are many obvious solutions, it seems, to my mind at least, a hard problem to determine an optimal solution. Assuming file-system goals include:
Minimizing Inner/Outer fragmentation
Maximising locality of reference
Minimizing the cost of file extension
I'd like to know how Reiser FS approached these conflicting goals. Has Reiser FS used any mathematical models to evaluate long-term stability/performance?
Indeed, it looked that way to me - Harlequin's was a project ripe with optimisim which steadily evaporated as real-world developers continued to do battle with less adventurous languages. As I remember it, at least.
I'd intended a "?" in my title (but bungled) - hoping to prompt some comment about the differences between the systems. Wasn't Harlequin's based on SML not oCAML?
I wonder if F# has any relationship to the "ML for Microsoft" (I forget the name) efforts from Harlequin Software a few years ago? ML has always seemed an ideal fit for many single-user RAD developments, it just needed an appropriately stable, complete, clearly specified component library and professional quality IDE in order to reap productivity benefits over Java/C# et al.
Somebody had to stop this form of intellectual theft - the music business has done everything within their power to prevent the derisory practice of unlicensed shower performances - nonsense rhymes by artists with poor articulation etc. Clearly something had to be done or risk the entire population embarking on a karaoke binge.
I'm interested... though I have to say that I'm at least sceptical it's even possible to store state without degrading performance in the general case. (I can't see any way you can overcome the cost of bandwidth to stable storage.)
I'm very interested in the idea of designing new kinds of reliable store (if anything in IT can be really new these days!) I've even tinkered with this myself. The hash-table-like store is of particular interest to me... I guess this is done using trees in a way reminiscent of the grand plans Will Phillips discussed for the Tux2 file system. Do you have some URLs for papers/prototypes?
I wonder... is there a meaningful distinction between ROC and the classical holy-grail of ACID systems(i.e. systems which meet Atomic, Consistent, Isolated and Durable assumptions commonly cited in the realm of commercial RDBMS?) Apart from the 'swish' buzzword re-name that isn't even an acronym?
Professionals in the field, while usually in agreement about the desirability of systems which pass the ACID test, most admit that while the concepts are well understood, the real-world cost of the additional software complexity often precludes strict ACID compliance in typical systems. I would certainly be interested if there were more to ROC than evaluating the performance of existing well understood ACID-related techniques but can't find anything more than the "hype." For example, has ROC suggested designs to resolve distributed incoherence due to hardware failure? Classified non-trivial architectures immune to various classes of failure? Discovered a cost effective approach to ACID?
I'm intrigued... some of your arguments against EFS are obvious - (such as the idea that once you've got the physical disk if it's not hard to discover the EFS certificate used for reading - hence the encryption is pointless.) This makes perfect sense - I suspect this issue can be addressed (to some extent) using physically secured domain controllers. However I would like to know your source of information regarding this issue that files are decrypted when open. Do you mean by this that the whole file is written back to disk in plaintext form, or do you mean that only the in-memory copy (which obviously may be swapped out at some stage) is decrypted? Do you have references for this assertion?
Slashdot Mirror
While I am always inclined to root for wrinklies befuddled by technology, I think this objection is a non-starter. I don't want to receive spam at all - even if it is sent from someone's grandmother's computer. This warranty situation would work fantastically as once Granny's computer has been compromised the hacker would only be able to send a few emails before running out of escarow funds - and simultaneously open himself up for criminal prosecution for wire fraud. Sure it would be inconvenient to loose the escarow funds - but this has to be balanced against Granny feeling confident that none of her actions (no matter how ill conceived) have inadvertently annoyed her neighbours.
I see a potential problem with viruses emptying escarow accounts. However, if collecting from escarow accounts in cash requires a personal appearance, this offers a golden opportunity for law enforcement to arrest the criminal conspirator. In addition I can see that such a system would be extremely helpful in bringing pressure to bear on operating system vendors to take security seriously - especially if disgruntled customers could seek realistic damages for negligent practices among suppliers.
I disagree with your position. The fundamentally different thing about this warranty idea is that it presents a payment system which would permit cost free maintenance of legitimate mailing lists. When a user wishes to subscribe to a mailing list they send an email with warranty to the list maintainer, who claims (or puts this sum in permanent limbo) the warranty funds, which should exceed the warranty demands of the subscriber. The subscriberwould then remain subscribed at no additional cost until such time as they either request to unsubscribe (under which circumstances the funds are released back to them) or they claim the warranty on an email sent on the list... which would be detected by the list maintainer and effect a termination of the subscription. I personally suspect a very low warranty value would prove remarkably effective... $1 associated with each of millions of spam messages would get expensive, whereas tying up $20 for a typical user with only a handful of messages in limbo at any one time is unlikely to be a significant burden.
I agree that the infrastructure would be considerable - but I for one, remembering how useful email was a decade ago, would be willing to pay whatever it takes to establish a system in which any individual can contact me easily but where a few dozen arrogant cretins don't bother me every few hours with their typically criminal mass mailed proposals. I like the idea of warranties far more than I like the idea of micro-payments which (in my opinion) are likely to prove a far more significant burden for honest email users.
I've got the latest OO.org development build - but Word spelling/grammar tools beat it hands down - unfortunately - as in many other respects I find OO.org superior. I was lead to believe that both the Opera and Mozilla mail clients had no equivalent spelling/grammar support to that in Outlook/Word - and feel doubtful about the support for Exchange. Sure - with any exchange alternative things would be less restrictive - but for the foreseeable future many are "shackled-to-history."
While risking a lampooning from the Slashdot crowd - I use both IE and Outlook - though I have to admit that as a result of this story I've been tempted to try Firebird again. To be honest, it has improved greatly and I'm now giving it another shot.
Outlook is less easy to replace... I've a target platform of XP, and need to interact with an exchange server. While I hate the clunky configuration, gaping security flaws and slow bloated memory-hogging Outlook, I have to admit that I find Word a very effective productivity tool when writing prose - even though it is a sledgehammer to crack a nut. I only want to send ASCII mail, but I want real-time spelling and grammar checking. When will open source catch up on this front?
If I were to put on my devils advocate hat, I'd have to ask if you think this would be a smart way for SCO management to pay off a SCO employee for other services rendered?
I wholeheartedly agree - I can't see the benefit in sending someone with lax morals to a prison where the only likely outcome I can envision is to provide an education in other criminal activity. Wouldn't it be best to associate the punishment with the crime? The real crime here is the wilful manner in which spammers misappropriate resources and waste users' time. I would advocate a fine equivalent to first class postage for each individual instance of spam, combined with a one-minute community service order - hence, the offender would contribute back to society on a scale directly related to the original misdeed. Under this scheme, a spammer sending 1000 emails in the UK would have a GBP 280 fine and have to perform community service work for two days. Conversely, a spammer sending a million messages would get a fine of GBP 280,000 and serve the community for about 5 years - which seems perfectly reasonable to me.
Is there a Win32 binary (installer?) available for GIMP 2.0?
I see where you are coming from, however I felt more forgiving about the second point - maybe because the recommendation was more vague. The original poster (grammar aside) suggested that SQL generation should be separated from UI interaction - and this is, IMHO, usually a very good idea. No-one suggested "all SQL should be done at the back end;" Only you seem to think that six times the volume of code would necessarily be required for such a separation; only you suggest that a boss would disagree - and I doubt, at this stage, anyone needs their "sorry ass" fired.
When considering complex systems, architecture is important. Sure, it is often possible to cut corners on trivial systems, but a good programmer will always remember that the system should be easily explicable in order for it to remain maintainable. While 3-tier architectures could be just as poorly implemented as single tier or client-server solutions, there is a wealth of empirical evidence to suggest that 3-tier designs have been a significant benefit in many complex systems. In my opinion, as a rule of thumb, it is a good idea to separate UI implementation from SQL interaction - particularly for applications to be used in adversarial environments. Even ignoring your distaste for the 3-tier paradigm (which I admit is by no means a cure-all design) there remain many other techniques to logically separate SQL generation from UI interactions. I have never in practice seen the need to expose all of the functionality of the often bloated and complex SQL implementations to code primarily concerned with UI interaction... I frequently see myriad benefits in encapsulation.
While I agree with point 2, I can only say that point 1 is at best misguided nonsense and at worst a troll. If an attacker is able to overrun a buffer by a few bytes, then they are likely able to over-run by more than the 1K for which you've allowed. This technique is likely to give a false sense of confidence in an implementation as well as cause bloat - hence negating at least some of the advantages of the costly decision to implement at a low level permitting pointer arithmetic. There are much better ways to tackle such problems. In many cases C/C++ programmers should take a leaf from Java programmers and avoid pointer arithmetic in mainline code. It is trivial to code an ADT for arrays/strings in C, and C++ programmers should really consider STL containers. Only extremely low level code ever need directly manipulate pointers - and the cost of interacting at this level should be a moral obligation to show, using appropriate techniques such as pre-condition/post-condition inductive proofs, that buffer overruns are not possible.
Cool - then slashdotites can code en-route!
"The test could also lead to lower premiums."
Translation: "Could but most likely won't."
"Tax doesn't have to be taxing." (Infuriating UK IRS advert)
Translation "We've no excuse for the shoddy inexplicably complex mess."
"You could win a MILLION."
Translation: "You could win if we had ever intended to pay out."
None of the statements are false - just a little misleading.
And the inexplicable, unmistakable American style of the reprints?
"Word!" to grandmas everywhere!
(Yes I suck when I speedy-drafts: like I blow at speed-chess 8-)
A herd of monkeys would be able to produce the complete works of Shakespeare substantially more quickly if they were to use Word instead of their outdated typewriters!
I'm sad to say I'll to remain a Word advocate until OO supports grammar checking. While I agree that OO is usable, I really miss the squiggly green lines when I edit a paragraph (in a rush) and scramble it to nonsense. A gobbledegook indicatior vastly improves the quality of first draft documents and, to me is a must-have feature.
Are there any plans for something similar in OO?
While I guess most may suggest blatant advertising isn't OK, I'd be very intrigued to know who's selling this kind of cheap box here in the UK.
I'm looking for a supplier of cheap, but reliable, PCs for use as redundant servers - minimum spec:
800Mhz+ VIA/Duron etc. (Processor speed not very important)
256Mb PC133 RAM (or better)
30+Gb H/D (Pref 7200, but 5400 would be OK)
USB support
100Mbps Ethernet
PCI slot for ADSL/Modem/2nd Ethernet card.
CDRW drive.
I don't need a keyboard/mouse/monitor... I am interested in reliability and size.. and would prefer pre-built. My instinct suggests that this should be available for c. £200, but I'm yet to find a credible supplier.
Use a secure hash.
In order to put my address on the "don't email me unless I request it explicitly" list I compute an MD5 hash and submit it to a central repository.
Zionism
- Minimizing Inner/Outer fragmentation
- Maximising locality of reference
- Minimizing the cost of file extension
I'd like to know how Reiser FS approached these conflicting goals. Has Reiser FS used any mathematical models to evaluate long-term stability/performance?- Zero effort extra layer of PC security â" âoeCanâ(TM)t handshake my phone â" it probably isnâ(TM)t me⦠require full authentication.â
- Blue-tooth car radio â" jump in a car with a phone and it automatically negotiates that calls should be played through the sound system.
- Dial land-line calls from my mobile (no more squint-dial, squint-dial etc) â" no worries about controlling your neighbours phone!
- Locate people by mobile in hot-desk environments.
Iâ(TM)m sure there are more!Indeed, it looked that way to me - Harlequin's was a project ripe with optimisim which steadily evaporated as real-world developers continued to do battle with less adventurous languages. As I remember it, at least.
I'd intended a "?" in my title (but bungled) - hoping to prompt some comment about the differences between the systems. Wasn't Harlequin's based on SML not oCAML?
I wonder if F# has any relationship to the "ML for Microsoft" (I forget the name) efforts from Harlequin Software a few years ago? ML has always seemed an ideal fit for many single-user RAD developments, it just needed an appropriately stable, complete, clearly specified component library and professional quality IDE in order to reap productivity benefits over Java/C# et al.
Somebody had to stop this form of intellectual theft - the music business has done everything within their power to prevent the derisory practice of unlicensed shower performances - nonsense rhymes by artists with poor articulation etc. Clearly something had to be done or risk the entire population embarking on a karaoke binge.
I'm very interested in the idea of designing new kinds of reliable store (if anything in IT can be really new these days!) I've even tinkered with this myself. The hash-table-like store is of particular interest to me... I guess this is done using trees in a way reminiscent of the grand plans Will Phillips discussed for the Tux2 file system. Do you have some URLs for papers/prototypes?
I wonder... is there a meaningful distinction between ROC and the classical holy-grail of ACID systems(i.e. systems which meet Atomic, Consistent, Isolated and Durable assumptions commonly cited in the realm of commercial RDBMS?) Apart from the 'swish' buzzword re-name that isn't even an acronym?
Professionals in the field, while usually in agreement about the desirability of systems which pass the ACID test, most admit that while the concepts are well understood, the real-world cost of the additional software complexity often precludes strict ACID compliance in typical systems. I would certainly be interested if there were more to ROC than evaluating the performance of existing well understood ACID-related techniques but can't find anything more than the "hype." For example, has ROC suggested designs to resolve distributed incoherence due to hardware failure? Classified non-trivial architectures immune to various classes of failure? Discovered a cost effective approach to ACID?
I'm intrigued... some of your arguments against EFS are obvious - (such as the idea that once you've got the physical disk if it's not hard to discover the EFS certificate used for reading - hence the encryption is pointless.) This makes perfect sense - I suspect this issue can be addressed (to some extent) using physically secured domain controllers. However I would like to know your source of information regarding this issue that files are decrypted when open. Do you mean by this that the whole file is written back to disk in plaintext form, or do you mean that only the in-memory copy (which obviously may be swapped out at some stage) is decrypted? Do you have references for this assertion?