Does this also mean the users(who are contributing to the coffers with their use of Firefox) can demand fixes to the nagging bugs and not get a 'if you don't like it fork it' reply?
No, no more than individual users of large commercial software packages that are contributing by actually paying licensing fees can "demand" changes and compel a positive response. They can, of course, request changes, and they can, if they aren't satisfied with the response, stop supporting Mozilla with their use of Firefox or otherwise.
If you want the power to demand changes, run your own project. Otherwise, you'll have to convince the people that are running the project that your requests ought to be a priority. Licensing model and payment schemes are largely irrelevant to this fact.
If what you intend to provide on the internet is just a webapp, that architecture should normally work.
OTOH, if what you want to expose is a database to which other applications (web or otherwise) will attach over the internet, it clearly doesn't work. Admittedly, that's probably a rare use case, but there is no reason that you should be forced to build a webapp with a SOAP, XML-RPC, REST, or some other web-service interface and make your consumers code their software to that, when what you really want to do is expose a database to access across the internet and let your consumers code to the DBs normal TCP/IP interface.
Now, if your database is insecure, that's a problem with your database, just as it would be a problem with your web server if that was insecure. Using a web-service interface running on a web server that isn't vulnerable to exploits as a way of providing a gateway to data residing in a database server that is vulnerable may be a viable workaround for security problems with the database server, but I have to think that the best solution is to just use a database that is secure in the first place.
If enough ignorant people misuse a phrase then that misuse becomes 'common usage'.
Its not "ignorant", and its not "misuse".
The transitive form "Begs the question foo" is distinct from the intransitive form "Begs the question" (the latter with no object). The latter only makes sense when referring to the petitio principi fallacy, the former is equivalent to "raises the question". The are different in form, and therefore unambiguous, they are both in long use, and it is purely misguided and ignorant to claim that the fact that the latter is proper means that the former is somehow improper, incorrect, or wrong in any way.
Phrases in natural language—like functions in many programming languages—may have different semantics with different argument structures.
This isnt a problem for most of the vehicles on the road today since they use primarilly hydraulically actuated power steering, but you can still steer even without hydraulic pressure. Same thing with standard rack-and-pinion and recirculating ball steering systems. For these three types, only a grandma that doesnt expect to loose hydraulic pressure will have any serious problems controlling the car.
I dunno. Maybe in most normal circumstances, but these won't be used in normal circumstances to start with. They'll be used in chases, which are already dangerous situations without the driver unexpectedly losing some measure of steering ability.
Also, are these rays energetic enough for, say, crowd control?
If they can disable the electronics in a car, no doubt they can disable the electronics in cellphones, video cameras, digital cameras, etc., in the target area.
If not directly usable for crowd control, they would at least help disable the modern devices that provide accountability, allowing the police a freer hand to use more primitive techniques of crowd control without restraint.
They all have integers, floats, strings, tuples, datetimes, booleans.
Yeah, most of them do. Though they aren't always the same thing ("strings" and "datetimes" particularly may be different things in different languages, even "floats" may be; ECMAScript doesn't even have real integers, all numbers are IEEE 754 floats, which are precise enough to cover a wide range of integers, and some bit-twiddling operations that pretend they are integers are available.)
None of them have varchars, decimals, timestamps, tiny integers, clobs, blobs, and other weird and esoteric DB types.
Actually, "varchars" are just a kind of string, many languages have either limited-precision or arbitrary precision decimals or more general exact rationals, or both, either natively or provided through libraries (exact rationals are part of the Scheme numeric tower, both arbitrary precision decimals and exact rationals are in the Ruby standard library -- BigDecimal and Rational classes -- and many languages have a variety of different sizes of integers, even if code can be written without much concern for the differences in most cases because of automatic conversion/coercion between compatible types.) And the variety of date/time related constructs available in many languages is a wide or wider than that in SQL, including things that are timestamp-like. Again, lots of times this can be safely ignored in much high-level code because of automatic conversion between compatible types, but that doesn't mean those types aren't features of the language or its libraries.
No offense intended, but in no case should any programmer fail to see that "If you can't correct it, you needn't detect it." is rubbish.
IIRC, its a recommended "best practice" in several languages and environments. But there are underlying assumptions, particularly:
1) That the routines you are calling throw exceptions or do something similar on exceptional states, and 2) That the environment provides a reasonable default response to such exceptions.
In those cases, its a good idea to not check for any exception you can't correct or at least add some useful information to on the way out. You do need, however, to detect error conditions resulting from the way your code is used that aren't thrown as exceptions by lower-level code and throw them as exceptions yourself, leaving your clients to decide whether they can handle them or whether they should instead ignore them and let them bubble up.
So, its not "rubbish", but it needs to be understood in its proper context and not just blindly applied without regard to context.
I've mostly seen it as a recommended best practice in certain functional languages (the "don't program defensively" maxim of Erlang, for instance) where not programming defensively lets crashes happen when they should, which is the exact opposite of the result in C, where not programming defensively usually means that the program continues on happily even in a situation where it should crash.
Sure, if you are providing the apps and the db. If the apps and db are not merely physically separated but also organizationally separate, there is no reason for them to not access each other over the internet. This may, for lots of organizational and competitive reasons, be uncommon in practice, but other than using a bad, insecure database server in the first place, there is no reason that it should be a particular security problem.
Fundamentally, a database server that takes connections over TCP/IP ought to be secure enough to expose on the public internet, and if it isn't, the fundamental problem isn't "you don't have it firewalled", but "you have an insecure database server". If you can exploit a database server over its TCP/IP connection, it is not safe for internal use either, since if you trusted your internal users without limit, you wouldn't need all the user and role-based security included in most database server software, and if it can be exploited to gain access beyond that which users are supposed to have, this is a problem if the exploit is from within as well as if it is from without. Except in a limited number of circumstances (such as a db server that exists solely to serve a particular web application and access to which is physically limited to only completely trusted users and the application itself), there aren't a lot of cases where having a fundamentally insecure server behind a secure firewall really addresses the security concerns.
You/Everyone should really read why the electoral college was designed, Hamilton wrote about it in Federalist #68, though there are more concerns than those he presented there. It's basicly meant to prevent a situation where there are 10 cantidates and 1 guy wins with only 23% of the vote.
Assuming each of the States had equal population, and equal voter turnout, and each applied the plurality-take-all rule, and there were only two candidates in each election, the minimum percentage of the vote necessary to win the Electoral College with a majority would be just over 25% (you need the smallest integer greater than half the votes in each state in the smallest integer number of states greater than half.) With unequal size states, the problem is greater. Assuming equal voter turnout, but the actual inequality in state sizes, it actually takes a minimum of less than 22% even before considering further reductions from multiple candidates.
A better way of managing the problem of multiple candidates splitting the electorate and producing a winner with narrow support is to use a preference voting system in a direct popular election.
It also has consequences beyond presidential elections, it will impact congressional as well. It will move to a coaliton sytle leglislature.
No, eliminating the electoral college would not force a move to a "coalition-style legislature". The electoral college is only used in Presidential elections, members of the House and Senate are already elected by direct popular elections. Eliminating the electoral college would have no direct effect on the Legislative branch.
OTOH, a multiparty legislature wouldn't be as bad as you seem to think—democratic nations that have them have measurably higher public satisfaction with government and its policies than democratic nations that don't.
The Republican in me wants to see a dig on Bush, so I have to hope you remember that Clinton didn't get the popular vote in either election.
Actually, Clinton won popular vote pluralities in both of his elections (that is, he was the highest popular vote getter). Unlike Bush, who only did that in one of his two terms.
Also since we're on party affiliation, there's a good chance that if the electoral college were done away with, The republican party, (or what becomes of it)/religious right, would probably win every election, because as far as overall idealogy goes, Republicans tend to be a bit more monolithic in their overall views throughout the party than do Democrats.
That depends on how the Electoral College were done away with. With a simple elimination with other rules kept the same (non-preference voting, majority required to win, no majority winner means the vote goes to the House voting under the unit rule), the Republicans would have a systemic advantage since, even when they lack a Congressional majority, they usually have a majority in a majority of states (having an advantage in smaller states), which would mean they would have a majority of votes in the House under the unit rule most of the time.
If a well-designed preference system were adopted, of course, both the degree of splitting of due to different candidates of similar ideologies and the tie-breaking procedures would be mostly irrelevant, and the candidate with the broadest national support would tend to be elected irrespective of the geographic distribution of that support.
The electoral college is designed to punish candidates who appeal to a limited geographic region.
Or, alternatively, to reward those who appeal to a particular "limited geographic region", defined specifically as the set of states with the smallest population per state.
The problem is that a properly rigged electronic election won't look suspicious enough to give people any reason to hand recount the paper trail.
A properly executed electronic election will include random precinct hand counts. Any deviation from the official count from those precincts will trigger wider recounts. Even if you build in tolerances for errors in the sample recount, no reasonable system will tolerate errors big enough to be indicative of a rigging effort that would change the result of the election.
So I don't think this is true, unless by "properly rigged", you mean "rigged so that a small enough number of votes are changed that it couldn't possibly affect the outcome".
Any electronic voting that doesn't suck is no better than pen and paper.
Except in (off the top of my head) these areas: 1) Accessibility to voters with various disabilities, and 2a) Economy in the counting process, and 2b) Range of electoral systems (beyond single-member, first-past-the-post) that it is practical to support with substantial district sizes.
(2a and 2b are, really, different aspects of the same feature).
There is no advantage and substantial disadvantages to pen-and-paper voting-and-counting over well-executed electronic voting-and-counting (which requires paper records, and a genuinely random hand audit of a selection of the count, with a full count if there are substantial discrepancies).
OTOH, that's not to say electronic voting and counting are necessarily better, it may be the case that well-executed electronic voting and counting is not politically attainable, and that the best we can get in that area is worse than the best we can get going pen-and-paper. But done right, electronic has a lot to offer.
Databases will certainly be faster and simpler if they adopted the data types and principles of modern programming languages.
Different modern programming languages have different data types and principles. Scheme, Erlang, Ruby and C# are all "modern programming languages", and have distinct sets of basic data types, and different ways of going beyond the basics. A database specialized to fit with any one of them might be simpler to develop for in that language, and might be faster in common use cases for the language it is designed to accompany. It would also likely be as hard or harder to develop for, and less efficient in use, when accessed from the languages it is not adapted to.
Of course, many modern programming languages have, either in their standard libraries or available as third partiy librarires, native datastores adapted to the datatypes and principles of the language. And that seems, IMO, to be the best place for datastores tightly bound to the assumptions of a particular language.
For example, we now take it for granted that the OS should implement a disk file as a simple byte stream
I would say, instead, that we take it for granted that the OS should provide access to a disk file as a simple byte stream. I don't think there is consensus at all that there is one true way to implement a disk file, or whether that is even necessarily the job of the OS, as such, rather than replaceable modules, different sets of which may be found in use with any particular instance of the same OS.
I'm not sure if any database can do this but what an OODBMS should really do is allow you to execute queries over an arbitrary navigational structure. For instance I should be able to ask questions like, "Can I get to an object O satisfying O.x+O.y=O.z by starting with object A and following A.next and A.prev as many times as needed."
Oracle can do that for lots of the most common constructs heirarchical queries (with the CONNECT BY construct); DB2 has what I believe is a more general solution with recursive queries (with the WITH construct).
If there's no "we allow an obscure government agency look at everything you read, write, say and listen to without court order or accountability" clause, can we sue the fuckers?
They are being sued; that's why this is news.
OTOH, Congress is already discussing a law which would provide them retroactive immunity from such suits.
"Commissioners of the Elections Board, which has been sued by the federal agency for not complying with election-modernization law, voted 3-1 to take up the matter in closed session." Italics mine.
That's a clear sign it's out of the voters hands.
Public board always take up lawsuits in closed session; one reason is that part of dealing with lawsuits its receiving, discussing, and making decisions about communications with counsel which could jeopardize the position of the agency in the suit if they were public.
There is nothing particularly nefarious about this.
and even the diodes will be more expensive if they're buying them in small quantities.
True, but not really relevant. If Blu-Ray dies, Sony's not dropping out of the media market, they'll acquire whatever licenses they need to start producing HD-DVD drives, so they'll be buying the diodes (if not other components) in substantial quantities.
If you haven't tried 1-800-GOOG-411 ; it's pretty awesome for getting said phone numbers, and automatically connecting you if you like. Tied in to a phone with Google Maps and GPS/e911?
If you have Google Maps installed on a smartphone (at leat, the version for the Treo; I assume its the same on any of them), you can just search for the restaurant in Maps, and when you get the result, directly call it (or add it to the contacts list in your phone.)
I'm not dissing GOOG-411, which I haven't tried, but if you've got Maps, calling someone to get a business phone number is often superfluous.
I guarantee that you'll think that cancer research needs more funding and that searching for aliens suddenly doesn't seem so important.
Transferring all global SETI expenditures (money and in-kind) to cancer research wouldn't make a difference noticeable unless you were looking out about 4 decimal places. If you are just talking about public funds, it would hardly show up at all, even in absolute terms.
Cancer research might need more funding, but everyone involved stopping all SETI activities and devoting those resources to it won't make a difference. Diverting resources from, say, fighting unnecessary wars, however, could make an enormous difference.
The press spends more money covering SETI than the scientists spend actually doing it. Just because something involves "space" doesn't mean that it has a NASA-like budget.
Heck, even NASA doesn't have a "NASA-like" budget, if by "NASA-like" you mean "like NASA at the height of the Apollo program, which shaped popular perception". Adjusted for inflation, NASA's present budget is about half of its 1966 budget.
It's called "dumping", and in the U.S., is illegal when conducted by a monopolist.
And not just "when done in the US". If its done anywhere in the world with the intent (even if its not the only intent) of reinforcing a US monopoly (such as, say, by preventing broader global adoption of Linux which would put pressure on US marketshare as more desirable software was available exclusively for Linux, providing an incentive for people to switch from Windows) it can violate US antitrust law.
Ever since the Lockheed bribery scandal [wikipedia.org], its been illegal for US citizens or corporations to bribe anyone, anywhere in the world,
Yes, but its rather dubious whether paying a company involved in an enterprise a fee to replace a product they've already purchased for use in that enterprise with your product is legally a "bribe". Had they directly paid Nigerian government officials to direct the company to drop Linux and adopt Windows, that would be different.
Anywho, the US government let them off with barely a slap on the wrist when they were found guilty of violating anti-trust law, you think there is going to be much effort for pressing this kind of issue?
Slashdot Mirror
No, no more than individual users of large commercial software packages that are contributing by actually paying licensing fees can "demand" changes and compel a positive response. They can, of course, request changes, and they can, if they aren't satisfied with the response, stop supporting Mozilla with their use of Firefox or otherwise.
If you want the power to demand changes, run your own project. Otherwise, you'll have to convince the people that are running the project that your requests ought to be a priority. Licensing model and payment schemes are largely irrelevant to this fact.
If what you intend to provide on the internet is just a webapp, that architecture should normally work.
OTOH, if what you want to expose is a database to which other applications (web or otherwise) will attach over the internet, it clearly doesn't work. Admittedly, that's probably a rare use case, but there is no reason that you should be forced to build a webapp with a SOAP, XML-RPC, REST, or some other web-service interface and make your consumers code their software to that, when what you really want to do is expose a database to access across the internet and let your consumers code to the DBs normal TCP/IP interface.
Now, if your database is insecure, that's a problem with your database, just as it would be a problem with your web server if that was insecure. Using a web-service interface running on a web server that isn't vulnerable to exploits as a way of providing a gateway to data residing in a database server that is vulnerable may be a viable workaround for security problems with the database server, but I have to think that the best solution is to just use a database that is secure in the first place.
Its not "ignorant", and its not "misuse".
The transitive form "Begs the question foo" is distinct from the intransitive form "Begs the question" (the latter with no object). The latter only makes sense when referring to the petitio principi fallacy, the former is equivalent to "raises the question". The are different in form, and therefore unambiguous, they are both in long use, and it is purely misguided and ignorant to claim that the fact that the latter is proper means that the former is somehow improper, incorrect, or wrong in any way.
Phrases in natural language—like functions in many programming languages—may have different semantics with different argument structures.
I dunno. Maybe in most normal circumstances, but these won't be used in normal circumstances to start with. They'll be used in chases, which are already dangerous situations without the driver unexpectedly losing some measure of steering ability.
If they can disable the electronics in a car, no doubt they can disable the electronics in cellphones, video cameras, digital cameras, etc., in the target area.
If not directly usable for crowd control, they would at least help disable the modern devices that provide accountability, allowing the police a freer hand to use more primitive techniques of crowd control without restraint.
Yes, they do.
Yeah, most of them do. Though they aren't always the same thing ("strings" and "datetimes" particularly may be different things in different languages, even "floats" may be; ECMAScript doesn't even have real integers, all numbers are IEEE 754 floats, which are precise enough to cover a wide range of integers, and some bit-twiddling operations that pretend they are integers are available.)
Actually, "varchars" are just a kind of string, many languages have either limited-precision or arbitrary precision decimals or more general exact rationals, or both, either natively or provided through libraries (exact rationals are part of the Scheme numeric tower, both arbitrary precision decimals and exact rationals are in the Ruby standard library -- BigDecimal and Rational classes -- and many languages have a variety of different sizes of integers, even if code can be written without much concern for the differences in most cases because of automatic conversion/coercion between compatible types.) And the variety of date/time related constructs available in many languages is a wide or wider than that in SQL, including things that are timestamp-like. Again, lots of times this can be safely ignored in much high-level code because of automatic conversion between compatible types, but that doesn't mean those types aren't features of the language or its libraries.
IIRC, its a recommended "best practice" in several languages and environments. But there are underlying assumptions, particularly:
1) That the routines you are calling throw exceptions or do something similar on exceptional states, and
2) That the environment provides a reasonable default response to such exceptions.
In those cases, its a good idea to not check for any exception you can't correct or at least add some useful information to on the way out. You do need, however, to detect error conditions resulting from the way your code is used that aren't thrown as exceptions by lower-level code and throw them as exceptions yourself, leaving your clients to decide whether they can handle them or whether they should instead ignore them and let them bubble up.
So, its not "rubbish", but it needs to be understood in its proper context and not just blindly applied without regard to context.
I've mostly seen it as a recommended best practice in certain functional languages (the "don't program defensively" maxim of Erlang, for instance) where not programming defensively lets crashes happen when they should, which is the exact opposite of the result in C, where not programming defensively usually means that the program continues on happily even in a situation where it should crash.
Sure, if you are providing the apps and the db. If the apps and db are not merely physically separated but also organizationally separate, there is no reason for them to not access each other over the internet. This may, for lots of organizational and competitive reasons, be uncommon in practice, but other than using a bad, insecure database server in the first place, there is no reason that it should be a particular security problem.
Fundamentally, a database server that takes connections over TCP/IP ought to be secure enough to expose on the public internet, and if it isn't, the fundamental problem isn't "you don't have it firewalled", but "you have an insecure database server". If you can exploit a database server over its TCP/IP connection, it is not safe for internal use either, since if you trusted your internal users without limit, you wouldn't need all the user and role-based security included in most database server software, and if it can be exploited to gain access beyond that which users are supposed to have, this is a problem if the exploit is from within as well as if it is from without. Except in a limited number of circumstances (such as a db server that exists solely to serve a particular web application and access to which is physically limited to only completely trusted users and the application itself), there aren't a lot of cases where having a fundamentally insecure server behind a secure firewall really addresses the security concerns.
I don't think you've made that any less likely with that post...
Assuming each of the States had equal population, and equal voter turnout, and each applied the plurality-take-all rule, and there were only two candidates in each election, the minimum percentage of the vote necessary to win the Electoral College with a majority would be just over 25% (you need the smallest integer greater than half the votes in each state in the smallest integer number of states greater than half.) With unequal size states, the problem is greater. Assuming equal voter turnout, but the actual inequality in state sizes, it actually takes a minimum of less than 22% even before considering further reductions from multiple candidates.
A better way of managing the problem of multiple candidates splitting the electorate and producing a winner with narrow support is to use a preference voting system in a direct popular election.
No, eliminating the electoral college would not force a move to a "coalition-style legislature". The electoral college is only used in Presidential elections, members of the House and Senate are already elected by direct popular elections. Eliminating the electoral college would have no direct effect on the Legislative branch.
OTOH, a multiparty legislature wouldn't be as bad as you seem to think—democratic nations that have them have measurably higher public satisfaction with government and its policies than democratic nations that don't.
Actually, Clinton won popular vote pluralities in both of his elections (that is, he was the highest popular vote getter). Unlike Bush, who only did that in one of his two terms.
That depends on how the Electoral College were done away with. With a simple elimination with other rules kept the same (non-preference voting, majority required to win, no majority winner means the vote goes to the House voting under the unit rule), the Republicans would have a systemic advantage since, even when they lack a Congressional majority, they usually have a majority in a majority of states (having an advantage in smaller states), which would mean they would have a majority of votes in the House under the unit rule most of the time.
If a well-designed preference system were adopted, of course, both the degree of splitting of due to different candidates of similar ideologies and the tie-breaking procedures would be mostly irrelevant, and the candidate with the broadest national support would tend to be elected irrespective of the geographic distribution of that support.
Or, alternatively, to reward those who appeal to a particular "limited geographic region", defined specifically as the set of states with the smallest population per state.
A properly executed electronic election will include random precinct hand counts. Any deviation from the official count from those precincts will trigger wider recounts. Even if you build in tolerances for errors in the sample recount, no reasonable system will tolerate errors big enough to be indicative of a rigging effort that would change the result of the election.
So I don't think this is true, unless by "properly rigged", you mean "rigged so that a small enough number of votes are changed that it couldn't possibly affect the outcome".
Except in (off the top of my head) these areas:
1) Accessibility to voters with various disabilities, and
2a) Economy in the counting process, and
2b) Range of electoral systems (beyond single-member, first-past-the-post) that it is practical to support with substantial district sizes.
(2a and 2b are, really, different aspects of the same feature).
There is no advantage and substantial disadvantages to pen-and-paper voting-and-counting over well-executed electronic voting-and-counting (which requires paper records, and a genuinely random hand audit of a selection of the count, with a full count if there are substantial discrepancies).
OTOH, that's not to say electronic voting and counting are necessarily better, it may be the case that well-executed electronic voting and counting is not politically attainable, and that the best we can get in that area is worse than the best we can get going pen-and-paper. But done right, electronic has a lot to offer.
Different modern programming languages have different data types and principles. Scheme, Erlang, Ruby and C# are all "modern programming languages", and have distinct sets of basic data types, and different ways of going beyond the basics. A database specialized to fit with any one of them might be simpler to develop for in that language, and might be faster in common use cases for the language it is designed to accompany. It would also likely be as hard or harder to develop for, and less efficient in use, when accessed from the languages it is not adapted to.
Of course, many modern programming languages have, either in their standard libraries or available as third partiy librarires, native datastores adapted to the datatypes and principles of the language. And that seems, IMO, to be the best place for datastores tightly bound to the assumptions of a particular language.
I would say, instead, that we take it for granted that the OS should provide access to a disk file as a simple byte stream. I don't think there is consensus at all that there is one true way to implement a disk file, or whether that is even necessarily the job of the OS, as such, rather than replaceable modules, different sets of which may be found in use with any particular instance of the same OS.
Oracle can do that for lots of the most common constructs heirarchical queries (with the CONNECT BY construct); DB2 has what I believe is a more general solution with recursive queries (with the WITH construct).
They are being sued; that's why this is news.
OTOH, Congress is already discussing a law which would provide them retroactive immunity from such suits.
Public board always take up lawsuits in closed session; one reason is that part of dealing with lawsuits its receiving, discussing, and making decisions about communications with counsel which could jeopardize the position of the agency in the suit if they were public.
There is nothing particularly nefarious about this.
True.
True, but not really relevant. If Blu-Ray dies, Sony's not dropping out of the media market, they'll acquire whatever licenses they need to start producing HD-DVD drives, so they'll be buying the diodes (if not other components) in substantial quantities.
If you have Google Maps installed on a smartphone (at leat, the version for the Treo; I assume its the same on any of them), you can just search for the restaurant in Maps, and when you get the result, directly call it (or add it to the contacts list in your phone.)
I'm not dissing GOOG-411, which I haven't tried, but if you've got Maps, calling someone to get a business phone number is often superfluous.
Transferring all global SETI expenditures (money and in-kind) to cancer research wouldn't make a difference noticeable unless you were looking out about 4 decimal places. If you are just talking about public funds, it would hardly show up at all, even in absolute terms.
Cancer research might need more funding, but everyone involved stopping all SETI activities and devoting those resources to it won't make a difference. Diverting resources from, say, fighting unnecessary wars, however, could make an enormous difference.
Heck, even NASA doesn't have a "NASA-like" budget, if by "NASA-like" you mean "like NASA at the height of the Apollo program, which shaped popular perception". Adjusted for inflation, NASA's present budget is about half of its 1966 budget.
And not just "when done in the US". If its done anywhere in the world with the intent (even if its not the only intent) of reinforcing a US monopoly (such as, say, by preventing broader global adoption of Linux which would put pressure on US marketshare as more desirable software was available exclusively for Linux, providing an incentive for people to switch from Windows) it can violate US antitrust law.
Yes, but its rather dubious whether paying a company involved in an enterprise a fee to replace a product they've already purchased for use in that enterprise with your product is legally a "bribe". Had they directly paid Nigerian government officials to direct the company to drop Linux and adopt Windows, that would be different.
Anywho, the US government let them off with barely a slap on the wrist when they were found guilty of violating anti-trust law, you think there is going to be much effort for pressing this kind of issue?