DOH! I *knew* I should've read the freakin' article before writing that.

Obviously, the article is talking about scripting languages, languages that (typically) run inside of a hopefully-OS-independent-behavior runtime rather than a traditional compiled language that doesn't contain a lot of "runtime" between the compiled code and the operating system.

If the language specification doesn't expressly say what happen when things "outside the design" happen, then different implementations may work differently.

For example:

If the language design spec says

"If an array index is out of bounds, exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program,"

that may seem very specific, but if how to "exit the program and return a value of ABEND_ARRAY_BOUNDS_VIOLATION to the calling program," isn't specified by someone (usually the operating system), then it may not be specific enough. if different operating systems specify how to do this differently, then expected "under the hood" behavior will not necessarily be consistent across operating systems.

For example, does "exit the program" mean simply returning control to the caller, or does it mean explicitly returning any resources that were previously granted to the program by the operating system first? Or is that optional? If it's optional as far as the operating system is concerned, does the language provide a compile- or run-time switch to force such a cleanup? Does returning memory to the operating system guarantee that the OS will sanitize the memory, and if not, does the language guarantee it? If the language doesn't guarantee it, does the language provide a compile- or runtime switch so the program will sanitize memory prior to returning it to the operating system?

These differences in language implementations and even differences in how operating systems handle the starting and stopping of processes can lead to differences in what the code actually does. Usually these differences are unimportant but sometimes they are very important.

Back in the days of race-based "red-lining" and "Whites-only" legally-enforced racially-segregated neighborhoods, rich and middle-class African-Americans had to live in the "non-white" part of town, along with the poor African-Americans and other non-Whites.

Once the zoning laws, deed restrictions, and race-based morgtage- and homeowners-insurance redlining disappeared, non-Whites had as much choice as white people when it came to where they wanted live. Money or lack of it still limited their choices, but their skin color was no longer a barrier.

Now, middle-class African-Americans who move into a city are likely to move into a "middle class" neighborhood, not a "Black" neighborhood.

We went from a society that had a more distinct "Black middle class" that was created out of racial discrimination into one where if there is a "Black middle class" that's distinct from a "Middle class" the distinction is much weaker than it once was, but where there is no legally-enforced racial discrimination and much less (and someday soon I hope, no) racial discrimination denying African-Americans and other non-Whites the same rights and opportunities enjoyed by White people.

I for one don't want to undo the last 50 years of racial desegregation just to bring back the distinct "Black middle class."

Likewise, I don't think we should deny today's children the ability to hear - albeit in a limited way - just to preserve "Deaf culture."

Getting on the plane is only part of the "game."

Unless you plan on doing something bad on the plane that will get you arrested or killed anyways, you also have to never be caught, even after the fact. Or at least delay your capture until all relevant criminal and civil statutes of limitations have run out.

Given that there are cameras everywhere these days, "Good luck with that."

Even then you have to worry about countries retroactively extending the statutes of limitations if their Constitutions/Basic Laws/whatever allow for it (In the last 10-20 years, California [USA] retroactively re-instated the right to sue for damages for certain decades-old torts).

To those who say "it's the bad guys who plan on hurting themselves or others once onboard" I say "You are right, that is an issue that needs to be addressed, but that's outside the scope of my comment, please start another thread."

For people who are packing light ("what fits on your backpack, no more"), increase the use of buses and provide (more?) safe/monitored parking in a "nearby" town at a reasonable price. Better yet, increase any fees paid by attendees to subsidize the cost, so those who do not use the in-city parking pay for part of the cost so as to encourage more use.

I don't know if this 2-lane highway has "full-service" shoulders on it, but if it does, get a permit from the state to allow these buses and other very-high-occupancy vehicles to use the shoulders, the same way that some roads in hurricane-areas have "full service shoulders" that are open during a hurricane evacuation.

Heck, for that matter, if the 2-lane road "could" be safely re-striped as a 3-lane road, pay to have it re-striped with the middle lane going inbound at the start and outbound at the end. Yes, that's a lot of money so barring a big donation it may not be feasible, but it's worth at least looking into.

... everyone suffers.

A general word to any leader who prevents a highly-valued contributor from contributing: If enough influential downstream users don't like this, you may not have the political capital to do this the next time you think you need to do the same thing.

This is not a comment on this specific situation - I am way too ignorant to even begin to know if Linus or Sievers has the higher moral ground or for that matter if either of them have the higher moral ground. It's just a general warning that this kind of action may require spending "political capital," and political capital can run out quickly if it is not continually re-earned.

They were big honking connectors with big fat cables, but at least you didn't have to worry about which end went where. Plus, every cable was an extension cable.

They aren't the only hermaphroditic connectors available.

Due to the lack of enough (or any?) use of a random-event-generator, some early versions of the original Pac-Man arcade game had "canned solutions" that worked for every level. After the hardest level, the hardest level just repeated itself forever. One version ended at the "5th key" and another at the "9th key."

I say "some early versions" - it might be "all versions." I don't know if there were any other versions of the official Pac Man arcade game back in its heyday.

So THAT'S why the typical rotating amusement-park space station is smaller than your other typical rotating space stations!

... used to be easy to do. Then the companies got wind that people were using them to "see through clothing" and made it impractical for most hobbyists.

Google Glass is one thing but as soon as people clamor OMG to the press and politicians loud enough, commercial companies will be afraid to market this to consumers and legislators may step in to criminalize the un-disclosed use of "IR vision" for non-"legitimate" (e.g. security cameras) use or even criminalize all non-"legitimate" IR use in public places.

