Are you accounting for the cost of researching dozens of dead-end candidate drugs before finding something that seems to work, running expensive, time-consuming (time is money) and dangerous clinical trials to find out that some of those which work have unacceptable side-effects, and finally going to market with the small percentage that make it all the way through the process to FDA approval?

I'm not saying that pharma companies always price things fairly, but claims of "1000x" on an industry-wide level are a gross exaggeration - cynical anti-capitalist propaganda targeting the ignorant. The industry's profits are nowhere even vaguely close to being that high. If you want to make accusations, keep them factual; it's not like it's hard to cite real evidence of corruption and greed...

Isara's concern, above, was about the legislature being forced to televise meetings that it doesn't want to. kenh incorrectly implied that the proposed law has nothing to do with that.

If the legislature was actually comfortable with recordings of every public meeting being freely available, they wouldn't have imposed a sweeping (and probably unconstitutional) ban on some of their most important uses:

You're rambling in this paragraph. I can't tell what your point really is, or who you're criticizing. The provisions of Prop 54 relating to the recordings of public meetings make up a majority of its non-boilerplate text, and I don't see what's "petty" about wanting their existence acknowledged.

Again, this is not true. DisplayPort has been pushed by other companies (NVIDIA, AMD, Dell, probably others) for years now; they just don't subscribe to Apple's "all or nothing" approach. My household has multiple DisplayPort systems, none of which include any Apple components. DisplayPort is favored by the computer industry because it's royalty-free and technically superior. Momentum and home theatre equipment are what keep HDMI alive.

Likewise, USB-C is not "foregin"; it's the official next-generation USB connector, which will eventually be used everywhere. It started appearing on high-end Android (not Apple!) phones last year.

Although the MacBook Pro does not implement this feature (and thus should indeed have included an HDMI port), USB-C is actually electrically compatible with HDMI, just like it is with DisplayPort. It is intended to eliminate the need for separate dedicated video ports in the interest of compactness (crucial for phones) and simplicity.

A fast, reliable, wired Ethernet port is always a good thing to have, but is unfortunately incompatible with Apple's endless quest for "thin". I don't personally think that a "Pro" laptop actually ought to prioritize "thin" over functionality - but then, I don't buy Macs anyway...

Why would you buy Apple's adapters? USB is an industry standard; there are a zillion other vendors offering Type C adapters.

True.

Prop 54 does not make every meeting public. It just says that if a meeting is open to the public, then it must also be recorded and posted online, with no bizarre, unconstitutional restrictions on what people can do with the video.

You might try spending 30 seconds looking up Prop 54 on Google before becoming "pretty sure". It does more than one thing:

The author(s) of Prop 54 agree. From the text of the proposed law (section 3, part c; emphasis mine):

As I said to the AC above, "multiple orbits" is not the same as "multiple orbital planes". The launch you reference did nothing which could not have been done by pretty much any launch system with a restartable engine on the upper stage.

All of the satellites on that launch for which I was able to find orbital parameters have the same inclination (98 degrees). I'm sure they have approximately the same longitude of the ascending node, as well.

1) China - like every launch provider - has their own launch failures. When it happens they do their best to fix the problem and move on, just like SpaceX does.

2) The latest Falcon 9 is way more powerful than the original, and has an expendable LEO capacity of 22.8 tons, not 10. It's also got a reusable first stage...

USB hasn't gone anywhere. The new MacBook Pro still fully supports USB; it's just using the new Type C connector standard designed by the USB Implementers Forum, not Apple. Everyone will be using Type C in a few years, but until then you can use a cheap, reliable, passive adapter; electrically it's fully compatible with the old standards.

It is, however, true that they really did drop the SD card reader.

I'm not sure about HDMI; the Type C connector and the Thunderbolt 3 controller are supposed to be compatible, so you should be able to just use a cheap passive adapter. However, Apple makes no mention of this anywere in their specs and they want a whopping $50 for the adapter, which makes me suspicious that they cheaped out and didn't actually include that functionality, even though they presumably could have done so quite easily. On the other hand, Apple accessories are often horribly overpriced, so perhaps a cheap third party passive adapter would work just fine.

While Thunderbolt 3 is proprietary (but to Intel, not Apple), its use is completely optional on the new Macs. USB-C, USB 3.1, and DisplayPort are all industry standards which all major PC vendors are adopting; Apple is just ahead of the curve.

Adapters are required because the USB-C connector is too new, not because it is proprietary. In two to five years, most new peripherals will not require the adapter, regardless of which company made them. The real issue is that by the time the adapters aren't needed anymore, this year's crop of MacBook Pros will be starting to wear out.

There is a big difference between "multiple orbits" and "multiple orbital planes". Any rocket with a restartable upper stage can deposit payloads at multiple orbital altitudes, but it is obvious from its specifications that the PSLV doesn't have enough deltaV to reach many widely separated orbital planes in a single launch (and neither does any other present-day launch system).

Those are both way smaller than the PSLV's LEO payload capacity of 3.8 tons, or even its GTO payload capacity of 1.4 tons. Even a shoebox-sized gold brick (~250 kg) doesn't weight nearly that much.

So, the PSLV has the same fundamental problem for such missions as U.S. commercial launchers: it's too expensive to launch tiny satellites one at a time on a huge rocket, which means they have to be launched in batches. But, satellites launched in batches are all deposited in the same orbital plane. That's problematic because different missions require different orbital planes, and making large plane changes after achieving orbit is very, very expensive - especially in LEO.

So, I'm not sure what problem the author thinks the PSLV solves for people launching micro-satellites - it's actually sized for launching medium or mini satellites.

I get the feeling that you don't understand how numerous, complex, arbitrary, diverse, ambiguous, etc. natural languages are. That phrase, "all languages", doesn't even have a knowable, well-defined meaning, either in theory or in practice.

It would certainly be possible to improve upon Unicode, if you're willing to sacrifice backwards compatibility. However, it will never achieve your stated goal of guaranteeing support for "all languages" just by "throwing in" a new text processing library.

Projects that refuse to invest in internationalization will continue to fail badly at it, regardless of whether they use Unicode, or a "lessons learned" successor encoding.

True UTF-16 supports non-BMP code points just fine, and is not a "hack". In fact, it's actually slightly easier to do so in UTF-16 than with UTF-8 (the only other common Unicode encoding).

The real problem is that there is no single concept in Unicode that maps to the "character" of the old, simple ASCII standard with which most programmers are familiar. Depending on the task at hand, the correct substitute under Unicode may be code units, code points, or graphemes. Ignorant and/or lazy programmers who make incorrect selections between those three are the cause of many Unicode-related bugs.

Also, some important "Unicode" APIs were stabilized before the standard evolved into its present complex form, and cannot be completely fixed for backwards compatibility reasons: notably, the Java standard library and the Win32 API.

These problems persist for the same reason that commercial software usually doesn't even try to support Linux: the additional market share (in dollars , not just users) which can be captured is perceived to be worth less than the cost of properly writing, optimizing, and testing the considerably more complex and slower code required for full Unicode support.