Eh, I still would find it concerning if I were a grunt in the area of a recent armor battle (or, say, an A-10 Gatling CAS strike). It also seems that chelation therapy isn't as effective for uranium as it is for other heavy metals. I also imagine there is less treatment data about acute uranium toxicity than there is for, say, lead. Again, I admit that my expertise in heavy metal toxicity is vanishingly small.
Please understand I am not a breathless radiation paranoiac. In fact, I disclaim my positions as opinion when appropriate and I didn't edit that WHO quote that indicated only a 1% marginal risk from spent-fuel sourced DU.
I am an advocate of nuclear technology. I live within 15 miles of a nuclear power plant and feel perfectly safe (with the exception of reports of how inept the machinegun-armed guards are). I would feel safe even if the plant were immediately adjacent to my home. This is just very different in my mind than exposure (pulmonary especially) to aerosolized, potentially spent-fuel sourced DU dust. More so than lead.
Would I be concerned about a machined sailboat keel made of DU? Not at all. Would I be concerned about an area that has been covered by aerosolized DU dust that has highly radioactive impurities? Certainly. This is what happens in the wake of a DU kinetic energy penetrator strike on armor.
PS. if a radioactive impurity stops being significant "after a few years" then by definition it is quite radioactive. Radioactivity is nifty that way... the more radioactive the isotope, the shorter the half-life. I would have hoped for better understanding about radioactivity from Slashdotters who advocate how "benign" DU is.
Not that there's any special danger associated with depleted uranium in the envronment
You are correct that pure DU would essentially be no more hazardous than other types of heavy metal pollution. However, the situation is more complex in reality.
Spent uranium fuel from nuclear reactors is sometimes reprocessed in plants for natural uranium enrichment. Some reactor-created radioisotopes can consequently contaminate the reprocessing equipment and the DU. Under these conditions another uranium isotope, 236U, may be present in the DU together with very small amounts of the transuranic elements plutonium, americium and neptunium and the fission product technetium-99. However, the additional radiation dose following intake of DU into the human body from these isotopes would be less than 1%.
Somehow, I don't find that very reassuring ("Yay! Heavy metal toxicity with a side of biosequestered alpha & beta emitters!"). It seems much more likely that spent-fuel DU production would have less quality control care than the original enrichment process, but I could very well be mistaken.
I have heard it alleged that only the US uses spent reactor fuel to create DU for weapons and that other countries that produce DU weapons use only the byproduct from the enrichment stage. However, since I have no cite at the moment, I wouldn't assign that much credulity. Regardless, it does seem that in practice DU is not always pure as the driven snow.
Amen. I actually opted-out after the TSA was implemented. I flew without concern in October 2001 (ie. while the National Guard was still deployed at ORD with assault rifles), but I immediately ceased when I read that the TSA was deployed.
However, I am very disturbed that the right of free travel within the country is becoming very circumscribed. Most people in the US consider driving a privilege extended to them by the State rather than a fundamental right. Walking isn't really a viable option for travel, and it isn't much of a stretch to imagine federal travel restrictions similar to air travel for those people who choose to take a bus.
Even though I am a natural-born US citizen, I can envision the day where I will find myself forced, on principle, to "opt-out" of the US entirely and expatriate.
Yes, given the history of Supreme Court decisions, I fully anticipate the possibility that the Federal government will circumscribe the individual's right to walk across state lines as part of their 75 year history of progressive interpretation of the interstate commerce clause of the Constitution.
If you think about it, that would be no more of a distortion of the original meaning/intent of the Constitution than Wickard v. Filburn or Gonzalez v. Raich.
Actually, the Feds love to dream big. Since both of those cited decisions involved (non)actions of people who never crossed state lines, why not just circumscribe everyone's right to walk down the street without an internal passport bearing a visa for your destination?
I wouldn't know. I'm not huge fan of CS translations and localizations, at least of those that go beyond proper localized output of data (numbers, dates).
Ah, so your versions of Java, Perl, Ruby, C, et al, use commas as parameter delimiters for your method invocations? If so, what happens when you are passing floats... must you switch to US-style decimal points (ie. dots)?
If the correct interpretation of your comment implies that you don't code in any of these languages, then I apologize for being dense.
That's really interesting; thank you for the insight. I am used to programming languages that use commas to separate method parameters. Somewhat tangential, but are there dialects/programming languages in your locale that use semicolons to separate parameters in method invocations?
As for OOo, it breaks our locale because it mimics Excel's function invocations (names, start with "=FUNCTION_NAME", enclosing parens, etc) in all ways except that it uses semicolons to separate params rather than the ubiquitous comma.
Allow me to disclose my bias: I hate MS products, especially Office after it went all Ribbon-y. I also have a moral objection to product activation. So, all I use on my primary computer is OOo 3.2.1, and the machine has been OOo-only since the day I bought it two years ago. I appreciate all the effort that the developers have put into it and that it is free.
That said, OOo is a pain to use. Document assembly just hurts. How often do you make tables in your word processing documents? MS Word is great about manipulating columns, rows, etc. Text wrapping is great. OOo... oh my god. It's nearly impossible to get the table the way you want it to be. Bullets and numbering in Writer is nowhere as flexible as in Word, and I have often switched back to manual numbering in exasperation. Autocorrect in OOo blows, it usually annoys more than it helps, so I have turned it off. Never had a problem with MS Office.
Doing scientific work? Want to embed sections of a spreadsheet in your Writer doc? Great, just don't expect the cells to look nicely. Border formatting in Calc sucks. Oh, and heaven forbid you find an error in your embedded spreadsheet cells; editing those in place is so problematic/laggy that it is just easier to delete the whole table and copy/paste from the (fixed) source spreadsheet. Text wrapping around these elements is abysmal... there's no option similar to Word's "in line with text", and so the thing stays as a floating table (no other option). OOo does offer some wrapping options that I don't think have parallels in MS Word: "background" and "through". These are excellent examples of a page wrap that I doubt anyone really wanted, because they allow text to wrap right through the table, becoming superimposed over or superimposing upon the table. Wow! Did I mention that the borders on the embedded tables will disappear on random sides when it comes time to print/export as PDF? WYSINWYG.
Charts in Calc suck. There is no analogue to Excel's "chart as a sheet" option. That means if you change your page layout, etc, you have to go manually try to resize the floating chart to the new desired size with your mouse. It is difficult to get it exactly to the print size limits, because the chart is a floating object that does not snap to cell borders and lags/jumps when you try to drag it for fine positioning. It is very easy to get it a few pixels off and then have your chart print out as multiple pages, yay! It should go without saying that printing charts is a pain unless you send them to another sheet (trying to print just the chart without the data that is otherwise on the sheet).
Which brings me to another point: there is no polynomial regression curve fitting for scatter plot charts in Calc, unlike Excel. This missing feature has driven me back to Excel for my reports more than once.
There are lots of little annoyances with Calc, like there being no quick way to perform a sum on all relevant rows in a column. In Excel, this would be "=SUM(B:B)". In Calc, you are forced to enter "=SUM(B1;B65536)". Annoying. Also, the use of semicolons to separate function arguments is an annoying difference from Excel. Why not just use the same format? Was it patented? Most of the rest of the UI tries to be Excel-like... so why this difference?
I could go on, but you get the picture. I believe the users who complain about OOo. Some just dislike having to learn anything new, but OOo does have serious limitations/annoyances for those who have scaled the learning curve. BTW, yes I did search for solutions to most of these issues/annoyances in OOo... they don't exist.
tl;dr: I use OOo because I hate MS, but it is very difficult to do so—sometimes it is impossible to get a final product polished the way you wanted. Using something this painful probably builds character.
I see the GP is well on his way to earning the elusive (Score:5, Troll) achievement which is one of the rarest drops on Slashdot (BTW, when did Slashdot turn into XBox Live with achievements? Now, get off my lawn...)
Just an FYI, your ad hominem attack does not detract from his legitimate point. I am well aware of the technical issues involved, but at some point you have to stop giving Linux & X Windows a pass just because Unix/X was crappily designed in this regard back in the 70's (tty's and client/server GUI apps). If stuttering media playback is a side effect of the present modular paradigm, then perhaps it is time to stop making excuses for it.
This is almost as bad as when people stepped up to defend the ext4 data loss / commit interval issue to say it was "by design". Yeah, it is trivial to avoid by calling fsync in your app all the time, but watch that destroy perf because it flushes the whole I/O queue for the system. Ordered data mode just makes sense... strange that wouldn't be default, or even an option to turn off if you think about it. So, what's a cautious app designer to do? Fsync all the time? Can a userspace app even query this flag? And no, using SQLite is not a legitimate workaround.
Same damn thing when Linux zealots call ZFS a "rampant layering violation" and then define away innovative capabilities like RAIDZ and cheap, versatile COW snapshots as "nonfeatures" because they can't be replicated while abiding within the Linux layering paradigm. Sour grapes, indeed. Btfs won't be able to replicate these features unless they break the layering paradigm, so who wants those features anyway?
Soooooo... watch me get flayed alive for my heresy: I say if the extant paradigm isn't optimal, then maybe it's time to consider changing it. At the very least, it's intellectually dishonest to claim that these aren't problems just because there are no simple fixes in the present model. As noted by others, this "fix" is essentially a heuristic with improved granularity for the given problem. Good, at least that's something. Now, how about the real, underlying problem?
You can also use numeric character references, but that's not very portable. What works for Windows is wrong on a Mac, for instance.
I thought Unicode (especially UTF-8) was intended to resolve this issue. With UTF-8 becoming nearly ubiquitous, EOL issues are a much bigger problem than character encoding.
Don't get me wrong: I wish ISO-8859 and CP1252 would be incinerated by a bolt of lightning from Zeus for all the issues they have caused me over the years. The divine hammer can't be dropped soon enough: even Slashdot is stuck in the early 1990's by continuing to insist on using ISO-8859-1 for the US-based site (the.jp site, at least, uses UTF-8).
HTML escaped characters are a horrible hack in every case aside from the syntax interference related ones (greater than, less than, etc).
This evolution is essential. For instance, I should be able to inject some ancient Sumerian Cuneiform characters into this message, dammit! Unicode supports me on this!
This isn't just an idle desire for feature-creep. Sometimes I channel Ur-geeks who had to post their trolls via clay tablet in the marketplace, and dammit, they want a piece of this action. Writing something like "Your ancestors were so foolishly illiterate that they mistakenly grew flax instead of barley" just doesn't have the same punch in English as in Sumerian Cuneiform.
One thing that has always irritated me about tmpfs is that it will page out into swap if memory pressure dictates.
Using ramfs as an alternative to tmpfs means that you lose the ability to stipulate a maximum size, and it can grow to exhaust all available memory in the system. Because ramfs won't page out, I presume it is quite possible to take down the entire machine in such circumstances.
It's sad that MacOS (pre-X) had the problem solved 15 years ago by allowing the creation of a fixed size RAM disk that would not page out, but this capability has apparently been lost in modern OS's. Unrelated aside: it was quite fun to load a stripped down version of the MacOS System Folder into a RAM disk and watch how fast the machine would boot (MacOS RAM disks would persist between reboots but would naturally be obliterated if power was cut).
My (admittedly wishful) intent would be to promulgate a counter-meme, "Brooks' Law considered harmful".
When one considers the assumptions made by Brooks, it is apparent that his law is merely a case of Amdahl's Law with certain initial conditions and modeling parameters. I am actually surprised he didn't make a more generalized restatement of Amdahl's Law, because he is clearly referring to a maximum amount of speedup. Why stop with only "late" projects and not make a broader rule for dev projects in general?
If I may posit for your consideration, I suggest that your examples missed the broader point. Everything you pointed out is reasonable, but my suggested replacement for Brooks' Law is to use Amdahl's Law to calculate a hard upper bound on the maximum amount of speedup that could be obtained adding additional devs. The result would be something along the lines of "even if we hired 128 new devs who all instantly acted as as perfect development cogs and assume our project development is embarrassingly parallel, we would still miss the release date by at least 7 months". I contend that such a model would be significantly more useful than Brooks' Law.
If your maximum speedup from adding additional capacity is insufficient by an order of magnitude or more, then it's obviously time to consider alternatives. Contrariwise, if the numbers show a clear possibility of payoff then it might make sense to add capacity; however, this is much more ambiguous than what can be ruled *out* by Amdahl's Law.
Your examples point out how such a model could be abused, much as I allege that Brooks' Law is currently abused. If people turn the model around and start using it to project hard release dates based on dev team size, initial dev complexity estimates, and so forth, then such a model could easily become more harmful than helpful.
I believe we are in general agreement because the feasibility of any such calculation is predicated upon a well-managed, well-instrumented dev team. Ideally, there would be a reasonable amount of historical metrics about dev velocity statistical bands, "initial estimate vs. actual time required" fidelity, team overall velocity vs team size, typical ramp-up time, etc. Perhaps I have been spoiled by working on such teams in the past. Regardless, if you don't have a realistic basis for the numbers you are using, then all of this becomes yet another para-masturbatory exercise similar to the Drake Equation.
PS. In the link I posted above, it is shown that Gustafson merely restated Amdahl's Law via a different formulation—there is only one law.
I am quite familiar with the context. This meme is constantly misquoted and misunderstood; it is probably better off dead. Take, for instance, your claim:
"You cannot add developers to a late project and make it release sooner"
It is false. Let's say you have a multi-year project and you hit a snag in the first 2 months, a snag which implies that complexity is somewhat increased compared to your initial estimates and would take an additional six months to complete if nothing changes—the project is now officially late. However, you can still release on schedule if you add another 10% capacity to your dev team. This is a very plausible scenario, and only one such scenario must exist for your absolute statement to be disproven.
So, you have to start adding further precise stipulations in order to make the original Brooks' Law even remotely plausible. For instance, the project has to be late but only insofar as it does not represent a fundamental shift in the amount of work to be done (in my example, more work has been "added" to the project). Furthermore, it is presumed that additional developer capacity will never reach breakeven for sunk training costs/bugs/etc before the project would be delivered anyway, which further restricts the number of applicable scenarios.
The communication network scaling factor is a straw man in itself because that is not how developers interact in a non-dysfunctional dev team. It's just retarded, even at a basic level: "Hello, Anne? You work on the kernel-level Windows USB hardware driver team, right? Hi, I am Gavin from the Windows Explorer dev team, and I am working on rendering icon panes for displaying directory contents, so I thought I would call you up—you know, because we have a fully interconnected dev team communication network and I thought I should inquire about your insights on my task." *cough*
The world would be a better place if we killed Brooks' Law and replaced it with understanding of Amdahl's/Gustafson's Law in conjunction with a rational consideration of new dev ramp-up time. Even as an "outrageous oversimplification" Brooks' Law is misleading and very likely harms more than it helps. How many projects were made even later when an appeal to Brooks' Law was used to cut off debate about adding capacity?
You cannot add developers to a project and make it release sooner, no more than 9 women can make a baby in one month.
So Windows Vista could have been released in 2002 if Microsoft had only fired all but one member of the Windows development team back in 2001, before the Vista project started? Shit, hold on while I let all of my clients know that they don't need my services anymore—the answer is to fire all but one member of the team!
...or maybe it doesn't actually work the way you say, because the corollary to your claim is that release will happen soonest if no one is ever added to the project (one member is requisite for the project to exist at all). Back to the example: over the years Microsoft grew the Windows team up from 0 members, and I doubt they were doing it to reduce their development capacity.
Honestly, scaling is manageable if the project is broken down into bite sized chunks and the team is comprised of subteams (personal size preference: 4-5 members). Yes, there is added overhead, but hierarchy and management can mitigate such issues; Agile development practices make the overhead as painless as possible. It is naive to think that you need a fully-connected network for an entire (massive) project in order for the team to be able to function.
In summary, "Yes, you can add developers to a project and make it release sooner, so please stop spreading this meme which was only ever applicable if certain naive stipulations were presumed."
PS. There is a finite amount of release speedup available by adding additional devs (Amdahl's Law), but overall release complexity capacity per time unit increases (Gustafson's Law). This is a classical problem in parallel processing. Some dev projects are more serial in nature, others are embarrassingly parallel.
If we are speaking strictly (as US citizens), then please note that the US government asserts tax on your worldwide income. There is an exclusion on the first $~90k of annual income, but we are speaking *strictly*.
The only way to strictly avoid US taxation is to renounce your US citizenship, but there are clawback provisions to discourage that. However, once you have unwound your US investments/positions, renounced your citizenship (note: be certain not to become a stateless person), and filed your final tax returns, then you will strictly be free of US taxation.
You really cannot choose not to "do business" with the US government unless you are willing to uproot your entire life, likely leave behind your family, sell everything you own, live in a foreign land, and have circumscribed rights to return for visits. Show me a business that has anywhere near this level of coercive control or lock in.
Right, which implies that there is nothing special about 2.4 GHz with respect to water. From your source:
The frequency for maximum dielectric loss lies higher than the 2.45 GHz (wavenumber 0.0817 cm-1, wavelength 12.24 cm) produced by most microwave ovens.
I read an excellent journal paper about this just a few months ago, but I mislaid the link. Anyway, if memory serves, the frequency for maximum dielectric loss in liquid water was 11+ GHz. So, while 2.4 GHz may be a "sweet spot" for a microwave oven's efficiency at heating variegated foodstuffs, there is nothing special about it wrt to water (solid or liquid).
While I will concede that the legal system sometimes comes up with bizarre counter-intuitive redefinitions of common terms, the standard definition of annex in this context would mean "appendix". So, when you say that the common understanding of the singular term means the 1949 GC, well, you probably need to be even more precise because it would seem that an appendix to the 1949 GC would be considered part of the same. So, now it's "the 1949 Geneva Convention, as stated in 1949, not including any subsequent additions"?
I understand what you were trying to state in your original post; however, I would counter that when a topic becomes ambiguous, eg. "the singular term generally refers" and then requires even further armchair lawyering to establish definitions, then dropping a pedantic debunking hammer on others becomes disingenuous at best.
For future reference, whenever somebody tells you that "the Geneva Convention says you can/can't do X", that should immediately set off your bullshit detector. [...] The Geneva Conventions cover the treatment, in wartime, of prisoners, wounded, civilians and medics. That is literally all there is to them.
"The full title is Convention on Prohibitions or Restrictions on the Use of Certain Conventional Weapons Which May Be Deemed to Be Excessively Injurious or to Have Indiscriminate Effects and it is an annexe to the Geneva Conventions of August 12, 1949."
Protocol I restricts weapons with non-detectable fragments
Protocol II restricts landmines, booby traps
Protocol III restricts incendiary weapons
Protocol IV restricts blinding laser weapons
Protocol V sets out obligations and best practice for the clearance of explosive remnants of war
It's somewhat regrettable to debunk your "debunking". You had quite a bit of momentum and righteous indignation in your rant; it sounds like you have had some practice spreading this particular bit of misinformation. My guess would be that you took the common misattribution of the dumdum bullets ban to the Geneva Convention and turned it into this sweeping generalization.
Reminds me of when I used to tell people that microwave ovens operated at a resonant frequency of water, repeating what my engineering prof told us in class. Ouch... there were quite a few people I had to go around and issue a retraction to. (FYI: 2.4 GHz has absolutely nothing special wrt water--resonance, dielectric, or otherwise)
Considering how many entry forms still don't allow '+' in an e-mail address (or, worse, allow it in the sign-up box but not in the unsubscribe box)
Ah... I am fond of GMail aliases. Naturally, many times I have encountered the unsubscribe issue you describe; however, I have often emerged victorious (victory!)
You will often find that the unsubscribe links (or a GET-based form submission) will result in a URL. Workaday morons often forget to consistently URL-encode their input. They build an URL encoded query string, but they take your email address as a string literal. Bizarre.
So, your "foo+bar@gmail.com" will often be misinterpreted as "foo bar@gmail.com", thus confusing their system (space character encodes as +). Fortunately, you can take the high path with these drooling simps by simply adding the missing URL encoding feature for them: '+' encodes as %2B.
Change the salient part of the URL to be "foo%2Bbar" and you should expect a warm feeling of superiority to wash over you. Oh, yeah, and it will finally kill that fucking spam those morons keep sending you.
HTH. Don't forget to send nastygrams to their customer service departments about their moronic devs.
Who would have thought that giving the Russians a monopoly would give them more leverage in setting the price we pay? Maybe we should have a Congressional committee study this phenomenon and produce a report explaining how such a price increase could possibly have happened. Unfathomable mysteries, indeed.
Re:Funny you should choose that example
on
Health Care Reform
·
· Score: 1
Haha, fair point. However, the substance of my comment stands: the Constitution enumerates all of the powers that are granted to the Federal government. Any authority that the Feds wish to claim must be linked to an enumerated power or the claim is illegitimate.
Alliant has the "web form + mail-in" option (eDeposit) and then a scanner-only (no mail) option (eDeposit Plus). Personal opinion: eDeposit Plus has *very* finicky analysis software. Check images of front & back must be JPEG, greyscale, 200+ DPI, < 1 MB per file, and *no* whitespace around the check image. I ended up spending more time scanning (and subsequently in GIMP) than it would have taken to mail in the check.
There are limits. Apparently eDeposit Plus has a daily limit of $1500, but this limit might eventually be extended to $5000 based on Alliant's experience with you. Regular eDeposit (mail-in) has a range of 5k to 20k.
I have no idea what USAA's limits are, because it is academic.
Re:Funny you should choose that example
on
Health Care Reform
·
· Score: 1
I don't see anything in the current Constitution that would make mandatory insurance illegal.
Your statement is posed incorrectly. The Constitution does not form a list of prohibited actions for the Federal government; rather, it forms a comprehensive list of everything the Federal government is allowed to do. The founders of the country were very concerned that the Federal government would become all encompassing and supersede state and local authority in day-to-day life.
I counter your comment with a question of my own: where in the Constitution do you see that the Federal government has the right to force individuals to obtain health insurance? Please notice that in my comments I have not yet weighed in on one side or the other of the health care debate. I am merely asking under which Constitutional theory the Federal government has been granted the right to mandate individual health coverage.
Amendment IX
The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people.
Amendment X
The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
It is very clear: if the Federal government cannot link their authority for the health insurance mandate to an explicitly Constitutionally-granted Federal power, it is illegal. As I said, this is the reason why they were forced to pass the 16th amendment in order to assess individual income tax--they did not have an explicitly Constitutionally-granted authority to assess individual income tax. Same with Prohibition.
The Constitution is designed to tie the hands of the Federal government--not the people.
Slashdot Mirror
Eh, I still would find it concerning if I were a grunt in the area of a recent armor battle (or, say, an A-10 Gatling CAS strike). It also seems that chelation therapy isn't as effective for uranium as it is for other heavy metals. I also imagine there is less treatment data about acute uranium toxicity than there is for, say, lead. Again, I admit that my expertise in heavy metal toxicity is vanishingly small.
Please understand I am not a breathless radiation paranoiac. In fact, I disclaim my positions as opinion when appropriate and I didn't edit that WHO quote that indicated only a 1% marginal risk from spent-fuel sourced DU.
I am an advocate of nuclear technology. I live within 15 miles of a nuclear power plant and feel perfectly safe (with the exception of reports of how inept the machinegun-armed guards are). I would feel safe even if the plant were immediately adjacent to my home. This is just very different in my mind than exposure (pulmonary especially) to aerosolized, potentially spent-fuel sourced DU dust. More so than lead.
Perhaps we can civilly agree to disagree.
Would I be concerned about a machined sailboat keel made of DU? Not at all. Would I be concerned about an area that has been covered by aerosolized DU dust that has highly radioactive impurities? Certainly. This is what happens in the wake of a DU kinetic energy penetrator strike on armor.
PS. if a radioactive impurity stops being significant "after a few years" then by definition it is quite radioactive. Radioactivity is nifty that way... the more radioactive the isotope, the shorter the half-life. I would have hoped for better understanding about radioactivity from Slashdotters who advocate how "benign" DU is.
Not that there's any special danger associated with depleted uranium in the envronment
You are correct that pure DU would essentially be no more hazardous than other types of heavy metal pollution. However, the situation is more complex in reality.
Quoth the WHO:
Somehow, I don't find that very reassuring ("Yay! Heavy metal toxicity with a side of biosequestered alpha & beta emitters!"). It seems much more likely that spent-fuel DU production would have less quality control care than the original enrichment process, but I could very well be mistaken.
I have heard it alleged that only the US uses spent reactor fuel to create DU for weapons and that other countries that produce DU weapons use only the byproduct from the enrichment stage. However, since I have no cite at the moment, I wouldn't assign that much credulity. Regardless, it does seem that in practice DU is not always pure as the driven snow.
Amen. I actually opted-out after the TSA was implemented. I flew without concern in October 2001 (ie. while the National Guard was still deployed at ORD with assault rifles), but I immediately ceased when I read that the TSA was deployed.
However, I am very disturbed that the right of free travel within the country is becoming very circumscribed. Most people in the US consider driving a privilege extended to them by the State rather than a fundamental right. Walking isn't really a viable option for travel, and it isn't much of a stretch to imagine federal travel restrictions similar to air travel for those people who choose to take a bus.
Even though I am a natural-born US citizen, I can envision the day where I will find myself forced, on principle, to "opt-out" of the US entirely and expatriate.
Yes, given the history of Supreme Court decisions, I fully anticipate the possibility that the Federal government will circumscribe the individual's right to walk across state lines as part of their 75 year history of progressive interpretation of the interstate commerce clause of the Constitution.
If you think about it, that would be no more of a distortion of the original meaning/intent of the Constitution than Wickard v. Filburn or Gonzalez v. Raich.
Actually, the Feds love to dream big. Since both of those cited decisions involved (non)actions of people who never crossed state lines, why not just circumscribe everyone's right to walk down the street without an internal passport bearing a visa for your destination?
I wouldn't know. I'm not huge fan of CS translations and localizations, at least of those that go beyond proper localized output of data (numbers, dates).
Ah, so your versions of Java, Perl, Ruby, C, et al, use commas as parameter delimiters for your method invocations? If so, what happens when you are passing floats... must you switch to US-style decimal points (ie. dots)?
If the correct interpretation of your comment implies that you don't code in any of these languages, then I apologize for being dense.
That's really interesting; thank you for the insight. I am used to programming languages that use commas to separate method parameters. Somewhat tangential, but are there dialects/programming languages in your locale that use semicolons to separate parameters in method invocations?
As for OOo, it breaks our locale because it mimics Excel's function invocations (names, start with "=FUNCTION_NAME", enclosing parens, etc) in all ways except that it uses semicolons to separate params rather than the ubiquitous comma.
Allow me to disclose my bias: I hate MS products, especially Office after it went all Ribbon-y. I also have a moral objection to product activation. So, all I use on my primary computer is OOo 3.2.1, and the machine has been OOo-only since the day I bought it two years ago. I appreciate all the effort that the developers have put into it and that it is free.
That said, OOo is a pain to use. Document assembly just hurts. How often do you make tables in your word processing documents? MS Word is great about manipulating columns, rows, etc. Text wrapping is great. OOo... oh my god. It's nearly impossible to get the table the way you want it to be. Bullets and numbering in Writer is nowhere as flexible as in Word, and I have often switched back to manual numbering in exasperation. Autocorrect in OOo blows, it usually annoys more than it helps, so I have turned it off. Never had a problem with MS Office.
Doing scientific work? Want to embed sections of a spreadsheet in your Writer doc? Great, just don't expect the cells to look nicely. Border formatting in Calc sucks. Oh, and heaven forbid you find an error in your embedded spreadsheet cells; editing those in place is so problematic/laggy that it is just easier to delete the whole table and copy/paste from the (fixed) source spreadsheet. Text wrapping around these elements is abysmal... there's no option similar to Word's "in line with text", and so the thing stays as a floating table (no other option). OOo does offer some wrapping options that I don't think have parallels in MS Word: "background" and "through". These are excellent examples of a page wrap that I doubt anyone really wanted, because they allow text to wrap right through the table, becoming superimposed over or superimposing upon the table. Wow! Did I mention that the borders on the embedded tables will disappear on random sides when it comes time to print/export as PDF? WYSINWYG.
Charts in Calc suck. There is no analogue to Excel's "chart as a sheet" option. That means if you change your page layout, etc, you have to go manually try to resize the floating chart to the new desired size with your mouse. It is difficult to get it exactly to the print size limits, because the chart is a floating object that does not snap to cell borders and lags/jumps when you try to drag it for fine positioning. It is very easy to get it a few pixels off and then have your chart print out as multiple pages, yay! It should go without saying that printing charts is a pain unless you send them to another sheet (trying to print just the chart without the data that is otherwise on the sheet).
Which brings me to another point: there is no polynomial regression curve fitting for scatter plot charts in Calc, unlike Excel. This missing feature has driven me back to Excel for my reports more than once.
There are lots of little annoyances with Calc, like there being no quick way to perform a sum on all relevant rows in a column. In Excel, this would be "=SUM(B:B)". In Calc, you are forced to enter "=SUM(B1;B65536)". Annoying. Also, the use of semicolons to separate function arguments is an annoying difference from Excel. Why not just use the same format? Was it patented? Most of the rest of the UI tries to be Excel-like... so why this difference?
I could go on, but you get the picture. I believe the users who complain about OOo. Some just dislike having to learn anything new, but OOo does have serious limitations/annoyances for those who have scaled the learning curve. BTW, yes I did search for solutions to most of these issues/annoyances in OOo... they don't exist.
tl;dr: I use OOo because I hate MS, but it is very difficult to do so—sometimes it is impossible to get a final product polished the way you wanted. Using something this painful probably builds character.
I see the GP is well on his way to earning the elusive (Score:5, Troll) achievement which is one of the rarest drops on Slashdot (BTW, when did Slashdot turn into XBox Live with achievements? Now, get off my lawn...)
Just an FYI, your ad hominem attack does not detract from his legitimate point. I am well aware of the technical issues involved, but at some point you have to stop giving Linux & X Windows a pass just because Unix/X was crappily designed in this regard back in the 70's (tty's and client/server GUI apps). If stuttering media playback is a side effect of the present modular paradigm, then perhaps it is time to stop making excuses for it.
This is almost as bad as when people stepped up to defend the ext4 data loss / commit interval issue to say it was "by design". Yeah, it is trivial to avoid by calling fsync in your app all the time, but watch that destroy perf because it flushes the whole I/O queue for the system. Ordered data mode just makes sense... strange that wouldn't be default, or even an option to turn off if you think about it. So, what's a cautious app designer to do? Fsync all the time? Can a userspace app even query this flag? And no, using SQLite is not a legitimate workaround.
Same damn thing when Linux zealots call ZFS a "rampant layering violation" and then define away innovative capabilities like RAIDZ and cheap, versatile COW snapshots as "nonfeatures" because they can't be replicated while abiding within the Linux layering paradigm. Sour grapes, indeed. Btfs won't be able to replicate these features unless they break the layering paradigm, so who wants those features anyway?
Soooooo... watch me get flayed alive for my heresy: I say if the extant paradigm isn't optimal, then maybe it's time to consider changing it. At the very least, it's intellectually dishonest to claim that these aren't problems just because there are no simple fixes in the present model. As noted by others, this "fix" is essentially a heuristic with improved granularity for the given problem. Good, at least that's something. Now, how about the real, underlying problem?
Seriously.
You can also use numeric character references, but that's not very portable. What works for Windows is wrong on a Mac, for instance.
I thought Unicode (especially UTF-8) was intended to resolve this issue. With UTF-8 becoming nearly ubiquitous, EOL issues are a much bigger problem than character encoding.
.jp site, at least, uses UTF-8).
Don't get me wrong: I wish ISO-8859 and CP1252 would be incinerated by a bolt of lightning from Zeus for all the issues they have caused me over the years. The divine hammer can't be dropped soon enough: even Slashdot is stuck in the early 1990's by continuing to insist on using ISO-8859-1 for the US-based site (the
HTML escaped characters are a horrible hack in every case aside from the syntax interference related ones (greater than, less than, etc).
This evolution is essential. For instance, I should be able to inject some ancient Sumerian Cuneiform characters into this message, dammit! Unicode supports me on this!
This isn't just an idle desire for feature-creep. Sometimes I channel Ur-geeks who had to post their trolls via clay tablet in the marketplace, and dammit, they want a piece of this action. Writing something like "Your ancestors were so foolishly illiterate that they mistakenly grew flax instead of barley" just doesn't have the same punch in English as in Sumerian Cuneiform.
One thing that has always irritated me about tmpfs is that it will page out into swap if memory pressure dictates.
Using ramfs as an alternative to tmpfs means that you lose the ability to stipulate a maximum size, and it can grow to exhaust all available memory in the system. Because ramfs won't page out, I presume it is quite possible to take down the entire machine in such circumstances.
It's sad that MacOS (pre-X) had the problem solved 15 years ago by allowing the creation of a fixed size RAM disk that would not page out, but this capability has apparently been lost in modern OS's. Unrelated aside: it was quite fun to load a stripped down version of the MacOS System Folder into a RAM disk and watch how fast the machine would boot (MacOS RAM disks would persist between reboots but would naturally be obliterated if power was cut).
My (admittedly wishful) intent would be to promulgate a counter-meme, "Brooks' Law considered harmful".
When one considers the assumptions made by Brooks, it is apparent that his law is merely a case of Amdahl's Law with certain initial conditions and modeling parameters. I am actually surprised he didn't make a more generalized restatement of Amdahl's Law, because he is clearly referring to a maximum amount of speedup. Why stop with only "late" projects and not make a broader rule for dev projects in general?
If I may posit for your consideration, I suggest that your examples missed the broader point. Everything you pointed out is reasonable, but my suggested replacement for Brooks' Law is to use Amdahl's Law to calculate a hard upper bound on the maximum amount of speedup that could be obtained adding additional devs. The result would be something along the lines of "even if we hired 128 new devs who all instantly acted as as perfect development cogs and assume our project development is embarrassingly parallel, we would still miss the release date by at least 7 months". I contend that such a model would be significantly more useful than Brooks' Law.
If your maximum speedup from adding additional capacity is insufficient by an order of magnitude or more, then it's obviously time to consider alternatives. Contrariwise, if the numbers show a clear possibility of payoff then it might make sense to add capacity; however, this is much more ambiguous than what can be ruled *out* by Amdahl's Law.
Your examples point out how such a model could be abused, much as I allege that Brooks' Law is currently abused. If people turn the model around and start using it to project hard release dates based on dev team size, initial dev complexity estimates, and so forth, then such a model could easily become more harmful than helpful.
I believe we are in general agreement because the feasibility of any such calculation is predicated upon a well-managed, well-instrumented dev team. Ideally, there would be a reasonable amount of historical metrics about dev velocity statistical bands, "initial estimate vs. actual time required" fidelity, team overall velocity vs team size, typical ramp-up time, etc. Perhaps I have been spoiled by working on such teams in the past. Regardless, if you don't have a realistic basis for the numbers you are using, then all of this becomes yet another para-masturbatory exercise similar to the Drake Equation.
PS. In the link I posted above, it is shown that Gustafson merely restated Amdahl's Law via a different formulation—there is only one law.
It is false. Let's say you have a multi-year project and you hit a snag in the first 2 months, a snag which implies that complexity is somewhat increased compared to your initial estimates and would take an additional six months to complete if nothing changes—the project is now officially late. However, you can still release on schedule if you add another 10% capacity to your dev team. This is a very plausible scenario, and only one such scenario must exist for your absolute statement to be disproven.
So, you have to start adding further precise stipulations in order to make the original Brooks' Law even remotely plausible. For instance, the project has to be late but only insofar as it does not represent a fundamental shift in the amount of work to be done (in my example, more work has been "added" to the project). Furthermore, it is presumed that additional developer capacity will never reach breakeven for sunk training costs/bugs/etc before the project would be delivered anyway, which further restricts the number of applicable scenarios.
The communication network scaling factor is a straw man in itself because that is not how developers interact in a non-dysfunctional dev team. It's just retarded, even at a basic level: "Hello, Anne? You work on the kernel-level Windows USB hardware driver team, right? Hi, I am Gavin from the Windows Explorer dev team, and I am working on rendering icon panes for displaying directory contents, so I thought I would call you up—you know, because we have a fully interconnected dev team communication network and I thought I should inquire about your insights on my task." *cough*
The world would be a better place if we killed Brooks' Law and replaced it with understanding of Amdahl's/Gustafson's Law in conjunction with a rational consideration of new dev ramp-up time. Even as an "outrageous oversimplification" Brooks' Law is misleading and very likely harms more than it helps. How many projects were made even later when an appeal to Brooks' Law was used to cut off debate about adding capacity?
So Windows Vista could have been released in 2002 if Microsoft had only fired all but one member of the Windows development team back in 2001, before the Vista project started? Shit, hold on while I let all of my clients know that they don't need my services anymore—the answer is to fire all but one member of the team!
...or maybe it doesn't actually work the way you say, because the corollary to your claim is that release will happen soonest if no one is ever added to the project (one member is requisite for the project to exist at all). Back to the example: over the years Microsoft grew the Windows team up from 0 members, and I doubt they were doing it to reduce their development capacity.
Honestly, scaling is manageable if the project is broken down into bite sized chunks and the team is comprised of subteams (personal size preference: 4-5 members). Yes, there is added overhead, but hierarchy and management can mitigate such issues; Agile development practices make the overhead as painless as possible. It is naive to think that you need a fully-connected network for an entire (massive) project in order for the team to be able to function.
In summary, "Yes, you can add developers to a project and make it release sooner, so please stop spreading this meme which was only ever applicable if certain naive stipulations were presumed."
PS. There is a finite amount of release speedup available by adding additional devs (Amdahl's Law), but overall release complexity capacity per time unit increases (Gustafson's Law). This is a classical problem in parallel processing. Some dev projects are more serial in nature, others are embarrassingly parallel.
If we are speaking strictly (as US citizens), then please note that the US government asserts tax on your worldwide income. There is an exclusion on the first $~90k of annual income, but we are speaking *strictly*.
The only way to strictly avoid US taxation is to renounce your US citizenship, but there are clawback provisions to discourage that. However, once you have unwound your US investments/positions, renounced your citizenship (note: be certain not to become a stateless person), and filed your final tax returns, then you will strictly be free of US taxation.
You really cannot choose not to "do business" with the US government unless you are willing to uproot your entire life, likely leave behind your family, sell everything you own, live in a foreign land, and have circumscribed rights to return for visits. Show me a business that has anywhere near this level of coercive control or lock in.
Gustafson's Law giveth, while Amdahl's Law taketh away.
Interesting...
The frequency for maximum dielectric loss lies higher than the 2.45 GHz (wavenumber 0.0817 cm-1, wavelength 12.24 cm) produced by most microwave ovens.
I read an excellent journal paper about this just a few months ago, but I mislaid the link. Anyway, if memory serves, the frequency for maximum dielectric loss in liquid water was 11+ GHz. So, while 2.4 GHz may be a "sweet spot" for a microwave oven's efficiency at heating variegated foodstuffs, there is nothing special about it wrt to water (solid or liquid).
While I will concede that the legal system sometimes comes up with bizarre counter-intuitive redefinitions of common terms, the standard definition of annex in this context would mean "appendix". So, when you say that the common understanding of the singular term means the 1949 GC, well, you probably need to be even more precise because it would seem that an appendix to the 1949 GC would be considered part of the same. So, now it's "the 1949 Geneva Convention, as stated in 1949, not including any subsequent additions"?
I understand what you were trying to state in your original post; however, I would counter that when a topic becomes ambiguous, eg. "the singular term generally refers" and then requires even further armchair lawyering to establish definitions, then dropping a pedantic debunking hammer on others becomes disingenuous at best.
*cough*
"The full title is Convention on Prohibitions or Restrictions on the Use of Certain Conventional Weapons Which May Be Deemed to Be Excessively Injurious or to Have Indiscriminate Effects and it is an annexe to the Geneva Conventions of August 12, 1949."
It's somewhat regrettable to debunk your "debunking". You had quite a bit of momentum and righteous indignation in your rant; it sounds like you have had some practice spreading this particular bit of misinformation. My guess would be that you took the common misattribution of the dumdum bullets ban to the Geneva Convention and turned it into this sweeping generalization.
Reminds me of when I used to tell people that microwave ovens operated at a resonant frequency of water, repeating what my engineering prof told us in class. Ouch... there were quite a few people I had to go around and issue a retraction to. (FYI: 2.4 GHz has absolutely nothing special wrt water--resonance, dielectric, or otherwise)
Ah... I am fond of GMail aliases. Naturally, many times I have encountered the unsubscribe issue you describe; however, I have often emerged victorious (victory!)
You will often find that the unsubscribe links (or a GET-based form submission) will result in a URL. Workaday morons often forget to consistently URL-encode their input. They build an URL encoded query string, but they take your email address as a string literal. Bizarre.
So, your "foo+bar@gmail.com" will often be misinterpreted as "foo bar@gmail.com", thus confusing their system (space character encodes as +). Fortunately, you can take the high path with these drooling simps by simply adding the missing URL encoding feature for them: '+' encodes as %2B.
Change the salient part of the URL to be "foo%2Bbar" and you should expect a warm feeling of superiority to wash over you. Oh, yeah, and it will finally kill that fucking spam those morons keep sending you.
HTH. Don't forget to send nastygrams to their customer service departments about their moronic devs.
This has already come to pass.
Who would have thought that giving the Russians a monopoly would give them more leverage in setting the price we pay? Maybe we should have a Congressional committee study this phenomenon and produce a report explaining how such a price increase could possibly have happened. Unfathomable mysteries, indeed.
Haha, fair point. However, the substance of my comment stands: the Constitution enumerates all of the powers that are granted to the Federal government. Any authority that the Feds wish to claim must be linked to an enumerated power or the claim is illegitimate.
Alliant has the "web form + mail-in" option (eDeposit) and then a scanner-only (no mail) option (eDeposit Plus). Personal opinion: eDeposit Plus has *very* finicky analysis software. Check images of front & back must be JPEG, greyscale, 200+ DPI, < 1 MB per file, and *no* whitespace around the check image. I ended up spending more time scanning (and subsequently in GIMP) than it would have taken to mail in the check.
There are limits. Apparently eDeposit Plus has a daily limit of $1500, but this limit might eventually be extended to $5000 based on Alliant's experience with you. Regular eDeposit (mail-in) has a range of 5k to 20k.
I have no idea what USAA's limits are, because it is academic.
I don't see anything in the current Constitution that would make mandatory insurance illegal.
Your statement is posed incorrectly. The Constitution does not form a list of prohibited actions for the Federal government; rather, it forms a comprehensive list of everything the Federal government is allowed to do. The founders of the country were very concerned that the Federal government would become all encompassing and supersede state and local authority in day-to-day life.
I counter your comment with a question of my own: where in the Constitution do you see that the Federal government has the right to force individuals to obtain health insurance? Please notice that in my comments I have not yet weighed in on one side or the other of the health care debate. I am merely asking under which Constitutional theory the Federal government has been granted the right to mandate individual health coverage.
It is very clear: if the Federal government cannot link their authority for the health insurance mandate to an explicitly Constitutionally-granted Federal power, it is illegal. As I said, this is the reason why they were forced to pass the 16th amendment in order to assess individual income tax--they did not have an explicitly Constitutionally-granted authority to assess individual income tax. Same with Prohibition.
The Constitution is designed to tie the hands of the Federal government--not the people.