The other reason to release our patches back to the development community is to avoid having to maintain the software long-term yourself. I've seen far too many companies where someone writes their own kernel, sendmail, Apache, or gcc fork and thinks they can just backport anything from new releases to their static release. Keeping such a private fork far, far too often leads to quite a lot of nasty regression testing when a new feature is desired, and often completely destabilizes the system when a full upgrade finally occurs because the changes are no longer modular, and the original author has long left the project.
It's much safer in the long run to get such changes into the main codeline for public review and testing.
Now here, you have a point better than Theo's. It's very, very difficult to do clean room creation of complex new software. You're liable to nab bits and pieces of old projects, which you may not even remember the license of. So it happens: you many of you who've packaged CPAN or Apache or PHP modules double-checked the source code and made sure to note the licenses when you've packaged it? I know I've made an innocent mistake, or duplicated one, when I grabbed and modified a corporate.deb or.rpm or.pkg.
Oh, I can easily believe the Eben suggested Theo chill out, given some of the recent kernel driver issues for BSD/GPL licensing. OpenBSD developers used some Linux driver software without permission, and Theo threw a hissy and yanked the drivers iinstead of acknowledging where they came from and working out some sort of licensing deal. Then he whined and bitched extremely loudly about "see, see! See how I'm being oppressed" as his own developers just walked away from his hissy fit and stopped development of the drivers.
From harsh personal pain, the OpenBSD versions of things are really not more stable. NetBSD was, but they kicked out Theo from commit access to CVS. His attitudes and behavior towards developers.
And please don't parrot Theo's lines about how GPL takes away freedoms. We've seen what happens when people, especially aggressive companies, take open source and close it. which BSD explicitly allows. This is exactly what led to the GPL, because it is a recurring problem since the earliest days of UNIX. If you want to see computers get Tivo-ized, and your routres, and your BIOS, and your cell phone, don't use GPL. Go ahead and use BSD.
If you want hte flaws exposed and forks permitted to actually get better software instead of locked in customers, or you don't want your critical apps to become closed source abandonware, go ahead. Do development based on BSD, but kiss the customary patches goodbye, becuase you have no right to insist on copies.
Look, Theo is a joke in the serious development world. While quite a few contributors to OpenBSD, and they claim Theo is technically brilliant, he gets these sorts of procedural and legal issues wrong on a reqular basis. He also keeps trying to claim credit for OpenSSH, which is even funnier. It was written by Tatu Ylorien, the founder of SSH Communications Security, and the OpenSSH is a fork from the last free release of the code.
Not that there's anything major wrong with OpenSSH, but it's a fork that's wasted a lot of time with logging and ignored basic user behavior like enforcing the use of passphrases, properly handling reverse DNS in a worldwide environment, and having a real chroot cage to create save upload and download sites. Like Theo's other work, OpenBSD is caught up in theological purity and frankly languishing, loved by a few developers who are fond of some of its tight code at the expense of supportability or upgradability.
If you don't believe this, take a trip back to the 20th century for silently broken, undocumented, and RSI iinduciing installation procedures and try insalling OpenBSD.
If you want to play the "I have my own license, no one else can touch my code without permission", try the Dan Bernstein copyright oddness or the Pine licensing oddities.
If you want a more robust license that is dealing with Tivo-ization, patent concerns, and makes sure that the software cannot be taken off-line and further development halted by a possessive copyright holder, use the GPL. We're seeing a lot more business proprietization of BSD code right now because the license permits it, and its damaging to the freedom of us, as computer users, to see and modify what runs on our systems.
If you don't believe me, go take a look at highly proprietary firewall and spam filter devices. They choose BSD based software partly for the licensing, and partly for the admittedly more limited and restrictive development models. If Theo doesn't think the GPL license is effective, he can go write his own compiler.
I'm afraid not. Welcome to the non-disclosure clauses of an employee contract. Bringing up corporate policy, in court, where you don't have a cheap and guaranteed win (such as a subpoena from that court) will be a violation of your contract and leave you vulnerable to a serious lawsuit that will break you on the wheels of slow-turning, big law-firm justice.
Even where good whistleblower laws are in place, it's professional suicide to have a company as big as Microsoft unwilling to write you references, and to have that come up in interviews for new work. I've watched ethical people in the medical field who reported malpractice fight this sort of thing when they spoke up to the court. It's very serious career death, and winning the counter suit is very unlikely to pay even the legal costs.
Oh, yes. I've been bribed myself. I was given some very expensive tools, including a demo laptop, during an "evaluation phase" with a company. I turned those into our own company's hardware supply, where they were very useful, but had little corporate policy reason to do so and wouldn't have been caught, and realized only later that it was meant as a bribe for me, personally. When I realized that from the startled commments from the vendor's sales staff that he wondered why someone else had that nice demo laptop and I still used my antique monstrosity, I figured out the planned bribe and tried to get the company banned from our vendor list. I checked, and they were doiing this sort of thing to all clients: isolate the person who is most likely to say "no" and bribe the hell out of htem.
Not sending such messages via email means that you think of such communications as something outside of normal practices, and treat it differently. Unfortunately, a lot of managers now think of hteir email as their filing cabinet. They store their information there, well organized or not, in ways that make it easy to retrieve notes and references for their own use. Watch at how many semi-competent VP's and department managers have a secretary with access to their email to organize it for them, and you'll see this at work.
Automatic wiretap, including remote management of them, has been a necessary feature of telcom installations for the last 10 years at a minimum. Coupled with the NSA tapping of AT&T's fiber optic backbones, the old "Carnivore" project for monitoring email that was publicly denounced but still exists with years of upgrades in the same secured rooms in the same datacenters, it's only surprising that this program's existence took so long to reveal in this level of detail.
Understand that telco licensing requires this level of tapping capability: it's a bit concern about new IP based telephone soltions in law enforcement, that they'll avoid this kind of trackability and remote monitoring. Fortunately for them, I think that Skype and most major VOIP services have been extremely cooperative in such efforts. I can't prove it myself, but I'm confident that they've cooperated to help secure government cooperation in exporting their software.
Yeah. Does anyone know what motherboard they use? And I wonder if they're using LinuxBIOS, which has already proven itself more reliable and more secure than the average BIOS. At least one commercial BIOS I've met reset to a really unfortunate and unsecured set of defaults after 3 reboot failures. It caused me real problems with a data-center deployed server when some power interruptions occurred and they didn't want to connect a keyboard and monitor and reset the BIOS to not require a keyboard for reboot.
Combine it with ethereal for local monitoring, or with a one of rather nifty network monitoring tools like this (http://www.sandstorm.net/products/netintercept/pr eview_next_version.php) with voice-over-IP monitoriing and Microsoft TNEF attachment capture, and you have an absolutely wonderful box to put on a plane and monitor *all* of the traffic through the rather thin network feed to the ground. I recently saw a demo of the older version by someone using it for network monitoring: they're rather frightening devices, and I'm certain a lot of their manufactured systems are for the NSA and similar groups.
If they're competent, they'll be pleased as punch for working in such features to the ticket system. As mentioned in another note, I've done work for 3 companies where the trouble ticket systems were mandated by a group that didn't actually use it after its selection, and entire departments flat out refused to use the systems.
Come to think of it, all of those companies were using Siebel when this happened.
What? If you don't schedule a bit of regular downtime, or a bit of patch time for doing security updates and hardware changes, you've got a big problem as any admin. Even if you're a 99.9999% availability shop, you'd *better* test those failover systems ocasionally.
Nonsense. This is when you talk to your boss about changing the metrics. That's what an annual review is for. If your boss does not agree with you, then he doesn't think you're doing your job and would fire you anyway.
Because people like me who get the very strange, multi-discipline, takes more than "send the caller a webform and close the ticket" issues will be seriously devalued that way. Idiots who make clients fill out 8 distinct tickets for the same task and close each of them during the call will be overvalued.
No. A competently designed trouble ticket sytem provides the name of the person actually dealing with the issue, at least where they recorded the fix and especially where they adapted the fix to better suit the requester's needs, or when they reject it gracefully with an explanation of why it's such a bad idea. A competent sys-admin has to say "no" occasionally, and the means by which thta happens is noticed. And a competent sys-admin has to say "please" ocasionally": what is asked for, and what it provides, is also noticeable and measurable.
If you can't quantify it, your exceptional performance exists only in your own mind along with your 3l33t skillz. The means your company, or your workgroup, use to quantify it may be poor. That's an administrative problem, ot strictly a sys-admin problem. But a *really* good sys-admin has to manage those problems well, too.
Go confess to their priest, who will explain that they should become choirboys and learn about the "eighthth sacrament" that only the most special choirboys get?
Mocking young programmers who haven't gotten their first facial hair yet would be harsh of me to do in a discussion group.
But son, like building your own compiler, you don't want to go there without a bit more experience, or I'll be forced to write ASCII art of smiley faces with long gray beards.
You do realize that ITAR is not a law, it's a regulation? It was not written by Congress, but rather set by the State Department itself, and that therefore both its purpose and its implementation are thus set by the executive branch?
This helps keep the legislature out of it, since they didn't write it. It also means that the judiciary would need to stop it, and when they've interfered with such regulations in the past, the regulation has been simply transferred to another executive department andn it starts all over. (Look up the history of regulations in exporting encryption technologies: the executive department *does not want* and does all in its power to subvert any widespread encryption technologies that they cannot tap at whim.)
And the claim is fundamentally mistaken. There's a basic claim in his writings (which I read back in college), that there is a fundamental linguistic structure that is inherent in all languages: an underlying structure, a universal language referred o as the "q-language".
*THAT* is where Chomsky went overboard. He reasoned from this as a fundamental basis for human language, that it was inherent in human physiology and that all language understanding was based in translation to this underlying q-language. But it's not there: like the music of the spheres or the idea that there are only earth, air, fire, and water as elements, it's a mis-representation of the observable facts and leads to serious error if taken too seriously.
But hey, his politics are also founded on wishful thinking stated with strong argument but not borne out by reality, so it remains popular among people who aren't suspicious and don't compare the claims he makes to history or to the actual events around htem.
Slashdot Mirror
I thought you were an off-shore helpdesk?
The other reason to release our patches back to the development community is to avoid having to maintain the software long-term yourself. I've seen far too many companies where someone writes their own kernel, sendmail, Apache, or gcc fork and thinks they can just backport anything from new releases to their static release. Keeping such a private fork far, far too often leads to quite a lot of nasty regression testing when a new feature is desired, and often completely destabilizes the system when a full upgrade finally occurs because the changes are no longer modular, and the original author has long left the project.
It's much safer in the long run to get such changes into the main codeline for public review and testing.
Now here, you have a point better than Theo's. It's very, very difficult to do clean room creation of complex new software. You're liable to nab bits and pieces of old projects, which you may not even remember the license of. So it happens: you many of you who've packaged CPAN or Apache or PHP modules double-checked the source code and made sure to note the licenses when you've packaged it? I know I've made an innocent mistake, or duplicated one, when I grabbed and modified a corporate .deb or .rpm or .pkg.
Oh, I can easily believe the Eben suggested Theo chill out, given some of the recent kernel driver issues for BSD/GPL licensing. OpenBSD developers used some Linux driver software without permission, and Theo threw a hissy and yanked the drivers iinstead of acknowledging where they came from and working out some sort of licensing deal. Then he whined and bitched extremely loudly about "see, see! See how I'm being oppressed" as his own developers just walked away from his hissy fit and stopped development of the drivers.
From harsh personal pain, the OpenBSD versions of things are really not more stable. NetBSD was, but they kicked out Theo from commit access to CVS. His attitudes and behavior towards developers.
And please don't parrot Theo's lines about how GPL takes away freedoms. We've seen what happens when people, especially aggressive companies, take open source and close it. which BSD explicitly allows. This is exactly what led to the GPL, because it is a recurring problem since the earliest days of UNIX. If you want to see computers get Tivo-ized, and your routres, and your BIOS, and your cell phone, don't use GPL. Go ahead and use BSD.
If you want hte flaws exposed and forks permitted to actually get better software instead of locked in customers, or you don't want your critical apps to become closed source abandonware, go ahead. Do development based on BSD, but kiss the customary patches goodbye, becuase you have no right to insist on copies.
Look, Theo is a joke in the serious development world. While quite a few contributors to OpenBSD, and they claim Theo is technically brilliant, he gets these sorts of procedural and legal issues wrong on a reqular basis. He also keeps trying to claim credit for OpenSSH, which is even funnier. It was written by Tatu Ylorien, the founder of SSH Communications Security, and the OpenSSH is a fork from the last free release of the code.
Not that there's anything major wrong with OpenSSH, but it's a fork that's wasted a lot of time with logging and ignored basic user behavior like enforcing the use of passphrases, properly handling reverse DNS in a worldwide environment, and having a real chroot cage to create save upload and download sites. Like Theo's other work, OpenBSD is caught up in theological purity and frankly languishing, loved by a few developers who are fond of some of its tight code at the expense of supportability or upgradability.
If you don't believe this, take a trip back to the 20th century for silently broken, undocumented, and RSI iinduciing installation procedures and try insalling OpenBSD.
If you want to play the "I have my own license, no one else can touch my code without permission", try the Dan Bernstein copyright oddness or the Pine licensing oddities.
If you want a more robust license that is dealing with Tivo-ization, patent concerns, and makes sure that the software cannot be taken off-line and further development halted by a possessive copyright holder, use the GPL. We're seeing a lot more business proprietization of BSD code right now because the license permits it, and its damaging to the freedom of us, as computer users, to see and modify what runs on our systems.
If you don't believe me, go take a look at highly proprietary firewall and spam filter devices. They choose BSD based software partly for the licensing, and partly for the admittedly more limited and restrictive development models. If Theo doesn't think the GPL license is effective, he can go write his own compiler.
I'm afraid not. Welcome to the non-disclosure clauses of an employee contract. Bringing up corporate policy, in court, where you don't have a cheap and guaranteed win (such as a subpoena from that court) will be a violation of your contract and leave you vulnerable to a serious lawsuit that will break you on the wheels of slow-turning, big law-firm justice.
Even where good whistleblower laws are in place, it's professional suicide to have a company as big as Microsoft unwilling to write you references, and to have that come up in interviews for new work. I've watched ethical people in the medical field who reported malpractice fight this sort of thing when they spoke up to the court. It's very serious career death, and winning the counter suit is very unlikely to pay even the legal costs.
Oh, yes. I've been bribed myself. I was given some very expensive tools, including a demo laptop, during an "evaluation phase" with a company. I turned those into our own company's hardware supply, where they were very useful, but had little corporate policy reason to do so and wouldn't have been caught, and realized only later that it was meant as a bribe for me, personally. When I realized that from the startled commments from the vendor's sales staff that he wondered why someone else had that nice demo laptop and I still used my antique monstrosity, I figured out the planned bribe and tried to get the company banned from our vendor list. I checked, and they were doiing this sort of thing to all clients: isolate the person who is most likely to say "no" and bribe the hell out of htem.
They're still in business.
Not sending such messages via email means that you think of such communications as something outside of normal practices, and treat it differently. Unfortunately, a lot of managers now think of hteir email as their filing cabinet. They store their information there, well organized or not, in ways that make it easy to retrieve notes and references for their own use. Watch at how many semi-competent VP's and department managers have a secretary with access to their email to organize it for them, and you'll see this at work.
Automatic wiretap, including remote management of them, has been a necessary feature of telcom installations for the last 10 years at a minimum. Coupled with the NSA tapping of AT&T's fiber optic backbones, the old "Carnivore" project for monitoring email that was publicly denounced but still exists with years of upgrades in the same secured rooms in the same datacenters, it's only surprising that this program's existence took so long to reveal in this level of detail.
Understand that telco licensing requires this level of tapping capability: it's a bit concern about new IP based telephone soltions in law enforcement, that they'll avoid this kind of trackability and remote monitoring. Fortunately for them, I think that Skype and most major VOIP services have been extremely cooperative in such efforts. I can't prove it myself, but I'm confident that they've cooperated to help secure government cooperation in exporting their software.
And they're not going to hire overworked, underpaid foreigners as security staff. You don't fly out of major airports much, co you?
Yeah. Does anyone know what motherboard they use? And I wonder if they're using LinuxBIOS, which has already proven itself more reliable and more secure than the average BIOS. At least one commercial BIOS I've met reset to a really unfortunate and unsecured set of defaults after 3 reboot failures. It caused me real problems with a data-center deployed server when some power interruptions occurred and they didn't want to connect a keyboard and monitor and reset the BIOS to not require a keyboard for reboot.
Combine it with ethereal for local monitoring, or with a one of rather nifty network monitoring tools like this (http://www.sandstorm.net/products/netintercept/pr eview_next_version.php) with voice-over-IP monitoriing and Microsoft TNEF attachment capture, and you have an absolutely wonderful box to put on a plane and monitor *all* of the traffic through the rather thin network feed to the ground. I recently saw a demo of the older version by someone using it for network monitoring: they're rather frightening devices, and I'm certain a lot of their manufactured systems are for the NSA and similar groups.
If they're competent, they'll be pleased as punch for working in such features to the ticket system. As mentioned in another note, I've done work for 3 companies where the trouble ticket systems were mandated by a group that didn't actually use it after its selection, and entire departments flat out refused to use the systems.
Come to think of it, all of those companies were using Siebel when this happened.
What? If you don't schedule a bit of regular downtime, or a bit of patch time for doing security updates and hardware changes, you've got a big problem as any admin. Even if you're a 99.9999% availability shop, you'd *better* test those failover systems ocasionally.
Nonsense. This is when you talk to your boss about changing the metrics. That's what an annual review is for. If your boss does not agree with you, then he doesn't think you're doing your job and would fire you anyway.
Because people like me who get the very strange, multi-discipline, takes more than "send the caller a webform and close the ticket" issues will be seriously devalued that way. Idiots who make clients fill out 8 distinct tickets for the same task and close each of them during the call will be overvalued.
No. A competently designed trouble ticket sytem provides the name of the person actually dealing with the issue, at least where they recorded the fix and especially where they adapted the fix to better suit the requester's needs, or when they reject it gracefully with an explanation of why it's such a bad idea. A competent sys-admin has to say "no" occasionally, and the means by which thta happens is noticed. And a competent sys-admin has to say "please" ocasionally": what is asked for, and what it provides, is also noticeable and measurable.
If you can't quantify it, your exceptional performance exists only in your own mind along with your 3l33t skillz. The means your company, or your workgroup, use to quantify it may be poor. That's an administrative problem, ot strictly a sys-admin problem. But a *really* good sys-admin has to manage those problems well, too.
Go confess to their priest, who will explain that they should become choirboys and learn about the "eighthth sacrament" that only the most special choirboys get?
Where's Terry Pratchett's "Librarian" when you need him?
Mocking young programmers who haven't gotten their first facial hair yet would be harsh of me to do in a discussion group. But son, like building your own compiler, you don't want to go there without a bit more experience, or I'll be forced to write ASCII art of smiley faces with long gray beards.
You do realize that ITAR is not a law, it's a regulation? It was not written by Congress, but rather set by the State Department itself, and that therefore both its purpose and its implementation are thus set by the executive branch? This helps keep the legislature out of it, since they didn't write it. It also means that the judiciary would need to stop it, and when they've interfered with such regulations in the past, the regulation has been simply transferred to another executive department andn it starts all over. (Look up the history of regulations in exporting encryption technologies: the executive department *does not want* and does all in its power to subvert any widespread encryption technologies that they cannot tap at whim.)
And the claim is fundamentally mistaken. There's a basic claim in his writings (which I read back in college), that there is a fundamental linguistic structure that is inherent in all languages: an underlying structure, a universal language referred o as the "q-language".
*THAT* is where Chomsky went overboard. He reasoned from this as a fundamental basis for human language, that it was inherent in human physiology and that all language understanding was based in translation to this underlying q-language. But it's not there: like the music of the spheres or the idea that there are only earth, air, fire, and water as elements, it's a mis-representation of the observable facts and leads to serious error if taken too seriously.
But hey, his politics are also founded on wishful thinking stated with strong argument but not borne out by reality, so it remains popular among people who aren't suspicious and don't compare the claims he makes to history or to the actual events around htem.
Creatures that fling feces at each other? Who could tell the difference between them and the average Perl programmer?