Greater LA is roughly 16 million people. Of that population, roughly 55,000 are actual KCRW subscribers. And it's not just one station. As I said before there's at least one other listener-supported station in the LA area - I want to say it's KLON, but I'm not sure. There may be others, but once I found KCRW I stopped looking (I liked it so much that I still listen to it now that I'm not in LA).
KCRW is somewhat non-mainstream, and thus caters to a relatively small audience (there is a much larger market in LA for standard top 40 stuff, and Hispanic broadcasting - must be at least 4 or 5 Hispanic stations there). You claim that the "the majority of people in the UK use some service of the BBC". I'm not suggesting an immediate transition from one funding model to another. But perhaps they could try transitioning one unit, and see what happens.
Hey, maybe they'd cut back on all of the "Reality show dross and soaps" that some of the other posters in this thread have been whining about.
And before you pass judgement on what's actually possible under a listener- or viewer-supported scheme, why don't you take a look at KCRW and see how much they actually do. Not that I'm saying they have a 2bn GBP budget. But then, they also service a much smaller market (principally greater LA).
Further more, KCRW is getting contributions from a number of people outside of the LA area, who listen via streaming audio. I would imagine that there are enough people outside of the UK that think the BBC does a good job that the Beeb could also gather a significant contribution from overseas sources (they certainly already have a higher presence outside of their immediate market than KCRW does). I'd happily throw some money in the pot to support stuff like the BBC News website and some of their documentaries.
Which is nice for you, since you actually use some of their content. Not so good for the people who don't.
Perhaps instead of a mandatory licence fee you could consider a "community-supported" style of broadcast, based on voluntary contributions from users who see value in the service. It's neither conventionally commercial, or mandatorily publicly funded.
Can such a thing actually work in practice? Well, one has only to look at KCRW in Los Angeles for an example of a community-supported station that is thriving. Their programming is significantly better than the drivel on regular commercial radio, and people are willing to support that. With the advent of streaming internet radio they even tend to get large contributions from outside the state. IIRC KCRW isn't even the only LA-based community-supported radio - there's at least one Jazz station that I remember hearing, and there may be others.
I personally don't buy into the whole XP/Agile methodology, but I do think that they're on to something with their test-driven approach. Of course, what they're on to is getting back to actually writing real requirements, instead of the fluff that passes for requirements documents these days, but that's beside the point.
Ultimately, requirements are supposed to define what the customer will consider an acceptable product. Too often what they end up being is a bunch random features which may or may not actually solve the customer's problem, as well as a bunch of other drivel which really has no relevance to the customer's acceptability criteria and often represent premature design decisions.
Test-driven development essentially returns us to the idea of defining an acceptable product, and then producing a design which meets the acceptability criteria. It has the added advantage that the "requirements" are now expressed in a well-defined language with formal syntax and standard(ish) semantics, instead of vague wishy-washy natural language. The only drawback I see is that the language involved is (a) not necessarily amenable to consistency analyses beyond static type-checking, and (b) may express things at such a low level that validation is hard. I'd rather see the requirements/tests expressed in a higher-level formal language (Z, B, CSP, LOTOS, VDM, etc.), with test-case code automatically generated from the formal requirements. If the requirements change, the test-cases can easily be regenerated, and the implementation redeveloped to pass the new test-cases (assuming it doesn't pass them as is).
* Juggles the books if necessary to increase the stock proce. His job, by law, is to maximize shareholder value. Period.
But on what timescale is that shareholder value supposed to be maximized? Juggling the books will not produce long term maximization of value, just short term peaks in stock price. Not that I'm saying that there aren't CEOs that do this, merely that what they are doing is not necessarily their "legal duty" (which is presumably why they get prosecuted when they get caught - cf Enron and Worldcom).
Intuitive. But wrong. Libration points (or Lagrange points) are a dynamical balance between the gravitational forces of the two primary bodies, and the centripetal acceleration of the rotation of the three-body system. That's why there are libration points on the outside of each of the two primaries (L2 and L3), as well as one between them (L1). Plus two points located equidistant from both primaries (usually labelled L4 and L5).
Excluding the people who disagree, and then saying "everyone agrees" really doesn't tell us much. Not that I don't agree with your basic point, I just think you need to work on your argument a little.
...but in my experience the vast majority of publicly-held companies are amoral, meaning there is no real sense of right/wrong...
And that, really, is the crux of the matter. Publicly-held companies. Companies which no longer exist for any defined purpose aside from "make lots of money for the shareholders" (their "fiduciary duty"). Shareholders who typically have no idea what a company does, or how it obtains its money. Shareholders who act amorally because their separation from the actual running of the company enables them to evade responsibility for the actions of the company.
Which is not to say that there aren't amoral privately-held companies too. But the probem is exacerbated by making a company answerable to uninvolved shareholders. I don't necessarily think that the answer is to eliminate public companies. But perhaps we could at least consider making shareholders more responsible for the actions of the companies in which they own stock.
Disclaimer: I, through my 401K, am just as guilty of being an unaccountable shareholder as anyone else here. I am not claiming to be guilt-free myself, but merely trying to point out where the ultimate guilt lies.
I've had absolutely no problems with Firefox on OS X. In fact, it's been more stable for me than the version on my Linux box. I regularly leave Firefox running for days at a time.
Yeah, it's kind of disturbing just how many headlines in recent years have seemed like they came straight from the pages of the Onion. It's a bad sign when the satirists get out-done by the bizarreness of the "real world".
Huh? Just yesterday Apple released a security update for OS X. That was it. A pure security update. No functionality update. Not the first time I've seen one of those either. I would assume that they do something similar for OS X Server.
First of all, you are confusing CSP the theory with a specific implementation of CSP (occam). SEQ and PAR are occam constructs.
Second, it's not so much that I don't see a connection between "pure FP" and CSP, but rather that I think that the concepts are orthogonal. CSP is a concurrency model. Threads is another concurrency model. Don't think of a CSP as a layer on top of threads, think of it as a different way of representing concurrency. To quote from here:
Most computer science undergraduates are forced to read Andrew Birrell's ``An Introduction to Programming with Threads.'' The SRC threads model is the one used by most thread packages currently available. The problem with all of these is that they are too low-level. Unlike the communication primitive provided by Hoare, the primitives in the SRC-style threading module must be combined with other techniques, usually shared memory, in order to be used effectively. In general, programmers tend not to build their own higher-level constructs, and are left frustrated by needing to pay attention to such low-level details.
For the moment, push Birrell's tutorial out of your mind. This is a different thread model. If you approach it as a different thread model, you may well find it much easier to understand.
What you are referring to as "pure FP" is really "FP + threads". You could just as well implement "FP + CSP" (which is something like what Concurrent ML does - although I'm not sure if ML counts as "pure FP").
The concurrency semantics that implementations of CSP-style concurrency (such as occam) make use of allow a precise and safe one-to-one mapping from theoretical constructs to language constructs. That's the point - there's no need to have "enough knowledge about the properties of the compositional monads", because the concurrency model of CSP makes that knowledge essentially unnecessary.
Yes, you can map CSP style concurrency to thread style concurrency (which is what JCSP) does. You can also map threads to CSP if you want: the advantage of doing that being that you can then mathematically reason about thread interactions, which is not possible directly in the thread regime (in fact, the JCSP team has built and verified a CSP model of Java's monitor-threads concurrency system, as part of the larger effort to ensure the correctness of the JCSP implementation). But instead of going that roundabout route, why not just implement a good concurrency model in the first place?
It is clear that you aren't familiar with CSP at all. There are essentially two components to CSP: a mathematical theory of concurrency that allows for reasoning about concurrent systems, proving behavioral equivalences, checking for deadlock freedom, and other nifty features; and implementations of CSP-style concurrency abstractions for use in real programming.
CSP provides a way to think about concurrency. Theoretical work in CSP is done in mathematical notation. Mechanical verification of CSP models can be carried out by translating those models into CSPm, a machine readable version of CSP that does indeed embed a Haskell-style functional language. However, CSPm is not intended for creating final implementations, merely for modelling and understanding a design at a higher level of abstraction.
Occam provides one implementation of CSP-style concurrency in an actual programming language (literally built into the language). The advantage of doing this is that abstract system models of even very complex systems, that can be verified to be free of deadlock, and to meet their specifications, can easily be translated into equivalent software that will also maintain those properties. It's nice to have those features built into the language, but by no means absolutely necessary - see for example Peter Welch's work on building CSP-style primitives for Java (the JCSP project).
Yes, Haskell provides a Concurrent library with various threading primitives. But the point is that the threads model is decades old, and not the best way to do concurrent programming - it predates monitors (which everyone seems to agree are a good idea), and Hoare discarded his monitor concept to develop CSP due to weaknesses in the monitor idea. But the threads model, while easy to understand, can be very difficult to apply safely in any system above a modest level of complexity. One problem is that threads can often be tightly interdependent, so that their semantics compose in non-trivial ways - the whole skill in multi-threaded programming lies in setting up and staying in control of these complex interactions. On the other hand, parallel composition of CSP processes is mathematically clean, yields no engineering surprises and scales well with system complexity. The result is cleaner concurrent systems, in a much more understandable and maintainable form.
Haskell is a great language. Just not necessarily the best one to use for concurrent applications. Presumably you could build a library of CSP-style primitives for Haskell on top of the existing threads library (similar to JCSP for Java). But it would be nicer if it was built directly into the language (cf occam, Erlang, Newsqueak, or Concurrent ML). If type-systems are your particular fetish then yeah, occam may not be for you - it was originally designed for embedded systems. In that case, you might want to check out Concurrent ML or Erlang instead.
Besides, FOIA does not mean that you can get all of the information that you want from the government. FOIA requests can be refused for a variety of reasons (these reasons are specified in the act). Requests for "sensitive" data are often refused. So computer security isn't moot anyway.
Uh, yeah, you might want to take a look at NASA's FlightLinux project before you make statements like that.
Besides, this story is about WindRiver adding Linux to its lineup, not replacing VxWorks.
Re:um, car's aren't rockets...
on
Hondas in Space
·
· Score: 2, Interesting
Well, except that NASA doesn't actually build rockets either: that would be places like Boeing, Lockheed-Martin, and Orbital Sciences. Not only that, but SpaceX has managed to hire some of the most experienced and well-respected rocket builders in the US. So leaving it to NASA would really be leaving it to the B team at best.
Other points to consider:
SpaceX is building unmanned rockets - people won't die if it doesn't work
Rockets do not have to be ridiculously complicated (which is part of SpaceX's approach). In fact the most reliable rockets in the world tend to be those that minimize complexity as much as possible
Modern cars are becoming ridiculously complicated - and yet they still seem to work
we've been making rockets for years too - the industry has a pretty good understanding of what works and what doesn't
I don't have a fundamental problem with "publicly-owned networks" so long as
They are run on a user pays basis, rather than directly from taxes
They aren't run in monopoly mode, and other players are allowed to enter the market
That's a fine way to place competitive pressure on the telcos and cable companies. I just don't see the point in providing "free" services - the costs still exist, and forcing people who aren't using the service to pay for it seems a little unethical (it's analogous to the legendary "Microsoft Tax" that so many slashdotters like to complain about).
Perhaps you missed my point. Strike that. You did miss my point. There is a big difference between laying cable and setting up RF transmitters. One requires actually creating a physical connection between a service source and the end-user. That costs a lot of money. Every new customer costs money. Changing providers is hard, since it requires laying new cable (unless there's some agreement to share the cable network). In contrast, creating a wireless service in an area only requires setting up a transmitter, not physically connecting to every single user. Yes, there's "physical infrastructure" behind that at some level, but the reality is that the infrastructure is not physically present at the end-user's location. This results in a very different competitive dynamic. Look at the difference between the landline and cell-phone markets.
It's the sort of thing where it isn't really feasible to have more than one organization running the physical infrastructure.
Which might be true if we were talking about physical infrastructure. But we're not. It's a lot easier to have multiple wi-fi hotspots available from one location than it is to lay a new set of cable if you want to change "infrastructure" provider. It's like the difference between landlines (usually a single provider per region) and cell-phones (multiple providers per region).
Telcos aren't competitive.
And what happened? The cable companies stepped in to provide "high-speed internet". Do we have 12Mb/s for $20/month? No, not yet (although I'm about halfway there). On the other hand, how much of that $20/month is subsidized via taxes? How much does that bandwidth really cost?
And yet FedEx and UPS are both legally prevented from handling first class mail. Plus the USPS has all sorts of government provided perks, such as immunity from most OSHA regulations. It's not real competition. Think first class postage would cost as much as it did if FedEx and UPS could compete in that market?
You are correct: L1, L2, and L3 are all unstable equilibrium points. The halo orbits are stable periodic orbits around those equilibrium points. Unfortunately, it turns out that halo orbits are pretty much just an artifact of the "simplified" dynamics of the pure circular three-body model. Once you add slightly eccentric primary orbits, and additional bodies (the other planets), then halo orbits (i.e. purely periodic orbits around libration points) don't exist - all you can get is quasi-periodic (i.e. bounded, but not perfectly repeating) Lissajous orbits. The orbits we are talking about have amplitudes on the order of several hundred thousand km, and "periods" (time from one ascending crossing of the ecliptic plane to the next) on the order of several months (IIRC).
The sail emits carbon monoxide to get its speed boost. You know, the stuff the kills humans almost as fast as dihydrogen monoxide.
Actually, if you RTFA you'll see that they discovered the effect as a result of inadvertently boiling off carbon monoxide, but the paint that the article is about would actually use something like hydrogen (or perhaps methane).
You know, the stuff that burns much faster than dihydrogen monoxide;)
Is it not also the fault of the officials who are unprincipled enough to accept bribes? It takes two to tango after all. Note that I'm not defending the bribers, I just don't see any point in excusing the bribees.
I recently switched to a Powerbook after about 8 years of running Linux almost exclusively. I hadn't touched a Mac in about 15 years, but OS X looked intriguing. I was initially extremely skeptical about the one-button mouse. I planned to get a three-button mouse pretty soon after I got the Powerbook. But I've found that the one button mouse (or glidepoint) really isn't that bad. And the few times I need an extra button I can use "somekey+mouseclick" approach, which is easy enough when your hand is already on the keyboard. Actually, come to think of it, most of the necessity to use an extra mouse button comes from legacy Unix apps I'm running through fink, or stuff like Firefox which doesn't originate with the Mac platform.
It's been 5 months, and I still haven't got around to buying that three-button mouse...
Slashdot Mirror
KCRW is somewhat non-mainstream, and thus caters to a relatively small audience (there is a much larger market in LA for standard top 40 stuff, and Hispanic broadcasting - must be at least 4 or 5 Hispanic stations there). You claim that the "the majority of people in the UK use some service of the BBC". I'm not suggesting an immediate transition from one funding model to another. But perhaps they could try transitioning one unit, and see what happens.
And before you pass judgement on what's actually possible under a listener- or viewer-supported scheme, why don't you take a look at KCRW and see how much they actually do. Not that I'm saying they have a 2bn GBP budget. But then, they also service a much smaller market (principally greater LA).
Further more, KCRW is getting contributions from a number of people outside of the LA area, who listen via streaming audio. I would imagine that there are enough people outside of the UK that think the BBC does a good job that the Beeb could also gather a significant contribution from overseas sources (they certainly already have a higher presence outside of their immediate market than KCRW does). I'd happily throw some money in the pot to support stuff like the BBC News website and some of their documentaries.
Perhaps instead of a mandatory licence fee you could consider a "community-supported" style of broadcast, based on voluntary contributions from users who see value in the service. It's neither conventionally commercial, or mandatorily publicly funded.
Can such a thing actually work in practice? Well, one has only to look at KCRW in Los Angeles for an example of a community-supported station that is thriving. Their programming is significantly better than the drivel on regular commercial radio, and people are willing to support that. With the advent of streaming internet radio they even tend to get large contributions from outside the state. IIRC KCRW isn't even the only LA-based community-supported radio - there's at least one Jazz station that I remember hearing, and there may be others.
Ultimately, requirements are supposed to define what the customer will consider an acceptable product. Too often what they end up being is a bunch random features which may or may not actually solve the customer's problem, as well as a bunch of other drivel which really has no relevance to the customer's acceptability criteria and often represent premature design decisions.
Test-driven development essentially returns us to the idea of defining an acceptable product, and then producing a design which meets the acceptability criteria. It has the added advantage that the "requirements" are now expressed in a well-defined language with formal syntax and standard(ish) semantics, instead of vague wishy-washy natural language. The only drawback I see is that the language involved is (a) not necessarily amenable to consistency analyses beyond static type-checking, and (b) may express things at such a low level that validation is hard. I'd rather see the requirements/tests expressed in a higher-level formal language (Z, B, CSP, LOTOS, VDM, etc.), with test-case code automatically generated from the formal requirements. If the requirements change, the test-cases can easily be regenerated, and the implementation redeveloped to pass the new test-cases (assuming it doesn't pass them as is).
Ok then: what has Bill Gates stolen?
But on what timescale is that shareholder value supposed to be maximized? Juggling the books will not produce long term maximization of value, just short term peaks in stock price. Not that I'm saying that there aren't CEOs that do this, merely that what they are doing is not necessarily their "legal duty" (which is presumably why they get prosecuted when they get caught - cf Enron and Worldcom).
Intuitive. But wrong. Libration points (or Lagrange points) are a dynamical balance between the gravitational forces of the two primary bodies, and the centripetal acceleration of the rotation of the three-body system. That's why there are libration points on the outside of each of the two primaries (L2 and L3), as well as one between them (L1). Plus two points located equidistant from both primaries (usually labelled L4 and L5).
Excluding the people who disagree, and then saying "everyone agrees" really doesn't tell us much. Not that I don't agree with your basic point, I just think you need to work on your argument a little.
And that, really, is the crux of the matter. Publicly-held companies. Companies which no longer exist for any defined purpose aside from "make lots of money for the shareholders" (their "fiduciary duty"). Shareholders who typically have no idea what a company does, or how it obtains its money. Shareholders who act amorally because their separation from the actual running of the company enables them to evade responsibility for the actions of the company.
Which is not to say that there aren't amoral privately-held companies too. But the probem is exacerbated by making a company answerable to uninvolved shareholders. I don't necessarily think that the answer is to eliminate public companies. But perhaps we could at least consider making shareholders more responsible for the actions of the companies in which they own stock.
Disclaimer: I, through my 401K, am just as guilty of being an unaccountable shareholder as anyone else here. I am not claiming to be guilt-free myself, but merely trying to point out where the ultimate guilt lies.
I've had absolutely no problems with Firefox on OS X. In fact, it's been more stable for me than the version on my Linux box. I regularly leave Firefox running for days at a time.
Yeah, it's kind of disturbing just how many headlines in recent years have seemed like they came straight from the pages of the Onion. It's a bad sign when the satirists get out-done by the bizarreness of the "real world".
Huh? Just yesterday Apple released a security update for OS X. That was it. A pure security update. No functionality update. Not the first time I've seen one of those either. I would assume that they do something similar for OS X Server.
Second, it's not so much that I don't see a connection between "pure FP" and CSP, but rather that I think that the concepts are orthogonal. CSP is a concurrency model. Threads is another concurrency model. Don't think of a CSP as a layer on top of threads, think of it as a different way of representing concurrency. To quote from here:
What you are referring to as "pure FP" is really "FP + threads". You could just as well implement "FP + CSP" (which is something like what Concurrent ML does - although I'm not sure if ML counts as "pure FP").The concurrency semantics that implementations of CSP-style concurrency (such as occam) make use of allow a precise and safe one-to-one mapping from theoretical constructs to language constructs. That's the point - there's no need to have "enough knowledge about the properties of the compositional monads", because the concurrency model of CSP makes that knowledge essentially unnecessary.
Yes, you can map CSP style concurrency to thread style concurrency (which is what JCSP) does. You can also map threads to CSP if you want: the advantage of doing that being that you can then mathematically reason about thread interactions, which is not possible directly in the thread regime (in fact, the JCSP team has built and verified a CSP model of Java's monitor-threads concurrency system, as part of the larger effort to ensure the correctness of the JCSP implementation). But instead of going that roundabout route, why not just implement a good concurrency model in the first place?
CSP provides a way to think about concurrency. Theoretical work in CSP is done in mathematical notation. Mechanical verification of CSP models can be carried out by translating those models into CSPm, a machine readable version of CSP that does indeed embed a Haskell-style functional language. However, CSPm is not intended for creating final implementations, merely for modelling and understanding a design at a higher level of abstraction.
Occam provides one implementation of CSP-style concurrency in an actual programming language (literally built into the language). The advantage of doing this is that abstract system models of even very complex systems, that can be verified to be free of deadlock, and to meet their specifications, can easily be translated into equivalent software that will also maintain those properties. It's nice to have those features built into the language, but by no means absolutely necessary - see for example Peter Welch's work on building CSP-style primitives for Java (the JCSP project).
Yes, Haskell provides a Concurrent library with various threading primitives. But the point is that the threads model is decades old, and not the best way to do concurrent programming - it predates monitors (which everyone seems to agree are a good idea), and Hoare discarded his monitor concept to develop CSP due to weaknesses in the monitor idea. But the threads model, while easy to understand, can be very difficult to apply safely in any system above a modest level of complexity. One problem is that threads can often be tightly interdependent, so that their semantics compose in non-trivial ways - the whole skill in multi-threaded programming lies in setting up and staying in control of these complex interactions. On the other hand, parallel composition of CSP processes is mathematically clean, yields no engineering surprises and scales well with system complexity. The result is cleaner concurrent systems, in a much more understandable and maintainable form.
Haskell is a great language. Just not necessarily the best one to use for concurrent applications. Presumably you could build a library of CSP-style primitives for Haskell on top of the existing threads library (similar to JCSP for Java). But it would be nicer if it was built directly into the language (cf occam, Erlang, Newsqueak, or Concurrent ML). If type-systems are your particular fetish then yeah, occam may not be for you - it was originally designed for embedded systems. In that case, you might want to check out Concurrent ML or Erlang instead.
Besides, FOIA does not mean that you can get all of the information that you want from the government. FOIA requests can be refused for a variety of reasons (these reasons are specified in the act). Requests for "sensitive" data are often refused. So computer security isn't moot anyway.
Besides, this story is about WindRiver adding Linux to its lineup, not replacing VxWorks.
Other points to consider:
- They are run on a user pays basis, rather than directly from taxes
- They aren't run in monopoly mode, and other players are allowed to enter the market
That's a fine way to place competitive pressure on the telcos and cable companies. I just don't see the point in providing "free" services - the costs still exist, and forcing people who aren't using the service to pay for it seems a little unethical (it's analogous to the legendary "Microsoft Tax" that so many slashdotters like to complain about).Perhaps you missed my point. Strike that. You did miss my point. There is a big difference between laying cable and setting up RF transmitters. One requires actually creating a physical connection between a service source and the end-user. That costs a lot of money. Every new customer costs money. Changing providers is hard, since it requires laying new cable (unless there's some agreement to share the cable network). In contrast, creating a wireless service in an area only requires setting up a transmitter, not physically connecting to every single user. Yes, there's "physical infrastructure" behind that at some level, but the reality is that the infrastructure is not physically present at the end-user's location. This results in a very different competitive dynamic. Look at the difference between the landline and cell-phone markets.
Which might be true if we were talking about physical infrastructure. But we're not. It's a lot easier to have multiple wi-fi hotspots available from one location than it is to lay a new set of cable if you want to change "infrastructure" provider. It's like the difference between landlines (usually a single provider per region) and cell-phones (multiple providers per region).
Telcos aren't competitive.
And what happened? The cable companies stepped in to provide "high-speed internet". Do we have 12Mb/s for $20/month? No, not yet (although I'm about halfway there). On the other hand, how much of that $20/month is subsidized via taxes? How much does that bandwidth really cost?
And yet FedEx and UPS are both legally prevented from handling first class mail. Plus the USPS has all sorts of government provided perks, such as immunity from most OSHA regulations. It's not real competition. Think first class postage would cost as much as it did if FedEx and UPS could compete in that market?
You are correct: L1, L2, and L3 are all unstable equilibrium points. The halo orbits are stable periodic orbits around those equilibrium points. Unfortunately, it turns out that halo orbits are pretty much just an artifact of the "simplified" dynamics of the pure circular three-body model. Once you add slightly eccentric primary orbits, and additional bodies (the other planets), then halo orbits (i.e. purely periodic orbits around libration points) don't exist - all you can get is quasi-periodic (i.e. bounded, but not perfectly repeating) Lissajous orbits. The orbits we are talking about have amplitudes on the order of several hundred thousand km, and "periods" (time from one ascending crossing of the ecliptic plane to the next) on the order of several months (IIRC).
Actually, if you RTFA you'll see that they discovered the effect as a result of inadvertently boiling off carbon monoxide, but the paint that the article is about would actually use something like hydrogen (or perhaps methane).
You know, the stuff that burns much faster than dihydrogen monoxide ;)
Is it not also the fault of the officials who are unprincipled enough to accept bribes? It takes two to tango after all. Note that I'm not defending the bribers, I just don't see any point in excusing the bribees.
I recently switched to a Powerbook after about 8 years of running Linux almost exclusively. I hadn't touched a Mac in about 15 years, but OS X looked intriguing. I was initially extremely skeptical about the one-button mouse. I planned to get a three-button mouse pretty soon after I got the Powerbook. But I've found that the one button mouse (or glidepoint) really isn't that bad. And the few times I need an extra button I can use "somekey+mouseclick" approach, which is easy enough when your hand is already on the keyboard. Actually, come to think of it, most of the necessity to use an extra mouse button comes from legacy Unix apps I'm running through fink, or stuff like Firefox which doesn't originate with the Mac platform.
It's been 5 months, and I still haven't got around to buying that three-button mouse...