Sure, but why does this have to be accomplished via coercion under color of law? It seems your argument is predicated under the assumption that entities won't cooperate without government coercion.

For example, RAM standards are set by JEDEC, which is an open industry coalition. I wouldn't call the industry's experience with DDR SDRAM over multiple generations an example of failure & fragmentation due to lack of governmental control. The x86 ISA (such as it is) has also been a success over multiple evolutionary generations (albeit litigated at some points) despite lack of legal mandate.

So, while your electrical grid example is a potential threat if standards weren't mandated, it isn't very likely... imagine the PR fallout Oregon would get in your case: "Come to Oregon, none of your electronic devices will work!". There is a natural incentive for compatibility in those cited examples of railroad gauge, electrical gauge, and roads.

Besides, lack of coercive standards offers the potential for smaller-scale "experiments" that can be paradigm shifting. There is no law that says that DDR SDRAM has to be used on every motherboard, and that allowed the (admittedly vile patent troll) Rambus to attempt to promulgate a different standard that the market could evaluate as a competing standard. Rambus was an idea that was tried and largely discarded, but by the same token should ARM be banned by law because its ISA isn't x86-derived? I believe the market is better for allowing the possibility of experimentation (and possible failure!)

Furthermore, mandated standards can easily be overreaching. Imagine, if you will, that all roads had been fully standardized long ago: lane widths, lane counts based on traffic formulas, etc. You can easily imagine that such a regulatory regime might have squelched the ability of California to develop HOV lanes in the 1970's.

It's not the end of the world if there are widespread competing standards that eventually coalesce. When the US South finally decided to convert to standard gauge railroad from broad gauge, they coordinated its rollout quite well (they pulled off the conversion in 36 hours in an impressive feat of coordinated engineering).

Google/Samsung/et al. don't have a separate timeout for slide lock & security lock feature. This was originally an HTC Sense feature but now is also available in CyanogenMod.

Why CyanogenMod? Well, that's because after I wrote the code to replicate & improve upon the Sense feature, I only submitted a patch to CyanogenMod. (Hey, it's what I use...)

The feature is in CyanogenMod 7.1 or later, and any other ROMs that pull from CM 7.1 as an upstream. As stated before, a similar feature is also found in HTC Sense-derived ROMs. However, HTC's implementation isn't as versatile as mine, so I suggest you disregard that and just use CM instead (haha).

Pull the source if you want; port it anywhere you like:
Framework code
UI code

What?! No, there is no need for a bandwidth cap on a transmission system. They are clearly selling signals that are infinite in the time domain!

PS. Technically, any signal that is time limited has infinite bandwidth, though in all real world applications the Fourier transform is just an approximation. May the math be with you!

True, but beware sweeping generalizations. There was a complicated MVC that resulted in an overturned SUV in my metro area. Bystanders called 911 before attempting assist (as per proper protocol), but the ambient gasoline caught fire while the 911 call was live. The background of the tape includes the trapped passengers screaming as they burned to death with the 911 dispatcher asking if the bystander could do anything to help, to which he replied, "No, ma'am, not anymore." No survivors.

This is a scenario that demonstrates that it is difficult to have appropriate, hard-and-fast rules that the general populace can internalize. Obviously in your case it was best that you were left untouched. However, in this other case it is possible that some of the occupants could have survived if a bystander had risked extricating them in the first few minutes.

Disregarding the hoverboard feasibility issue for a moment, I wanted to point out that it is possible to force the magnetic flux of an array to be almost entirely on one side of the array: Halbach Array. Use the array's flux to induce an opposing field in loops of wire via induction.

Fun fact: Halbach Arrays are the reason many of those flat sheet refrigerator magnets only "stick" with one side and fall off if applied facing reverse.

So, now we have replaced the issue of prying the hoverboard free if it is flipped deck-side down by making it twice as difficult to free the hoverboard if it sticks to a light pole deck-side up. Progress! (haha)

I'm convinced that's exactly what they are trying to accomplish: they want to be the MAFIAA of written works, and seem determined to keep trying until they can bootstrap themselves into that position.

It's like watching The Omen , only real.

I would expect to spend less time waiting for statically compiled apps to load from disk, aggregated over my lifetime, than I have already had to spend in dependency hell trying to get two different binaries to play nicely. Not to mention less stress.

You make a good point, but I was exaggerating size requirements for effect: my statically compiled version of the svn binary was < 3 MB. I can think of no good reason why binaries like that shouldn't just be statically compiled. Besides, as the other poster pointed out, most MacOS X apps are statically compiled. I haven't seriously wished for faster app launch speeds when dealing with Macs compared to Windows, especially if I knew the tradeoff for ditching static compilation would be loss of "drag and drop" executability.

Granted, this isn't a panacea. I realize that all these different apps would need to be updated independently, but I consider this ramification to be conceptually consonant with my viewpoint (ideally using binary diff patches, of course).

As you pointed out, Mac OS does this "right" insofar as most apps are portable to another machine if you just copy the .app "file".

