Where are you putting the drives that the Bernoulli principle comes into effect? Given that the Bernoulli principle addresses issues of momentum conservation in a stream of fluid, I can't imagine a practical application where the stagnation pressure would come into play.
Wait, I know. Are you dropping running computers out of cargo aircraft at 60k feet?
Our main project (LedgerSMB) is still mostly an inherited codebase (we forked from SQL-Ledger, a nominee for worst web app ever). We didn't code it the first time around. Inherited bugs are responsible for nearly all of our security issues. Yes, we are rewriting from scratch but that takes time.
Military confrontation doesn't necessarily mean "shooting war."
I will give you an possibility that has a lot of hawks quaking in their boots.
Ok. Suppose the Korean Penninsula reunites. This would lead to a difficult transition for a while but I am sure things would get ironed out reasonably quickly, the South Korean government would exapnd into the North, would soon turn the PDRK's ballistic missile program into a satellite launch platform, and be well on their way to being a regional commercial powerhouse.
Only problem is, South Korea's economy is largely supported via trade with China (and North Korea is downright dependent on Chinese aid). Hence a unified Korea would be somewhat likely to side with China as their main ally in the region. This has the possibility of sucking us into a standoff with China over Japan. Hence we are involved in a much more serious standoff with China, even if no shots are fired.
Yes, a military confrontation with China in some form is probably inevitable. It is not clear whether or not this will take the shape of a shooting war, a standoff, or something else.
Normally, if a security issues is reported to us, we begin communicating with the submitter within a week. From here we can communicate what we are doing, how long it will take, etc. All security issues are fixed on a priority basis, and we do this pretty much as fast as we can.
However, in general nothing is gained by pushing out a fix too soon. Reviewing the problem and solution takes time, as does ensuring that we understand it properly. This is very important for the development of quality fixes.
Generally I would tell customers "one month maximum for most security issues." If we get it done in 48 hours, great (they will be happy).
A lot of our bugs which end up being things which are fixed quite quickly once they are understood.
Yes, it speaks loudly that their bugs are fixed in 15 minutes. It means that they are able to get enough information to fix the problem quickly. Of course, if the fixes are small, minimal testing may be required which can also fit in that time frame.
One month is an industry-standard maximum one should enforce in the absence of rare and extenuating factors.
Ideally, response time should be a lot less. Here are absolute maximums for general security issues in the absense of such factors: 1) 1 week to reproduce the problem and get back to the submitter of the issue. 2) 1 week of internal review, understanding where the problem is, how serious it is, etc. 3) 1 week of coding and code change review (usually less) 4) 1 week of testing/validation 5) couple of days packaging/releasing/etc.
If these take longer in a significant number of cases, you have bigger problems.
One more option is that you can grant roles to various users and require that they set their role prior to data access.
This doesn;t restrict it based on where they log in from, but the user's application needs to state that it is running reports instead of doing database administration, while when you log in via psql, you have to tell it you are doing admin stuff rather than reporting.
This provides the same enforcement without the headache of worrying what happens if consolidate your reporting system onto the local machine.
My rule is to always assume that the other side will try to enforce the contract. It is only worth consulting with a lawyer if you have decided in advance that you are up for a fight and are willing to take the chance at losing.
Otherwise consult lawyers if you want a second opinion of whether a contract might cover things you hadn't thought of, or to get pre-fight advice. Or to get representation in a fight. Asking "if I sign this, can I safely ignore it" is a stupid question to ask a lawyer unless you are willing to fight it in court, and have the time/money/inclination to do so.
A foot-gun is a device which is mostly useful for shooting yourself in the foot.
BTW, I have been reading a bit about SE-PostgreSQL (Linux-only) which might do all of this on Linux. It brings all the power and flexibility of SELinux to PostgreSQL.
The way we are trying to solve the OORelational mismatch issue in LedgerSMB is through using a fairly different approach. It works reasonably well, but some programmers complain about the fact that things are fundamnetally relational with OO glue over the top.
What we do is create object method mappings to database procedural interfaces. The procedural interfaces basically function as named queries which retrieve data in expected formats (included nested arrays). Thus we have an objectrelational mapping which is entirely encoded in the database, and could be reused by components in other languages.
The large issues we have with this approach have to do with large numbers of interfaces which an object may need to be using, and some cannot be automatically mapped back in all cases, unless one uses fairly complex interfaces (and some supported versions of PostgreSQL don't do everything we need to do for the complex interfaces, though that will change in a few years).
In the past, I have generally given back to an employer whatever ideas I thought would help them. Why not? I can't implement all my ideas anyway and if I get a bit of goodwill out of it.....
BTW, I have been rewarded for this. I have seen my ideas have an impact on my employers (even when they have been Fortune 500 companies), and even when I didn't get direct credit for the idea, I made sure it was recorded in my record with the company. Some of these former employers are now my customers, so it has all paid off well. BTW, I am happy to give ideas to customers as well.
However, I do not give people ideas I don't think they want to or can implement. That is stupid because in the end, if I go and implement myself, then I may get in trouble with trade secrets provisions. Instead I give business-specific ideas to specific businesses.
They offer a lot of benefits to the workers but they also disrupt a lot of necessary communication between workers and management. Unions are like chemotherapy-- why you would want to experience then when you don't have the disease is beyond me....
In general I would not want to work in a unionized environment nor would I want to work in an environment where unions were able to provide good benefits to the workers on top of what the company could offer. If the company isnt willing to offer it themselves, I don't want to work there....
For security issues we usually have a 48-hr to 1-month turn around time. I think a turnaround time for urgent issues of more than a month is excessive. Minor issues get fixed based on a number of factors and the turnaround time varies from 24 hours to 3 months.
In case you are wondering why the floor on the security issue fixes is a little longer, we usually put the initial problem and the fix through extra review so we ensure we truly understand the problem and that the fix solves all likely related issues. Then we have to decide whether to do a patch or a maintenance release. This process adds additional time.
Having said this, it is impossible to know from the description whether the customer is being reasonable or not. I have had issues where I had to come up with a fix within 24 hours and other cases where the demand was unreasonable. Hope this helps.
1) What is the business impact of the bug? 2) What is the data integrity impact of the bug?
That still seems like a footgun to me. It is better to use an administrative user for the admin functions. This introduces a lot less complexity and creates fewer problems down the road as components migrate around the network. In short it seems to me that you are making either the administration or the reporting entirely non-portable from a network perspective.
In PostgreSQL if you really need to do this, I you can use security definer stored procedures which could check for arbitrary other criteria and deny permission on that basis. Sure it is more difficult, and it is better to avoid situations where moving a component around a network can cause privelege escallation.
Spend your entire day documenting every idea you have had and send it to the appropriate place. This means you don't get any real work done. Also send a formal request to your manager, the legal department, etc. to get it limited in scope.
That is actualy incredibly bad advice. Note that when I did this at Microsoft, I made sure I had additional protections in place (basically an amendment to the contract which allowed me to run my own business and retain the intellectual property).
A better solution is to start a business which doesn't compete with your employer, ask for your employer's permission to do so, and get an ammentment that says that any IP created for that business is owned by that business (i.e. you). Then you can release it under whatever license you want.
Non-compete clauses have a valid purpose, i.e. to prevent leakage of valid trade secrets from one business to a competitor. It seems that if I say "I am hiring to to work on building this great LDAP server and this contract states that you cannot help other companies build products which compete with this specific product for a period of 6 months after employment" (btw similar in scope to the standard non-compete at Microsoft), this doesn't seem to be a problem.
OTOH, if I say "You may not work for any company which competes with us in any capacity" that is fundamentally different.
When I was at Microsoft, I was an hourly employee doing tech support. The employment contract had all these wonderful provisions such as including all of these things that were mentioned.
First, I negotiated exceptions like crazy (Microsoft to their credit has processes open for doing this). Secondly I tracked the time I spent on my own projects. I figured that if they wanted my software, and forced me to assign them IP rights, then I would charge them for all the time (at time and a half) for the time I spent on each project from the beginning. Finally I negotiated a broad exception to include all of my own ideas not related to Microsoft trade secrets I had access to (which weren't many). Everything worked well.
I am not sure about that. I have been looking for good Perl and/or PL/PGSQL programmers willing to do paid work on FOSS projects from home offices for a while and gotten nowhere. If people are interested in sending me resumes, my email address is mailto:chris@metatrontech.com.
Very few Americans bought the line about Saddam being linked to Al Qaeda. Interestingly, the ICG did an interesting analysis of Powell's presentation and concluded that if there were an Al Qaeda training camp, it was in the area controlled by the Patriotic Union of Kurdistan (our supposed allies).
Most people did assume that he had biological and chemical weapons, and there was an open question about nuclear weapons development.
A few of us understood the real reason for the war and understood that those even if true were not relevant to the question of it. The fact is that the presence of US troops in Saudi Arabia in order to contain Saddam was playing into the hands of Al Qaeda propaganda, and destabilizing the region. The idea was simple: redeploy those forces to Iraq as part of a containment policy on Iran. The problem is that this was unethical and immoral, and we have seen the results first-hand (our approach to North Korea is built on the same sort of mentality, and it is one of the greatest mistakes, foreign-policy-wise of our day. Long run, it has the capacity to hurt us far more than Iraq does).
BTW, yes, it is all about oil. The issue is that we get most of our oil from the Middle East and so fear of disruption of oil supplies is the guiding principle for US involvement in the Middle East. It is not about control of oil but rather security of supply (remember that the Japanese Navy in WWII was defeated decisively by cutting off access to oil).
BTW, about the PDRK (N. Korea). The US has a policy of isolating Kim Jong Il (what US News and World Report compared to "Threatening a drowning man with a life preserver"), purposefully prolonging the independent existance of the PDRK for the sole reason of our fear of Chinese involvement. The issue is that South Korea's economy is largely dependent on trade with China, and there is thus fear that a unified Korea would side with China against the US. The fact that the Korean War is still not officially over prevents this from happening however. Hence we do everything we can to delay reunification so we don't end up involved in a larger China/Japan standoff. The problem with this view is that most Koreans want eventual reunification, and so we are likely to cause the specific problem that we fear through our reactions today.
Slashdot Mirror
Where are you putting the drives that the Bernoulli principle comes into effect? Given that the Bernoulli principle addresses issues of momentum conservation in a stream of fluid, I can't imagine a practical application where the stagnation pressure would come into play.
Wait, I know. Are you dropping running computers out of cargo aircraft at 60k feet?
Shouldn't that be:
3) Profit? (as in how much does it profit us to fix the bug)
Honestly, we try to fix every bug reported to us. Some bugs happen faster than others.
Our main project (LedgerSMB) is still mostly an inherited codebase (we forked from SQL-Ledger, a nominee for worst web app ever). We didn't code it the first time around. Inherited bugs are responsible for nearly all of our security issues. Yes, we are rewriting from scratch but that takes time.
Military confrontation doesn't necessarily mean "shooting war."
I will give you an possibility that has a lot of hawks quaking in their boots.
Ok. Suppose the Korean Penninsula reunites. This would lead to a difficult transition for a while but I am sure things would get ironed out reasonably quickly, the South Korean government would exapnd into the North, would soon turn the PDRK's ballistic missile program into a satellite launch platform, and be well on their way to being a regional commercial powerhouse.
Only problem is, South Korea's economy is largely supported via trade with China (and North Korea is downright dependent on Chinese aid). Hence a unified Korea would be somewhat likely to side with China as their main ally in the region. This has the possibility of sucking us into a standoff with China over Japan. Hence we are involved in a much more serious standoff with China, even if no shots are fired.
Yes, a military confrontation with China in some form is probably inevitable. It is not clear whether or not this will take the shape of a shooting war, a standoff, or something else.
Normally, if a security issues is reported to us, we begin communicating with the submitter within a week. From here we can communicate what we are doing, how long it will take, etc. All security issues are fixed on a priority basis, and we do this pretty much as fast as we can.
However, in general nothing is gained by pushing out a fix too soon. Reviewing the problem and solution takes time, as does ensuring that we understand it properly. This is very important for the development of quality fixes.
Generally I would tell customers "one month maximum for most security issues." If we get it done in 48 hours, great (they will be happy).
Fair fa' your honest, sonsie face,
Great chieftain o' the puddin-race!
Aboon them a' ye tak your place,
Painch, tripe, or thairm...
A lot of our bugs which end up being things which are fixed quite quickly once they are understood.
Yes, it speaks loudly that their bugs are fixed in 15 minutes. It means that they are able to get enough information to fix the problem
quickly. Of course, if the fixes are small, minimal testing may be required which can also fit in that time frame.
Now, there *are* unreasonable customers out there, but I agree with you. Most of the time it is an issue of expectations.
One month is an industry-standard maximum one should enforce in the absence of rare and extenuating factors.
Ideally, response time should be a lot less. Here are absolute maximums for general security issues in the absense of such factors:
1) 1 week to reproduce the problem and get back to the submitter of the issue.
2) 1 week of internal review, understanding where the problem is, how serious it is, etc.
3) 1 week of coding and code change review (usually less)
4) 1 week of testing/validation
5) couple of days packaging/releasing/etc.
If these take longer in a significant number of cases, you have bigger problems.
One more option is that you can grant roles to various users and require that they set their role prior to data access.
This doesn;t restrict it based on where they log in from, but the user's application needs to state that it is running reports instead of doing database administration, while when you log in via psql, you have to tell it you are doing admin stuff rather than reporting.
This provides the same enforcement without the headache of worrying what happens if consolidate your reporting system onto the local machine.
My rule is to always assume that the other side will try to enforce the contract. It is only worth consulting with a lawyer if you have decided in advance that you are up for a fight and are willing to take the chance at losing.
Otherwise consult lawyers if you want a second opinion of whether a contract might cover things you hadn't thought of, or to get pre-fight advice. Or to get representation in a fight. Asking "if I sign this, can I safely ignore it" is a stupid question to ask a lawyer unless you are willing to fight it in court, and have the time/money/inclination to do so.
A foot-gun is a device which is mostly useful for shooting yourself in the foot.
BTW, I have been reading a bit about SE-PostgreSQL (Linux-only) which might do all of this on Linux. It brings all the power and flexibility of SELinux to PostgreSQL.
The way we are trying to solve the OORelational mismatch issue in LedgerSMB is through using a fairly different approach. It works reasonably well, but some programmers complain about the fact that things are fundamnetally relational with OO glue over the top.
What we do is create object method mappings to database procedural interfaces. The procedural interfaces basically function as named queries which retrieve data in expected formats (included nested arrays). Thus we have an objectrelational mapping which is entirely encoded in the database, and could be reused by components in other languages.
The large issues we have with this approach have to do with large numbers of interfaces which an object may need to be using, and some cannot be automatically mapped back in all cases, unless one uses fairly complex interfaces (and some supported versions of PostgreSQL don't do everything we need to do for the complex interfaces, though that will change in a few years).
In the past, I have generally given back to an employer whatever ideas I thought would help them. Why not? I can't implement all my ideas anyway and if I get a bit of goodwill out of it.....
BTW, I have been rewarded for this. I have seen my ideas have an impact on my employers (even when they have been Fortune 500 companies), and even when I didn't get direct credit for the idea, I made sure it was recorded in my record with the company. Some of these former employers are now my customers, so it has all paid off well. BTW, I am happy to give ideas to customers as well.
However, I do not give people ideas I don't think they want to or can implement. That is stupid because in the end, if I go and implement myself, then I may get in trouble with trade secrets provisions. Instead I give business-specific ideas to specific businesses.
They offer a lot of benefits to the workers but they also disrupt a lot of necessary communication between workers and management. Unions are like chemotherapy-- why you would want to experience then when you don't have the disease is beyond me....
In general I would not want to work in a unionized environment nor would I want to work in an environment where unions were able to provide good benefits to the workers on top of what the company could offer. If the company isnt willing to offer it themselves, I don't want to work there....
For security issues we usually have a 48-hr to 1-month turn around time. I think a turnaround time for urgent issues of more than a month is excessive. Minor issues get fixed based on a number of factors and the turnaround time varies from 24 hours to 3 months.
In case you are wondering why the floor on the security issue fixes is a little longer, we usually put the initial problem and the fix through extra review so we ensure we truly understand the problem and that the fix solves all likely related issues. Then we have to decide whether to do a patch or a maintenance release. This process adds additional time.
Having said this, it is impossible to know from the description whether the customer is being reasonable or not. I have had issues where I had to come up with a fix within 24 hours and other cases where the demand was unreasonable. Hope this helps.
1) What is the business impact of the bug?
2) What is the data integrity impact of the bug?
That still seems like a footgun to me. It is better to use an administrative user for the admin functions. This introduces a lot less complexity and creates fewer problems down the road as components migrate around the network. In short it seems to me that you are making either the administration or the reporting entirely non-portable from a network perspective.
In PostgreSQL if you really need to do this, I you can use security definer stored procedures which could check for arbitrary other criteria and deny permission on that basis. Sure it is more difficult, and it is better to avoid situations where moving a component around a network can cause privelege escallation.
In PostgreSQL, see ltree and tablefunc contrib modules for navigational access.
LedgerSMB 1.3 will be storing the arbitrary depth nested menus in the db and use tablefunc's connect_by() to generate the tree.
BTW, I think Oracle uses CONNECT BY while DB2 uses WITH RECURSIVE. I could be wrong, however.
Does the phrase "work to rule" ring a bell?
Spend your entire day documenting every idea you have had and send it to the appropriate place. This means you don't get any real work done. Also send a formal request to your manager, the legal department, etc. to get it limited in scope.
That is actualy incredibly bad advice. Note that when I did this at Microsoft, I made sure I had additional protections in place (basically an amendment to the contract which allowed me to run my own business and retain the intellectual property).
A better solution is to start a business which doesn't compete with your employer, ask for your employer's permission to do so, and get an ammentment that says that any IP created for that business is owned by that business (i.e. you). Then you can release it under whatever license you want.
Non-compete clauses have a valid purpose, i.e. to prevent leakage of valid trade secrets from one business to a competitor. It seems that if I say "I am hiring to to work on building this great LDAP server and this contract states that you cannot help other companies build products which compete with this specific product for a period of 6 months after employment" (btw similar in scope to the standard non-compete at Microsoft), this doesn't seem to be a problem.
OTOH, if I say "You may not work for any company which competes with us in any capacity" that is fundamentally different.
When I was at Microsoft, I was an hourly employee doing tech support. The employment contract had all these wonderful provisions such as including all of these things that were mentioned.
First, I negotiated exceptions like crazy (Microsoft to their credit has processes open for doing this). Secondly I tracked the time I spent on my own projects. I figured that if they wanted my software, and forced me to assign them IP rights, then I would charge them for all the time (at time and a half) for the time I spent on each project from the beginning. Finally I negotiated a broad exception to include all of my own ideas not related to Microsoft trade secrets I had access to (which weren't many). Everything worked well.
I am not sure about that. I have been looking for good Perl and/or PL/PGSQL programmers willing to do paid work on FOSS projects from home offices for a while and gotten nowhere. If people are interested in sending me resumes, my email address is mailto:chris@metatrontech.com.
Conversely, remember that the singular for "They" is "that" (etymologically speaking, at least) ;-)
"Why would you do that?" then takes on sexual connotations....
Very few Americans bought the line about Saddam being linked to Al Qaeda. Interestingly, the ICG did an interesting analysis of Powell's presentation and concluded that if there were an Al Qaeda training camp, it was in the area controlled by the Patriotic Union of Kurdistan (our supposed allies).
Most people did assume that he had biological and chemical weapons, and there was an open question about nuclear weapons development.
A few of us understood the real reason for the war and understood that those even if true were not relevant to the question of it. The fact is that the presence of US troops in Saudi Arabia in order to contain Saddam was playing into the hands of Al Qaeda propaganda, and destabilizing the region. The idea was simple: redeploy those forces to Iraq as part of a containment policy on Iran. The problem is that this was unethical and immoral, and we have seen the results first-hand (our approach to North Korea is built on the same sort of mentality, and it is one of the greatest mistakes, foreign-policy-wise of our day. Long run, it has the capacity to hurt us far more than Iraq does).
BTW, yes, it is all about oil. The issue is that we get most of our oil from the Middle East and so fear of disruption of oil supplies is the guiding principle for US involvement in the Middle East. It is not about control of oil but rather security of supply (remember that the Japanese Navy in WWII was defeated decisively by cutting off access to oil).
BTW, about the PDRK (N. Korea). The US has a policy of isolating Kim Jong Il (what US News and World Report compared to "Threatening a drowning man with a life preserver"), purposefully prolonging the independent existance of the PDRK for the sole reason of our fear of Chinese involvement. The issue is that South Korea's economy is largely dependent on trade with China, and there is thus fear that a unified Korea would side with China against the US. The fact that the Korean War is still not officially over prevents this from happening however. Hence we do everything we can to delay reunification so we don't end up involved in a larger China/Japan standoff. The problem with this view is that most Koreans want eventual reunification, and so we are likely to cause the specific problem that we fear through our reactions today.