Come to think if it, I might be in favor of rules allowing for civil-court action for failing to disclosure of "see through clothing-capable" photography done in places accessible to the public.

They were recalled for saying "no antibiotics" on the package but having measurable amounts of them in the product.

In my dream world, this should have been a joint effort by the FDA and the Federal Trade Commission.

Or to put it another way, if someone feels the need to say "XYZ is settled science" that's a clue that it might not be.

We teach preschoolers some specific examples of abstract algebra:

Today is Friday. Friday is the 6th day of the week. What day will it be 3 days from now? *hold up a calendar*

It is 11 o'clock. What time will it be two hours from now? *hold up an analog clock and point to the hour hand*

You get the idea.

Perhaps its time for a centralized theft registry.

Yes, this will reduce the pseudo-anonymity but it can be done.

Here's one possible way for bitcoin-wallet services to handle things, but it's off-the-cuff so it's probably buggy:

Executive summary:

Through the use of multiple wallets and a central registry of "stolen bitcoins," a wallet service's customers can put money they don't need immediately in "vaults." Unauthorized "withdrawals" from the vault will be refused by the software and will never make it into the block-chain, thereby providing some protection to the funds and deterring wholesale theft from bitcoin-wallet services.

Details:

Give account-holders two "wallets" - a "pocket money wallet" and a "vault wallet" - and create a third wallet - a "holding wallet" - that is controlled only by the wallet service.

Wallet #1 is the "pocket money" wallet. It has no additional protections. It's used for "petty cash" and for money that will be needed in the next day or two.

Wallet #2 is the customer's "vault wallet." For certain customers with few incoming transactions, this "vault wallet" will be stored "offline" and only moved online temporarily when the customer tells the wallet service there will be an incoming transaction soon.

Wallet #3 is the "holding wallet" for Wallet #2. There may be more than one such "holding wallet."

The "vault wallets" are registered in bulk by the bitcoin-wallet services with a central authority. Only certain transactions are allowed "out" of these vault wallets. All other transactions will be refused by the software - they will never make it into the block-chain.

If an exchange is compromised, all of its "vault wallets" are considered compromised until the exchange indicates they are not. Transactions indicating withdrawals from these "vault wallets" during the time of the compromised are refused by the software - they will never make it into the block-chain.

The registration is nothing more than
* some identifier belonging to the wallet service, to ensure that the registration information isn't tampered with later
* the identifier of the "vault wallet"
* the identifier of one or more "holding wallets."
* for each "holding wallet," a minimum time between each transaction. This will usually be at least a day.
* each "holding wallet" will typically be automatically dumped into the customer's "pocket money wallet" when the time expires.
* at the wallet-service's option, additional obfuscation may happen after the money leaves the holding wallet and enters the customer's "pocket money wallet." For example, the money leaving the customer's "holding wallet" may be dumped into "bank's temporary wallet #1" and an equal amount transferred from "bank's temporary wallet #2" into the customer's "pocket money wallet" shortly thereafter.
* at the wallet-service's option, the "holding wallets" may be part of an obfuscation scheme. For example, they may be randomly re-used across customers, or they may be designed as one-time-use wallets.
* a time-delay for any registration information changes other than marking wallets as compromised.

The idea is that the "pocket money" wallet is just as vulnerable as ever, but it will rarely have most of a customer's coins in it.

The "holding wallet" has some vulnerabilities but it will be empty most of the time and thanks to the "time lock" it's unlikely that all or even most "holding wallets" at a given will be able to be stolen at the same time.

The "vault wallets" are protected enough to make the immediate reward of "raiding" an exchange much lower than it is today. There will still be theft, but the number of people interested in stealing from exchanges will go down and the risk of loss from a given theft will go down.

Trade-offs:

* This is not a complete solution.
* There are probably anonymity issues I haven't considered.
* There are new denial-of-service issues introduced by this system. I can see the possibility of a DOS attack against a particular "vault," against a particular "wallet service," or even against the "central registration authority" itself.

These issues will need to be looked at and either fixed or deemed "acceptable" before this or any similar system will be accepted by end users.

If you control for # of hours worked, that's fine and dandy as long as this factor is something NOT based on gender discrimination.

If men get offered longer-hours, and therefore more-annual-pay, jobs or assignments, because they are men or because of some underlying factor where men have an advantage because they are men, then you SHOULD NOT be factoring this out.

If everyone gets offered such assignments without any gender discrimination and men choose to work longer hours, or if the reasons for any differences between what men are offered and what women are offered are all based on things that happened earlier in life that were based on free choices rather than gender discrimination, then you SHOULD factor these out.

Example:

If promotions are offered to those who have current skills for the new job, and those current skills are usually developed by taking extra training classes on the employee's own time, this may seem like a gender-neutral reason for selecting who gets promoted, even if its effect is to have many more of one gender promoted than another. In some environments, it may actually BE a gender-neutral way of selecting who gets promoted.

However, if the company's employee pool has a large number of women who simply do not have the time to take such classes (say, due to being single parents - single moms significantly outnumber single dads in the USA) and the employer either knows this or would have to be willfully blind to not know it, then using "who has current skills for the new job" for internal promotions without finding some way of ensuring everyone has a REAL opportunity to get skills training is, at best, indirect gender discrimination. If it's a deliberate "bwuhahahaha let's see if we can fool everyone into thinking we can play fair while ensuring most promotions go to men bwuhahahaha" deliberate technique, then the company better hope there is no smoking gun or they will lose any related employment lawsuit and probably alienate their customers as well.