Haha, Linux is exactly the reason I started seriously wishing for statically compiled binaries. When I compare, for example, getting a recent version of SVN onto a RHEL 4.x machine versus MacOS "drag to install"... well, the difference is stark. "No, I can't update lib-apr to your minimum version because that will break my PostgreSQL instance! Just give me a simple, standalone binary!" I eventually got a statically-compiled version of SVN for RHEL 4.x, scp'd it over, and it worked fine: statically compiled binaries for great "drag and drop" justice.

I'm not a zealot, so I believe people should have choice. I would love to be able to pick and choose whether I get a statically-compiled binary or the regular, linked-lib binary when installing from yum or apt-get. Of course, this would put a huge burden on repo maintainers, and I admit such an approach is likely unworkable.

Exactly. However, I would take it a step further and suggest that the overall idea to push this much application level functionality into OS libraries should be Considered Harmful.

"Don't write your own red eye correction code, it's built into the OS! Oh, wait, now I see that your new version only works correctly with version 1.5 of the library that's not in my current OS release. Guess I have to upgrade the *whole OS* to install your new software."

Yes, this happens in all OS's (cf. DirectX). However, increasing the surface of these kinds of dependencies to this degree seems like a bad plan.

I'm all for code reuse, but I would prefer it if most apps were statically compiled and included all their dependencies. I am also fine with having a few, very stable external dependencies; the .NET Framework is a good example because it is very basic and allows apps to explicitly target different framework levels (and the OS allows having multiple versions installed).

The alternative is DLL Hell (and/or weird gymnastics to try to avoid it) and all too often these dependency patches that get pushed out ("fixed once in dependency library, now fixed everywhere!") don't pan out as intended and break one app or another.

Statically compiled binaries would be "huge" but again, disk space is "free" in these amounts. As a user, do I really care if a particular app weighs in at 3 MB or 150 MB anymore? Naturally, a binary diff patch system like Chrome's would go a long way to mitigating the bandwidth required to keep these up to date.

Oh well. While I'm wishing, I want a moon rocket too.

I guess my realization was that this battle was over before it started due to the English translation of petitio principii being historically decided as "begging the question".

The typical connotation for transitive "beg" for common people is "to entreat/appeal/supplicate" or "require as necessary" the direct object of "beg". Consider a thought experiment: I'm sure you would agree that had this particular logical fallacy not appropriated the phrase then "begging the question" would logically parse as "prompts the question to be raised".

Therefore, I consider this scenario to be orthogonal to your valid example about the abuse of "awesome" supplanting the original denotation; I believe "begging the question" to have an inherent, valid and obvious parsing in the new, "abusive form" that has cropped up. This makes campaigning against the emergence of the new form almost untenable.

So, at best, I believe "begging the question" (fallacy) to be irrevocably cacked as a term due to the emergent ambiguity. This is much like how "megabyte" is now inherently ambiguous thanks to those IEC imperialists attempting to supplant the original definition. People can fight the good fight against the new definition, but the attempt at the promulgation of the new usurping definition has, ipso facto, ambiguated the term. /muttering about those IEC bastards and their scorched earth tactics...

PS. How's "ambiguate" as a neologism? Haha

You know, I used to be right there with you and corrected other people's misuse of the term. However, as time progressed I came around. It is much more intuitive (and frequently encountered) to use the improper form of this term. I still say, "begs me to ask" or "begs for the question" but they are unwieldy forms.

Besides, prima facie, the historical denotation of "begging the question" doesn't befit what is actually happening from a common person's perspective. "Question", in this context, is ambiguous for most people who aren't presuming the definition context of debate points. Furthermore, for those who truly beg the question to support an argument, asking questions/speaking tentatively is the furthest thing in their mind (ie. they are often full of zealous conviction).

Thus, I have begun to disambiguate and no longer use "begging the question" and say rather, "You are presuming the point under debate to support your argument", which is unambiguous and parses for everyone.

So, yes, you are correct. However, I think the effort to fight this is misplaced and righteous fury should be reserved for definitions that really matter. You know, like prefixes for data size being in powers of 2 rather than this subversive attempt to change the definition to refer to powers of 10. "MiB?! Over my dead body, you scum..."

The US Marshals collect DNA from all the people they arrest, per 42 USC 14135a.

Excerpt:

(a) Collection of DNA samples
(1) From individuals in custody
(A) The Attorney General may, as prescribed by the Attorney General in regulation, collect DNA samples from individuals who are arrested, facing charges, or convicted or from non-United States persons who are detained under the authority of the United States. The Attorney General may delegate this function within the Department of Justice as provided in section 510 of title 28 and may also authorize and direct any other agency of the United States that arrests or detains individuals or supervises individuals facing charges to carry out any function and exercise any power of the Attorney General under this section.

Automatic expurgation of DNA data upon acquittal? Ha.

Congress didn't "steal" the money: there was no possible way for them to save it (no 'lockbox' can ever exist for something like this), as I mentioned in my other comment. SS has always been a book-juggling, pyramid scam.

Also, you have to realize that the Boomers and their parents not only signed themselves up for SS, but all future generations as well. Imagine how hollow it rings for people of my generation to read comments like, "I paid in all my life, so you have to, too!" from my parents' generation knowing that we will pay and never benefit, not to mention having no say whether or not this program should have ever existed in the first place.

