Consider C-Kermit, wu-imapd, djbdns, and daemontools. While Dan Bernstein has relented, the owners of the other packages have not, and they've basically evaporated from typical distributions, and even Dan Bernstein's djbdns and daemontools have basically fallen by the wayside.
Would everyone who actually manages to run their servers with only "-stable" please raise their hands? One, two... no wait, that person is scratching their head.
I'm afraid that "running servers with only -stable" is like "never typing 'rm -rf' as root". It would be nice if we could do so, but far too often we need to get work done and risk a "non-stable" package to get particular critical features, and this approach breaks down very quickly.
Oh, goodness. My apologies, sir or madam: thank you for correcting me on that attribution. For some reason I thought I was still talking with Brightspark.
Perhaps it hasn't cost Miguel his soul, but it's certainly cost him his credibility. Like Colin Powell joining the Republican Party and standing up for the war in Iraq, it's a betrayal of the very principles and practices that allowed him to advance in his field. And standing up for Mono has cost Miguel his credibility.
It's possible Miguel believes Microsoft is attempting to play nice with open source: but we have long memories about Microsoft abuses, ranging from their abuse of Netscape to their theft of patented technologies from business partners, the amazing abuse of ISO to get OOXML ratified, and Microsoft's theft of the XML technology from lfj (for which they were fined $290,000,000.00). That level of abuse is not "an aberration". That takes policy, from former and current leaders of Microsoft, to commit that kind of abuse: a desire to play nice by your group when your bosses are that level of criminal requires extraordinary proof, which you've not provided.
Mr. Pratchett's work is brilliant, insightful, and often as funny as Monty Python. Racism, war, discrimination, child-raising, gangs, drug addiction, and all the ills of the modern age are covered in ways that both entertain and educate.
I wish the man would visit my neighborhood so I could buy him a hat.
I'm sad to say, every single one of the corporate partners I've dealt with in the last 2 years used HTTPS or even HTTP. _None_ used svn+ssh when I first met them: most of them began to _allow_ svn+ssh, but all refused to switch over.
svn+ssh is, in fact, a workaround, and pretty much a joke of one. Please take a look at the difference between ssh-wrapping a badly implemented joke of an unsecured and poorly configurable protocol, such as svnserve, and the much cleaner approaches of Perforce, Bitkeeper, or even git for access management.
The local changes are a peripherally related issue to ssh based access. You see, Subversion requires you to authenticate and communicate with the central repository for every single commit of any changes. With git, you can record your changes locally and only push them or do a comparison (which is much saner under git, by the way), when you're ready to push the changes as a set. This is vastly, vastly more efficient than the constant communication with the central repository and the related authentication issues: you can occasionally use an SSH key, with a passphrase, and not even bother to pre-unlock or pre-store the passphrase opened key.
> If I were to plug a vulnerable machine in, it's still a switched network, which means sniffing is impossibl
I'm afraid you're mistaken. This is not an uncommon belief, and you're not alone in your confidence in this form of security. But I very strongly urge you to look up 'ARP Poisoning', and consider trying it out in the safety of your own network. It's _nasty_, and an easy way to use a rootkitted laptop or hostile host inside a corporate network to sniff passwords on unsecured protocols.
The way to mostly defeat that is to program your switch so that individual ports are locked to individual MAC addresses, and make sure that any non-allocated MAC addresses popping up on your network immediately trigger an alert.
True, and that's what Sourceforge does. But there's no useful publicly available tool that I know of for managing those public keys. Do you have one? Git, at least, has 'gitosis' for that task, and it allows you to record your changes locally and only push them to the central repository when you're satisfied with your progress.
This sort of behavior is why I've discarded Subversion wherever possible. Security should not be an afterthought, to be addressed with patches slapped on after the fact.
What $HOME/.subversion is set to is dependent on the account creator's permissions for $HOME, and the individual user's umask. But even if.subversion were protected, if the account is NFS mounted or is available on backup tapes, your password is availalble to anyone who can gain _local_ root access on an NFS client and do 'su' to act as other users, or gain access to the backup tapes. NFS, in particular, is generally available to any laptop with a live CD anyone can plug into your network.
It's an incredible security problem, one generally ignored by people who "trust the people they work with".
I know you think you're kidding. But the old 'crack' program, by Alec Moffett, was very useful for detecting weak passwords. In many different environments it would successfully guess roughly 10% of all passwords, using the publicly available encrypted passwords from/etc/passwd in systems that had never had shadow passwords enabled. It's gotten tougher since MD5 based passwords came into fashion, admittedly.
What? Oh, I'm not talking about the server! I'm talking about the UNIX and Linux clients, which by default store your passwords in clear-text in $HOME/.subversion/auth/. Subversion has always done this: no fix has ever been planned for Linux and UNIX clients. There are workarounds, such as using 'svn+ssh' or using only Windows clients such as TortoiseSVN that do not have this problem, but there is no actual fix for this planned.
Subversion 1.6 does ask before storing the passwords, but that's not a fix.
Oh, I agree that they deserve to be shot. But don't blame the admin himself. Just try to get a startup company run by former academics who aren't old enough to remember the Morris Worm to take security seriously. I spent far too long sharing guidelines with a professional colleague last year, only to have his company's VP's throw the whole security recommendation away under the guise of "not critical". Then they fired him, apparently partially in retaliation for expressing his concerns as part of his project reports. I've written him excellent recommendations, but am very pleased that my upstream managerial personnel have been taught, partly by me, to take security seriously.
And don't forget to keep it updated. And do not use FTP based on normal user passwords. And HTTP based on normal user passwords. And turn off rsh. And turn off telnet. And make sure people don't use the same passwords for your critical servers and their external bank accounts and web services. And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text. And make sure that your POP and IMAP servers are SSL protected, always. And make sure that your SMTPAUTH is done enctypred. And make sure that your boss does not send passwords to people via email.
Etc., etc., etc. I'm sorry, but please don't pretend that strong passwords are enough to protect you from general attacks. And don't pretend that you can force users to pick good passwords.
I'm afraid that while IPv6 has many features, the upstream roll-out is hindered by necessary hardware and configuration upgrades, and interoperability with IPv4 for at least another decade. And frankly, with the effective use of NAT and staggered layers of NAT around the world, the overwhelming need of IPv6 has also evaporated for another decade.
Can you show me a single feature of IPv6 that Verizon's customers actually need? One that isn't also manageable with NAT and reasonably intelligent load balancers?
I just had a firm chat with an engineer who showed me the internal email from his company's sales department, asking employees to drive negative reviews off of AppWorld's product reviews. I've just barred my investment manager from putting any money in that company, because that kind of astro-turfing without identifying yourself as an employee is, in fact, considered fraud. If they're pulling that kind of nonsense for product reviews, what are they doing with their service level agreements and customer credit card security?
When he asked me to put in a positive review for a device I don't use and don't personally like, I actually wrote to his sales person who'd sent the note and explained why I turned around and gave their product a negative review. (It has serious, serious mechanical flaws and the battery life of a mayfly.)
I sympathize with you. And to avoid that hardware compatibility trap, you might consider simply using virtualization: a several year old hardware platform, such as the HP G4, should be reasonably equivalent to a virtual environment on newer hardware. And you can use the newer hardware's base OS or another client OS to provide read-only access to the client OS fileystem to run anti-virus scans, and provide a more clever network security toolkit with the virtualization server or another system as a proxy and file-service compatible firewall.
A corporate partner of mine just did this very effectively for some old Win98 tools they have to keep around for legacy data access reasons.
We'll have to, as new desktops and laptops are released with oddball chipsets for which the vendors only provide Windows 7 drivers. This has been one of the key forces behind corporate upgrades for years: the new hardware with new features is impossible or painful indeed to run on older operating systems.
Please read the definition you provided again. It says "sharing _or_ exchange". The word "sharing" allows it to be one-way. And even if your logic were valid for that single definition, to then say that because it does not match _that_ definition, email is not communication, is a "strawman" fallacy. It's selecting a single relatively easily argued point and ignoring the rest of the issue. In fact, I'm looking at the definition from the Oxford Compact Dictionary, at http://www.askoxford.com/concise_oed/communication?view=uk, which says:
communication: * noun 1 the action of communicating. 2 a letter or message. 3 (communications) means of sending or receiving information, such as telephone lines or computers. 4 (communications) means of travelling or of transporting goods, such as roads or railways.
So even without my correcting your interpretation of that first definition you cited, the definitions above, from a related source, _specifically_ include letters and messages. So your entire line of reasoning that somehow email is not communication falls apart.
It's not that you don't have a point that staggered communications, such as email or letters or Usenet or Slashdot or Wikis, do not alter communication and reduce or delay feedback. But to say that it's therefore not communication is ill-founded.
I apologize, sir or madam, for being unclear. Using tools like Ubuntu for operating systems, you're in a sweet spot right now where the difference in price for a 20 Gig or 250 Gig drive is nominal. If you were doing something like, say, running your own in-house Bittorrent and FTP site for downloaded music (as a recent engineer at work admitted doing, and I had to slap his wrist for using our bandwidth for downloads), the price/Gig would matter much more. (He had 2 Terabytes on 2 external drives he kept plugging into his laptop at work: I wanted to kill him for sucking up all our limited external bandwidth at that site.)
For the OS itself, you're quite right that the unit cost dominates. But to see the price/cost/performance tradeoffs played out in more detail, look at laptops capable of running your Ubuntu, where the prices are higher and have more effect.
My friend, 10 years ago, that 15 Gig was much, much more expensive. Please don't mistake the surplus drive space available this year to the economic and social forces that applied a decade ago, or which funded development of the latest round of Terabyte platters.
While a pleasant definition, the idea that "communication is two way" does not seem to be founded in law, information theory, or common English usage. On what do you base this claim? And given that even normal letter writing and conversation may have pauses while the messages are transmitted one way, or may overlap each other as email does, on what could you _possibly_ base the claim that email does not include two way communication?
After all, you and I are communicating right now. Doesn't that count?
Slashdot Mirror
I take it you haven't visited Canada or Sweden in this millennium?
Consider C-Kermit, wu-imapd, djbdns, and daemontools. While Dan Bernstein has relented, the owners of the other packages have not, and they've basically evaporated from typical distributions, and even Dan Bernstein's djbdns and daemontools have basically fallen by the wayside.
Would everyone who actually manages to run their servers with only "-stable" please raise their hands? One, two... no wait, that person is scratching their head.
I'm afraid that "running servers with only -stable" is like "never typing 'rm -rf' as root". It would be nice if we could do so, but far too often we need to get work done and risk a "non-stable" package to get particular critical features, and this approach breaks down very quickly.
And this felon had "no authority" over the prison computer system.
You don't need "authority", you just need access.
Oh, goodness. My apologies, sir or madam: thank you for correcting me on that attribution. For some reason I thought I was still talking with Brightspark.
Perhaps it hasn't cost Miguel his soul, but it's certainly cost him his credibility. Like Colin Powell joining the Republican Party and standing up for the war in Iraq, it's a betrayal of the very principles and practices that allowed him to advance in his field. And standing up for Mono has cost Miguel his credibility.
It's possible Miguel believes Microsoft is attempting to play nice with open source: but we have long memories about Microsoft abuses, ranging from their abuse of Netscape to their theft of patented technologies from business partners, the amazing abuse of ISO to get OOXML ratified, and Microsoft's theft of the XML technology from lfj (for which they were fined $290,000,000.00). That level of abuse is not "an aberration". That takes policy, from former and current leaders of Microsoft, to commit that kind of abuse: a desire to play nice by your group when your bosses are that level of criminal requires extraordinary proof, which you've not provided.
Mr. Pratchett's work is brilliant, insightful, and often as funny as Monty Python. Racism, war, discrimination, child-raising, gangs, drug addiction, and all the ills of the modern age are covered in ways that both entertain and educate.
I wish the man would visit my neighborhood so I could buy him a hat.
I'm sad to say, every single one of the corporate partners I've dealt with in the last 2 years used HTTPS or even HTTP. _None_ used svn+ssh when I first met them: most of them began to _allow_ svn+ssh, but all refused to switch over.
svn+ssh is, in fact, a workaround, and pretty much a joke of one. Please take a look at the difference between ssh-wrapping a badly implemented joke of an unsecured and poorly configurable protocol, such as svnserve, and the much cleaner approaches of Perforce, Bitkeeper, or even git for access management.
The local changes are a peripherally related issue to ssh based access. You see, Subversion requires you to authenticate and communicate with the central repository for every single commit of any changes. With git, you can record your changes locally and only push them or do a comparison (which is much saner under git, by the way), when you're ready to push the changes as a set. This is vastly, vastly more efficient than the constant communication with the central repository and the related authentication issues: you can occasionally use an SSH key, with a passphrase, and not even bother to pre-unlock or pre-store the passphrase opened key.
SanityinAnarchy wrote:
> If I were to plug a vulnerable machine in, it's still a switched network, which means sniffing is impossibl
I'm afraid you're mistaken. This is not an uncommon belief, and you're not alone in your confidence in this form of security. But I very strongly urge you to look up 'ARP Poisoning', and consider trying it out in the safety of your own network. It's _nasty_, and an easy way to use a rootkitted laptop or hostile host inside a corporate network to sniff passwords on unsecured protocols.
The way to mostly defeat that is to program your switch so that individual ports are locked to individual MAC addresses, and make sure that any non-allocated MAC addresses popping up on your network immediately trigger an alert.
True, and that's what Sourceforge does. But there's no useful publicly available tool that I know of for managing those public keys. Do you have one? Git, at least, has 'gitosis' for that task, and it allows you to record your changes locally and only push them to the central repository when you're satisfied with your progress.
This sort of behavior is why I've discarded Subversion wherever possible. Security should not be an afterthought, to be addressed with patches slapped on after the fact.
What $HOME/.subversion is set to is dependent on the account creator's permissions for $HOME, and the individual user's umask. But even if .subversion were protected, if the account is NFS mounted or is available on backup tapes, your password is availalble to anyone who can gain _local_ root access on an NFS client and do 'su' to act as other users, or gain access to the backup tapes. NFS, in particular, is generally available to any laptop with a live CD anyone can plug into your network.
It's an incredible security problem, one generally ignored by people who "trust the people they work with".
I'm afraid you did. In your first two lines:
> Email is a one way tranference of information. Communication is two way, needing a confirmatory "message heard and understood".
How else can we read that, except that you are saying email is not communication?
I know you think you're kidding. But the old 'crack' program, by Alec Moffett, was very useful for detecting weak passwords. In many different environments it would successfully guess roughly 10% of all passwords, using the publicly available encrypted passwords from /etc/passwd in systems that had never had shadow passwords enabled. It's gotten tougher since MD5 based passwords came into fashion, admittedly.
What? Oh, I'm not talking about the server! I'm talking about the UNIX and Linux clients, which by default store your passwords in clear-text in $HOME/.subversion/auth/. Subversion has always done this: no fix has ever been planned for Linux and UNIX clients. There are workarounds, such as using 'svn+ssh' or using only Windows clients such as TortoiseSVN that do not have this problem, but there is no actual fix for this planned.
Subversion 1.6 does ask before storing the passwords, but that's not a fix.
Oh, I agree that they deserve to be shot. But don't blame the admin himself. Just try to get a startup company run by former academics who aren't old enough to remember the Morris Worm to take security seriously. I spent far too long sharing guidelines with a professional colleague last year, only to have his company's VP's throw the whole security recommendation away under the guise of "not critical". Then they fired him, apparently partially in retaliation for expressing his concerns as part of his project reports. I've written him excellent recommendations, but am very pleased that my upstream managerial personnel have been taught, partly by me, to take security seriously.
And don't forget to keep it updated. And do not use FTP based on normal user passwords. And HTTP based on normal user passwords. And turn off rsh. And turn off telnet. And make sure people don't use the same passwords for your critical servers and their external bank accounts and web services. And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text. And make sure that your POP and IMAP servers are SSL protected, always. And make sure that your SMTPAUTH is done enctypred. And make sure that your boss does not send passwords to people via email.
Etc., etc., etc. I'm sorry, but please don't pretend that strong passwords are enough to protect you from general attacks. And don't pretend that you can force users to pick good passwords.
I'm afraid that while IPv6 has many features, the upstream roll-out is hindered by necessary hardware and configuration upgrades, and interoperability with IPv4 for at least another decade. And frankly, with the effective use of NAT and staggered layers of NAT around the world, the overwhelming need of IPv6 has also evaporated for another decade.
Can you show me a single feature of IPv6 that Verizon's customers actually need? One that isn't also manageable with NAT and reasonably intelligent load balancers?
I just had a firm chat with an engineer who showed me the internal email from his company's sales department, asking employees to drive negative reviews off of AppWorld's product reviews. I've just barred my investment manager from putting any money in that company, because that kind of astro-turfing without identifying yourself as an employee is, in fact, considered fraud. If they're pulling that kind of nonsense for product reviews, what are they doing with their service level agreements and customer credit card security?
When he asked me to put in a positive review for a device I don't use and don't personally like, I actually wrote to his sales person who'd sent the note and explained why I turned around and gave their product a negative review. (It has serious, serious mechanical flaws and the battery life of a mayfly.)
I sympathize with you. And to avoid that hardware compatibility trap, you might consider simply using virtualization: a several year old hardware platform, such as the HP G4, should be reasonably equivalent to a virtual environment on newer hardware. And you can use the newer hardware's base OS or another client OS to provide read-only access to the client OS fileystem to run anti-virus scans, and provide a more clever network security toolkit with the virtualization server or another system as a proxy and file-service compatible firewall.
A corporate partner of mine just did this very effectively for some old Win98 tools they have to keep around for legacy data access reasons.
We'll have to, as new desktops and laptops are released with oddball chipsets for which the vendors only provide Windows 7 drivers. This has been one of the key forces behind corporate upgrades for years: the new hardware with new features is impossible or painful indeed to run on older operating systems.
Please read the definition you provided again. It says "sharing _or_ exchange". The word "sharing" allows it to be one-way. And even if your logic were valid for that single definition, to then say that because it does not match _that_ definition, email is not communication, is a "strawman" fallacy. It's selecting a single relatively easily argued point and ignoring the rest of the issue. In fact, I'm looking at the definition from the Oxford Compact Dictionary, at http://www.askoxford.com/concise_oed/communication?view=uk, which says:
communication: * noun 1 the action of communicating. 2 a letter or message. 3 (communications) means of sending or receiving information, such as telephone lines or computers. 4 (communications) means of travelling or of transporting goods, such as roads or railways.
So even without my correcting your interpretation of that first definition you cited, the definitions above, from a related source, _specifically_ include letters and messages. So your entire line of reasoning that somehow email is not communication falls apart.
It's not that you don't have a point that staggered communications, such as email or letters or Usenet or Slashdot or Wikis, do not alter communication and reduce or delay feedback. But to say that it's therefore not communication is ill-founded.
I apologize, sir or madam, for being unclear. Using tools like Ubuntu for operating systems, you're in a sweet spot right now where the difference in price for a 20 Gig or 250 Gig drive is nominal. If you were doing something like, say, running your own in-house Bittorrent and FTP site for downloaded music (as a recent engineer at work admitted doing, and I had to slap his wrist for using our bandwidth for downloads), the price/Gig would matter much more. (He had 2 Terabytes on 2 external drives he kept plugging into his laptop at work: I wanted to kill him for sucking up all our limited external bandwidth at that site.)
For the OS itself, you're quite right that the unit cost dominates. But to see the price/cost/performance tradeoffs played out in more detail, look at laptops capable of running your Ubuntu, where the prices are higher and have more effect.
My friend, 10 years ago, that 15 Gig was much, much more expensive. Please don't mistake the surplus drive space available this year to the economic and social forces that applied a decade ago, or which funded development of the latest round of Terabyte platters.
While a pleasant definition, the idea that "communication is two way" does not seem to be founded in law, information theory, or common English usage. On what do you base this claim? And given that even normal letter writing and conversation may have pauses while the messages are transmitted one way, or may overlap each other as email does, on what could you _possibly_ base the claim that email does not include two way communication?
After all, you and I are communicating right now. Doesn't that count?