The Boomers and their parents voted to setup this program, not us. Perhaps I share some blame for not voting harder against SS when I was a child (*cough*).

At this point, I am in favor of erasing the entire SS program, wiping out the Treasuries it holds (and their annual interest payments) with the stroke of a pen, and replacing the program with a means-tested replacement, "Old, Poor People's Welfare (Fuck You, 'Greatest Generation' For Screwing Us Over)" program... OPPWFYGGFSUO rolls off the tongue, right?

I am a libertarian, but I recognize that previous generations naively trusted, for their whole lives, that somehow the government could magically overcome the mathematically certain failure of SS, and I would prefer to ease the pain. The alternative is a shock if my (or a future) generation decides to abrogate the entire program because clear-eyed analysis shows that it holds no benefit for us.

Why should we presume to hold our childrens' future forfeit merely to propagate our ancestors' mistakes?

If the SSA were to "keep the cash on hand" it would presently cause extreme deflationary pressure on US currency (tax receipts being sequestered would result in less circulating money) followed by inflation once benefit expenditures exceed tax receipts (ie. when the Boomers retire).

That's the issue with the whole SS pyramid scam: there is no effective way for the government to save the money paid in. Once you look past the notional bookkeeping, it is clear that SS benefits are always made from current tax revenue. At present—while there is an SS revenue surplus—SS payroll taxes merely end up in the general fund. Once there are more benefits paid out than SS tax revenue received, then SS will effectively be paid out of the general federal budget.

Let's follow the notional flow of the money at present:
1) Payroll taxes received by the SSA
2) SSA pays benefits to recipients and is left with a tax revenue surplus
3) SSA buys US Treasuries with the surplus (because there is no possible concept of something like a bank savings account to hold this much cash) and refers to this as the Trust Fund
4) Trust Fund Treasuries pay interest to SSA (annual interest paid by federal general budget from current general tax revenue), thus increasing the Trust Fund, which is plowed back into buying more Treasuries

Let's follow the notional flow of the money in the future:
1) Payroll taxes received by the SSA
2) SSA pays benefits to recipients but has more expenditures than revenue (a deficit)
3) SSA pays out benefits to recipients from current interest on Treasuries in the Trust Fund, the small SSA cash reserve, or redeemed Treasuries from the Trust Fund (redemption paid by federal gov from current-year general tax revenue)

Why does the federal government sell Treasuries in the first place? To fund current general expenditures. Thus, it is clear that despite some indirection, surplus tax revenue from FICA payroll taxes goes to the general budget and that once there are more SS benefits paid out than SS tax received then those benefits will be paid with current general tax revenue too. The money necessary to retire debt (eg. when the SSA redeems the Treasuries in the Trust Fund instead of just rolling them over) must always come from current tax revenue.

Then again, perhaps the Chinese will keep floating US deficit spending by buying more US debt indefinitely, which would allow the federal gov to roll over the redemption of SS Trust Fund Treasuries by selling new Treasuries to the Chinese in a 1:1 ratio. I'm sure the Chinese want nothing more than to enable US deficit spending indefinitely (*cough*).

There is no good solution to this issue. It must be recognized that the Boomers and their parents signed themselves & all future generations up for a pyramid scheme that future generations will have to pay out. Unfortunately, the Boomers failed to breed in sufficient numbers to delay the inevitable collapse of the scheme past their generation's death.

The real question is whether we want to saddle future generations with the crushing load caused by this scheme.

Your approach makes sense, but have you ever wondered why there is no means testing and a limited wage basis? Hint: it's not a plutocratic plot.

Ever since SS was instituted it has been defined as tantamount to a pension. This is why there is no means testing for benefits and a limited wage basis: it is a pension that workers pay into that has a maximum benefit payout based on how much the worker paid in over their life. If you take the present value of an annuity that pays out based on what the worker has paid in (with a max benefit cap), then it is a simple actuarial calculation to determine what the maximum pay-in should be, and this is how the inflation-indexed ~105k wage basis is derived. If a worker pays in more, they get paid more out—directly correlated to the amount they paid. I am hard-pressed to believe this is unfair.

Now, if SS is going to be redefined as pure wealth redistribution program funded by payroll taxes, then having means testing and an unlimited wage basis will be self-consistent. Of course, this will nullify the ability for people to claim, "I paid in, so I deserve to receive a payout" because means testing and eliminating wage basis decouples the received benefit from the individual's contribution. In this case, SS would essentially become yet another welfare program like Medicare (where payout is unrelated to pay-in). Changing the conceptual basis of the program cuts both ways.

It would be great if SS automatically indexed an increasing retirement age to increasing life expectancy, much like the wage basis is indexed to inflation. Given the SSA-reported life expectancies for 1940 vs. 1990, the retirement age should already be up to 68+.

I firmly believe that SS benefits will be paid with Monopoly-grade money by the time I retire (eg. by deliberately understating CPI for years) and the entire system will become a joke. I think most people in my generation are seriously looking into alternative plans to ensure our basic costs of living are covered rather than relying on SS.