DreamHost has a diverse array of services, geek-oriented tech support, and a community oriented around tech-friendly features. I've been very satisfied for many years. If they don't support it, I guarantee one of the in-house developers has an unofficial install working somewhere that they'd be happy to copy over.
Of the nine U.S. Unified Combatant Commands, AFRICOM (United States Africa Command) is the newest. Both W and Obama have expressed significant interest in expanding the role of U.S. operations in Africa, for purposes of counter-terorrism and a desire to improve stability (ironically, special operations forces are historically used to invoke instability in a nation-state). The Obama operations in Libya during its civil war was actually AFRICOM's coming-out party, its first chance to be a real boy.
Since then, AFRICOM has moved forward in supporting policy roles by expanding U.S. military facilities, particularly those supporting drone operations, on the continent. this implied that special operations were the next step--why just spy on a terrorist cell when you can try and capture it's leader, too?--so learning about these events is not a big surprise. However, the relative failure of these efforts (at least the Somalia operation--the Tripoli operation may or may not be a disappointment at the policy level, depending on how sincere their protests are) is something of a black mark on AFRICOM's plans. There is some serious head-scratching going on, I am certain, and the role of tactical operations is likely being re-evaluated.
The shutdown has not yet affected me, save to the extent that we can get a heck of a lot more work done without the government contractors constantly throwing spears and interfering with forward movement for the sake of satisfying their own egos. The rest of my industry's getting hammered--NASA in particular--so I know how fortunate I am. Still, I can't help feeling that the shutdown as a whole is experiencing a great deal of hype, and I'm tremendously disappointed in the way which so many officials are doing their best to exaggerate and exacerbate the impacts ("shut down" Twitter feeds, websites, and parks being the three best examples).
Children can learn programming from a very early age. Kindergarten is a good place to start, because by that time interested parents (not teachers) have likely introduced the child to the only two real prerequisites:
Basic arithmetic (2 + 1 = )
Elementary logic (this-then-that, if-then)
The remaining skills necessary to become interested in, and capable of, writing code can be picked up concurrent to coding itself:
Typing
Variables and assignment
Control flow
Now that we've dispensed with the technical items, we need to address something amiss in this discussion--and where TFA gets it wrong. Teaching your kids to program is NOT a matter of pushing your school to displace an art, music, or language class. If you are truly interested in getting your kids to code, this is a topic best taught by YOU. My daughter is currently 3 years old, and while she's fascinated by computers, we've got to tackle the prerequisites listed above first. (I'm guessing we'll start actual coding around the time she turns 5.) I'm eagerly chomping at the bit for the opportunity!
Since there seems to be a dearth of actual parents in this discussion, let me point out one more thing. School is fine for teaching fundamentals (which you can dispatch to large groups of kids simultaneously) and some other topics (where parents may not have sufficient familiarity). When you are both a parent and a geek, though, you can't WAIT to share the really awesome tidbits of knowledge with your kid--and even if it is something their school covers, you're going to be so excited that you'll show it to them first, just to make sure they know how amazing the world really is. That's why we listen to Symphony of Science in the car, and why lately we've been spending our spare time building spinning machines. When we finally sit down and write our first BASIC program together (screw you, Dijkstra--you were an amazing scientist, but a horrible educator), it's going to be for the same reason: I want to share it with her!
This approach appears to be slightly different from traditional frame stacking, in that they are utilizing a low read noise (really, 1e- doesn't pass the smell test--there's got to be some tradeoffs) to take a large number of frames with short exposure times. The only other interesting approach they are taking is searching the velocity space, for which (given 1000 points) they need a 2500-node HPC cluster (you do have one of those in your closet, yes?). From their description, they are also only searching 1px/frame movement, which runs into PSF constraints when the atmosphere starts blurring your crazy-sensitive focal plane (they give a token nod to this problem, and then promise to look into it in a future paper).
There are a couple of items that raised some red flags, including errors in formulating SNR calculations (who measures it in sigma? optical sensor pd--probably of detection--is typically computed for SNR = 6 or 10, in linear space), the avoidance of frame-stacking technique comparisons (as you noticed), and the fact that they conclude with a single-paragraph (5 1/2 lines) consideration of instrumental effects (everything depends on your sensor performance, noise, and sensitivities) while telling us to wait until yet another paper to straighten the issues out.
Of course, I'm being overly critical. I'm actually looking forward to seeing what this approach can do, given that everyone's pretty much given up on characterizing this class size of asteroids in the past. 90% of what they are saying is actually consistent with theory, it's the practice bit where the red flags are going up. It's worth keeping in mind, though, that you don't publish CalTech papers and get time on the Palomar 200" by being a dim-witted slacker.
As an engineer who lives practically next door to one of the hubs of so-called 'Silicon Beach', let me tell you that there is more publicity than business behind this concept. Don't get me wrong--there are legitimate reasons for considering the Los Angeles area a decent tech hub. A number of my favorite companies (Dreamhost!, and others) are located here, typically somewhere between the downtown area and Santa Monica. One of the biggest benefits is the thriving venture capital communities in the downtown and Pasadena areas, which is an understated-but-critical component to any truly substantial claim to 'Silicon [noun]'. (Strong venture capital communities also come with excellent startup support, commonly in some form of incubator.) You also get some great synergies between the educational institutions in the area (USC, UCLA, CalTech, Claremont colleges...), ongoing technology business efforts, and the parallel (not-as-mighty-as-it-once-was-but-still-substantial) aerospace community. We're fortunate to have a new (at least moderately) technically literate mayor, who's been pushing this 'Silicon Beach' idea quite a bit.
But that's the end of the good news. Here's why the TFA totally misses the mark, and (most likely unintentionally) buys into one of the latest political fads here in southern California.
First, the MySpace influence is strongly overrated. Businesses fail and shrink all the time, and--surprise--when they do, talented engineers will go off and do other things. The article paints a picture that implies that MySpace was this huge supergiant of a tech star, which went nova and whose subsequent remnants collected to spawn a whole new constellation of stars. In reality, MySpace was never really that big of a tech phenomenon or local influence. It's nowhere near as substantial as the unprecedented collapse of the southern California aerospace community (a PDF--page 11 is most interesting) after the Cold War. If you don't want to click the link, here's a summary: southern California employed 271,700 aerospace jobs in 1990; that number dropped by 57% by 2000, and continues to plummet (88,4000 in 2011). It really makes MySpace look like a drop of piss in a thunderstorm.
Second, it's easy to underestimate the fact that southern California--even just 'Los Angeles'--is a really, really big place. The Silicon Valley is ~46km long (I'm measuring from San Mateo to downtown San Jose--the width, of course, is mere miles), and Wikipedia puts the population between 3.5 and 4 million. By comparison, Los Angeles county alone is 76km (Santa Clarita to Long Beach) by 74km (Santa Monica to Claremont), with a population of 10 million souls. Why is that relevant? It shouldn't be a surprise that, in a really big area, there are going to be a few winning tech companies. Few people can even agree what 'Silicon Beach' constitutes. Is it supposed to be Playa Vista, with the new Fox technical studios (a la MySpace), Electronic Arts offices, and a few new offices in newly-remodeled air hangers? It is sort of the west side in general, where Google has recently consolidated a new office (in Venice Beach), and Activision-Blizzard is headquartered (Santa Monica)? Is it the general downtown vicinity, including North Hollywood and other light industrial areas, where established tech businesses have high-rise offices and new startups are renting out old movie studios for a steal of a rate? Is it the city of Los Angeles in general, with a new tech-friendly mayor, or the county, including tech-friendly Pasadena (CalTech and JPL, plus a lot of venture capital organizations)? Or does it also include Orange County, host of a whole slew of tech-sector ecosystems centered around U.C. Irvine (including the
Johnson's biography is quite a good read--not going to win a Nobel prize in literature any time soon, but the content is a delight for aerospace engineers like me. Johnson WAS Skunk Works, for many many years.
Funny note about Rule 4: He's advocating version control for engineering projects. If he was alive today, I suspect Mercurial would give him a hard-on.
Rule 4: A very simple drawing and drawing release system with great flexibility for making changes must be provided.
Last point: It's funny how many of the 14 Rules are anathema to modern management practice, particularly as implemented by the dominant aerospace firms. I'm not saying you can solve all of the industry's problems by requiring 14 Rule adherence, but you'd come close, The parent post already mentioned Rule 14, and implied it's laughable contradiction with current pay-scales in the engineering industry; Rule 5 directly contradicts the micro-managed, hyper-documented approach for modern systems engineering standards. Rule 12 has been repeatedly blown away by deeply-ingrained contractor dishonesty w.r.t. pricing and scheduling estimates, and by contractees' fanatical devotion to requirements creep and abrupt project changes (although in fairness, the budgeting environment doesn't help things), and as a result it's hard to imagine that this kind of trust will ever again exist between the government and the large aerospace contractors. Rule 10 is also a victim of this phenomenon.
I try to avoid becoming involved with./ articles that are little more than glorified blogposts, but this is a subject near and dear to my heart. I am an engineer who graduated from a 'liberal arts' college that offered six majors: math, physics, engineering, chemistry, biology, and computer science. There was, however, a Humanities and Social Sciences department, and students are required to take eleven courses (including an introductory course on random topics that emphasizes writing skills) from the 'Hums' before they can graduate, regardless of their major.
It's my conclusion, from experience, observations, and a lot of thought on the topic, that this is a good approach. It forces highly-intelligent technical people to spend significant time ourside of their comfort zone, which in itself is a valuable experience. What's more, because so many of these highly-intelligent technical people are able to follow Hum topics that actually interest them (you are required to choose an area of concentration for at least four of your eleven course), there's a lot of critical thinking going on between the students and Hum professors. This prevents the latter group from being too fring-idealogical (you know what I'm talking about--the avowed communist economics teacher who tells engineers that it is immoral for them to make a profit from their work, for one arbitrary example); professors actually have to stay on their toes, and some of them even enjoy dropping marginal / controversial / partisan topics into their courses every know and then just to watch the students react and critically tear it apart. Lots of fun discussions occurs.
That having been said, TFA is completely the wrong approach. This idea of 'science-vs-non-science' is absurd, but even worse than the condescending elitism shown by the scientific side of the discussion is when you find gentlemen like this author, who somehow manage to convince themselves that they are the Secret Guardians of the Superior Non-Rational Secrets to the Universe, which mere reason (and scientists who use it) can never hope to comprehend. (Don't tell me you haven't meet anyone like this--there are at least four in every Coffee Bean at any given point in time, reading their latest Jenny McCarthy blog post and trying to pass head shots off to anyone who looks like an acting agent.) This isn't skepticism (which is a profoundly scientific trait, by the way, despite what TFA tries to advocate); this is blind contrarianism with a dash of well-read, modern pseudo-intellectualist voodoo.
Not just a model (no one would make a high-performance plane with that amount of composites--any failure mode worth considering would be catastrophic to anyone within 100s of meters)... It's the nation-level equivalent of a 3rd grader drawing pictures of giant robots shooting flame from their eyes and terrorizing Tokyo. That particular design couldn't fly above 0.15 Mach without an incredibly sophisticated suite of controls--the forward canards are far too big and the plane itself is inherently unstable--far beyond the capabilities of any nation but the U.S. and Russia. You also won't be able to generate enough lift with that small of wing area unless you are traveling far too fast (boundary layer will separate by the second airfoil) and with an engine that, again, is far beyond the efficiency and miniaturization capabilities of Iran's industrial and scientific base. An enumerated on this page, there are hundreds of other reasons to laugh--which is really what this is all about; Iran technological developments are to aerospace nerds what Joe Biden's quotations are to the political analyst community.
Social changes are hard and difficult to enforce--the most reliable way is to thoroughly screen who you hire and, reciprocally, who you work for, both of which are moot points for situations like this. Therefore, I am going to enumerate three easy steps, albeit brute-force, that should help change the way you and your engineers work and think. Devious, yes--but wait on your judgement until you've read through the list, they're not all that bad.
* Start managing a trunk repository, and require all engineers to branch and merge as needed. Nearly every version control tool worth a darn now adays can handle distributed repositories, and most are easy to learn.
* Document, document, document. Interns are great for this, as it's also a good way to learn a new code base. It's also easier to track and sort new feature requests when you know where they stand with respect to your current version. This doesn't have to be Word DOCs--two easy and useful alternatives are wikis and PowerPoint (a lot easier to edit and communicate with the former; a lot easier to diagram and illustrate with the latter).
* Establish an expectation of workflow--specifically, bug and feature pipelines. A substantial part of this duty falls on your shoulders, as you must always know (or be able to look up) who is working on what, and where that piece fits into the big puzzle. Particularly important is the feature pipeline, as this is your interface to managers and others who interact with your code base.
I'm assuming, of course, that you haven't already done these things. If you have, there are many ways to take it to the next level: start using Bugzilla (or a similar tool) to track bugs and features; organize your documentation into User Guides, ICDs, and ADDs; define a small but standardized set of processes for complex challenges; etc. You get the idea--incremental is good, as you can't simply dictate, from top down, the behavior and practices of your engineers (unless... are you on a management track?). Of course, if you're in a CMMI-4 organization in which each person has their own HG clone of the primary code base, with your own QA and support staff, these are hopefully already in your rear-view mirror.
One additional practice I would recommend is periodic release cycles--that is, release a major version every year, minor every month (or some variation thereof), and include in each release only the features and updates that are ready. If you can get to a point where your schedule and release cycle is no longer at the mercy of your requirement creep problems or an almost-done set of patches, you will find the atmosphere becomes much more productive and stress-free; quality will skyrocket as a result.
Last but not least... I'm sure there will be many fine suggestions from knowledgeable slashdotters on this page. Pick and choose the ones you think will work (feel free to ignore all of mine, except this one) for your team / company / project--and when you sit down to implement them, don't expect to get away with 100% of your changes. Do what you can, what you are allowed, and what keeps you productive. Too many idealistic junior managers or engineers-turning-managers try to bring their 'brilliant ideas' into an environment where they simply don't work, and the lack of pragmatism leads to total failure of all of their efforts, when they could have gotten away with 60% (which is better than 0%). Throw in the vast world of methodologies, process monkeys, and paradigm acolytes, and you'll see why it's worth being cautious and flexible.
As a long-time contributor to Wikitravel, I'm very glad to see Wikivoyage managed by Wikimedia. Internet Brands, the organization that took over Wikitravel some time ago, has been turning their site into a classic example of ham-handed monetization; compare intrusive travel booking banners and horrendously limited search to their respectivealternatives. For a while, they were even several versions behind the MediaWiki platform itself. I abandoned contributing to Wikitravel last year, and I'm very happy to have a new place to which I can contribute content. More importantly, I suspect I'm not the only one.
It seems like a lot of contributors here are missing the point. Discussions like this--and particularly the analysis that provokes them, regardless of how perfect it may be--are highly valuable and productive, for the same reason as project post-mortems. Too often, debates about development (where it's styling, methodologies, or rules of thumb) are done before coding begins, and as a result, several things invariably happen:
* Contributions are made by people with little or no knowledge of the topic
* Contributions are made by people with little or no experience
* Too much time is spent debating theory and not practice
* Minor and unimportant topics absorb the majority of pre-development time and energy
* Development planning becomes convoluted, and / or ends of being thrown out as actual development begins and unforeseen issues arise
This, of course, is a reflection of the principle that a good engineer learns from his mistakes, while a great engineer learns from other people's mistakes. Both pictures and hindsight are worth a thousand pre-emptive, ill-informed words. I'm particularly pleased with the focus on coding quality, which (in post-mortems and hindsight analysis like this) takes second place to project and management practices. I will take, and have learned infinitely more from, 10/.-ers debating an informed and evidence-based review of a quality codebase over 1000s of discussions about programming theory, the latest development paradigm fad, or some wannabe game designer's blog post.
Not to say it wouldn't be impressive, but you clearly have to define your conditions for success. I'll bet both sides will (in fact, effectively have already) released conclusions in hindsight claiming victory--Anon. for executing so many attacks, with visible successes here and there, and Israel for not really loosing anything critical and demonstrating a well-designed and operated CSec environment.
So nice to read a decent post about the original topic and not another who-to-blame-in-the-middle-east piece. Let's discuss.
I can count the number of serious players in large-scale cyberwar on one hand. Anonymous isn't one of them--and Israel is. Defacing websites and conducting DDoS is something you do to make a point--not make a difference in full-scale military conflict or subversive operations.
One of the things I am most amused by is the explicit reference to Israel's threat to cut off Palestinian internet access as the trigger for their actions. The death of multitudes of innocents on both sides isn't enough reason to take action, but if a Palestinian can't check his email, it's war! That, combined with the stance they took and the targets they are choosing, is a pretty clear indicator of their scope and level of maturity.
I would add one more interesting note worthy of a Slashdot post: In the constant P.R. war that is the Israel-vs.-Palestine conflict, Israel has converted their live blog of events into some sort of a web-based achievement game. They're getting a lot of flack, and it's fair to say it lacks taste, but to me it seems more of a P.R. failure and less an indication of eeeevil. Don't think I'll be trying to grind my Level 11 IDF Rifleman any time soon.
Computer science is a branch of mathematics; software engineering is a collection of methods for applying that math in the "real world."
Close, but I would add the following:
* A computer scientist can formally prove that his algorithm will solve your problem effectively. He or she is focused on solving interesting problems. Computer scientists are more likely to be found on a technical track or consulting. Small, extremely difficult, technologically challenging problems and performance demands are commonly attract of computer scientists.
* A software engineer is an engineer who programs as, or in the course of, his job. He or she is focused on creating a product (in the engineering, not business, sense). Software engineers are more likely to move eventually towards a managerial track, and will be oriented towards formal processes (requirements, etc.--either agile or formal). Software engineers are more likely to be found in enterprise environments and in disciplines where integrated systems (aerospace, etc.) are critical.
This is actually different from the developer-vs.-software-engineer discussion the other week--'developer' is a generic term for anyone who can write code. It can therefore also be a nearly-derogative term to people who write code but are neither computer scientists nor software engineers--for example, a computer scientist or software engineer might call someone a developer if they can write a web page or script a game, but aren't familiar with the underlying architecture of the server or engine they're using.
There are some very interesting studies regarding the links between meat consumption, testosterone levels, and related impacts. Most point to zinc shortages in one's diet, and the corrected testosterone levels incurred when said shortages are addressed by increased meat consumption. Not to say, especially as I happen to be a male, that increased testosterone levels will guarantee lying, cheating, and stealing. There does, however, seem to be a (single-sample-point, empirically-backed, possibly-placebo) link between consumption of multiple medium-cooked 2/3-lb burgers from The Counter and one's libido over subsequent days. (Not to spam a business link, but it's by far the tastiest way to get a testosterone boost I know of.)
I'm surprised a government-funded project would qualify at all. I mean, NASA's landed rovers on Mars--do we really doubt national governments' abilities to put something similar on the moon? I was under the impression that the whole point was to encourage privately-driven efforts. After all, if government-funded rovers were eligible, the USSR would have won with Luna 17 / Lunakhod 1--42 years ago.
TV is, strangely, one of those things that's begging to be reinvented in a way that integrates all of the great potential of internet + TV + consoles + disc players + multi-channel / caching devices, etc. Typically we'd look to Apple to show everyone how a problem like this really should be solved, but I think we all know how well that's gone. Speaking for myself, I will continue to simply plug in my laptop to my flatscreen's HDMI port and not bother with silly things like cable or satellite subscriptions. Until you can give me a way, for example, to watch HBO (and not Lifetime, or MSNBC, or any of the other 500 channels I'd never touch with a 31.5-foot pole) without paying hundreds of dollars a month for the Super Platinum Ultra cable package, the value just isn't there. A handful of networked (and some cable) shows are already doing this on Hulu, but the push for Hulu Plus subscriptions (and accompanying limitations on free Hulu) is really starting to get annoying.
In the long run, I think Google's approach is the one that time will show to be the winner. They're constantly looking for ways to extend search for better monetization (and after all the hammer thinks everything is a nail), but I think that's going to be the sustainable market path that can eventually take us to a day when I can--for example--pay a $10 subscription fee to watch real-time releases of Game of Thrones in the same way I can pay a modest fee for privileged access to my favorite Twitch channels. When the monetization comes full circle, and starts feeding back into investment and production of shows, it will produce a much tighter feedback loop and much better programming, much the same way cable did when it originally had its heyday so many years ago.
Because, if you (as the government) insist on getting your money back for a program you cancel after overruns and delays, you get unending lawsuits and are stuck in litigation for several decades. There's a better way to do things, to be sure, but payment on delivery (or from another perspective, 100% refunds) are out of the question for cases in which much of the cost has been sunk into hundreds of man-months of up-front professional (engineers, developers) labor or even purely scientific research.
Major projects in software and aerospace, especially when boundaries are being pushed (frequently, though not always, the case in aerospace--less so in ERP), can require a lot of up-front investment before a single product roles off the line. The B-2, for example, has a flyaway cost of $555M, but the total program cost $44B. We call it NRE--non-recoverable expenditure--and if there were absolutely no guarantees regardless of outcome, boundaries would never be pushed by interested parties of a certain size (i.e., DoD / enterprise software corporations / aerospace companies) because such entities are, by their, nature, VERY risk-averse.
Perfect application of Hanlon's Razor: Not so much a conspiracy to waste money as the worst combination of both world (defense acquisition and enterprise software development). Both fields are very prone to overruns, scope creep, and repeated waste of funds as manager after manager--or contractor after contractor--throws away work to start over again. Another great example is the FAA's version of enterprise software, which is currently at $63.4 BILLION and counting (though, to be fair, it's quite possible the most complicated software project in the world).
Still, there are worse examples--specifically, when these kinds of overruns, violations, and program restarts are done deliberately to ensure continued funding to entrenched players in a limited field and / or to pursue minor permutations on someone's pet dream of a project. This can occur at the cost of throwing away many years and billions of dollars of decent work while never really getting closer to a functioning system. Space Launch System, anyone? (Not a software example, but the line between software and aerospace engineering is a lot thinner than most people realize.)
Permit me to interject a perspective into my favorite bastion of anarchical Democrats. Read or ignore at your own prerogative.
First and foremost (that is, most relevant to the OP) is the following observation: If any state has a chance of seceding, and doing so successfully in a way that leads to a growing and stable nation-state, it is Texas. The reasons are too many to list here--suffice it to say, there is precedence, will, and ability. (If you doubt it, consider the following: You are POTUS, and Texas secedes. You lose the Marine Corps. Immediately. In a closely-related event, 12 hours later you will also lose the capitol, Norfolk, and New York.)
Second, schisms embodied by secession movements highlighted here do not strictly adhere to red-vs-blue state correlations. (Note, for example, that Oregon, New York, and New Jersey are also on the list.) Instead, movements like these are built around a perception that the governing body does not represent the best interests of a subset of their constituents--sometimes even a perception that they are actively working to their detriment. In many red states, this is realized in the perception that the federal government ignores, if not mocks and holds in contempt, those states, their residents, and their values. In the three aforementioned blue states, there is a sizeable portion (as measured by population or geography) that is soundly overruled by a larger subset (or a subset with stronger influence over state policy).
I can speak from experience that non-Willamette Oregonians feel like they are ruled by those who live in the 'Valley'--Portland, Salem, Eugene, and surrounding burbs. Tax money flows from industries outside of the regions into one or two metropolitcan areas to build local light-rail projects, subsidize regional interests, and fund other policies exclusive to those areas. This is a major driver behind the movement to create a state of Jefferson, consisting of southern Oregon and northern California (residents of the latter face similar problems with their state government in Sacramento and the population centers of the Bay Area & southern California). I suspect there are similar sentiments in upstate New York and mid/southern New Jersey (i.e., urban and commuting populations effectively nullifying the idealogies of their rural and local counterparts).
Lastly, it's worth pointing out the nature of the ongoing discussions (some would say civil war) within the Republican party. One major driving factor that is often downplayed (if noticed at all) is the degree to which ideology drives conservative politics--much more so than counterpart mechanisms on the left, which are typically more issue- and demographically-oriented. Here's an example, in which I attempt to list some of the major factions in the ongoing discussions:
* Republican Intelligensia (pundits, think tanks, and beltway thinkers) are primarily focused on the demographic issues--how do we best adjust our message (if not change it outright) to best appeal to voting block Z? Most truely wealthy Republicans fall into this group.
* "Value Voters" (i.e., those vote for Republicans primariliy on religious--as opposed to universally moral--issues) will be convinced of whatever their leaders tell them. That's the thing about religious movements--they're very finicky, and can change abruptly when they perceive slights or when their leaders start playing power games. Officials spend a lot of time running after their vote, particularly after the elections between 2000 and 2004, but (as can be seen in the recent election, where turnout was surprisingly low) to very little effect. Since this is Slashdot, I should point out that, to the degree that anti-science and fundamentalist viewpoints have grown into the Republican party platform, it is exclusively a result of efforts to capture this block.
* Dittoheads (middle class working voters) are the base of the party (numbers of the previous two are insufficient to successfully elect a national platform, though
Slashdot Mirror
Oh, yeah: .NINJA domain advocacy. Enough said.
DreamHost has a diverse array of services, geek-oriented tech support, and a community oriented around tech-friendly features. I've been very satisfied for many years. If they don't support it, I guarantee one of the in-house developers has an unofficial install working somewhere that they'd be happy to copy over.
Of the nine U.S. Unified Combatant Commands, AFRICOM (United States Africa Command) is the newest. Both W and Obama have expressed significant interest in expanding the role of U.S. operations in Africa, for purposes of counter-terorrism and a desire to improve stability (ironically, special operations forces are historically used to invoke instability in a nation-state). The Obama operations in Libya during its civil war was actually AFRICOM's coming-out party, its first chance to be a real boy.
Since then, AFRICOM has moved forward in supporting policy roles by expanding U.S. military facilities, particularly those supporting drone operations, on the continent. this implied that special operations were the next step--why just spy on a terrorist cell when you can try and capture it's leader, too?--so learning about these events is not a big surprise. However, the relative failure of these efforts (at least the Somalia operation--the Tripoli operation may or may not be a disappointment at the policy level, depending on how sincere their protests are) is something of a black mark on AFRICOM's plans. There is some serious head-scratching going on, I am certain, and the role of tactical operations is likely being re-evaluated.
The shutdown has not yet affected me, save to the extent that we can get a heck of a lot more work done without the government contractors constantly throwing spears and interfering with forward movement for the sake of satisfying their own egos. The rest of my industry's getting hammered--NASA in particular--so I know how fortunate I am. Still, I can't help feeling that the shutdown as a whole is experiencing a great deal of hype, and I'm tremendously disappointed in the way which so many officials are doing their best to exaggerate and exacerbate the impacts ("shut down" Twitter feeds, websites, and parks being the three best examples).
Children can learn programming from a very early age. Kindergarten is a good place to start, because by that time interested parents (not teachers) have likely introduced the child to the only two real prerequisites:
The remaining skills necessary to become interested in, and capable of, writing code can be picked up concurrent to coding itself:
Now that we've dispensed with the technical items, we need to address something amiss in this discussion--and where TFA gets it wrong. Teaching your kids to program is NOT a matter of pushing your school to displace an art, music, or language class. If you are truly interested in getting your kids to code, this is a topic best taught by YOU. My daughter is currently 3 years old, and while she's fascinated by computers, we've got to tackle the prerequisites listed above first. (I'm guessing we'll start actual coding around the time she turns 5.) I'm eagerly chomping at the bit for the opportunity!
Since there seems to be a dearth of actual parents in this discussion, let me point out one more thing. School is fine for teaching fundamentals (which you can dispatch to large groups of kids simultaneously) and some other topics (where parents may not have sufficient familiarity). When you are both a parent and a geek, though, you can't WAIT to share the really awesome tidbits of knowledge with your kid--and even if it is something their school covers, you're going to be so excited that you'll show it to them first, just to make sure they know how amazing the world really is. That's why we listen to Symphony of Science in the car, and why lately we've been spending our spare time building spinning machines. When we finally sit down and write our first BASIC program together (screw you, Dijkstra--you were an amazing scientist, but a horrible educator), it's going to be for the same reason: I want to share it with her!
This approach appears to be slightly different from traditional frame stacking, in that they are utilizing a low read noise (really, 1e- doesn't pass the smell test--there's got to be some tradeoffs) to take a large number of frames with short exposure times. The only other interesting approach they are taking is searching the velocity space, for which (given 1000 points) they need a 2500-node HPC cluster (you do have one of those in your closet, yes?). From their description, they are also only searching 1px/frame movement, which runs into PSF constraints when the atmosphere starts blurring your crazy-sensitive focal plane (they give a token nod to this problem, and then promise to look into it in a future paper).
There are a couple of items that raised some red flags, including errors in formulating SNR calculations (who measures it in sigma? optical sensor pd--probably of detection--is typically computed for SNR = 6 or 10, in linear space), the avoidance of frame-stacking technique comparisons (as you noticed), and the fact that they conclude with a single-paragraph (5 1/2 lines) consideration of instrumental effects (everything depends on your sensor performance, noise, and sensitivities) while telling us to wait until yet another paper to straighten the issues out.
Of course, I'm being overly critical. I'm actually looking forward to seeing what this approach can do, given that everyone's pretty much given up on characterizing this class size of asteroids in the past. 90% of what they are saying is actually consistent with theory, it's the practice bit where the red flags are going up. It's worth keeping in mind, though, that you don't publish CalTech papers and get time on the Palomar 200" by being a dim-witted slacker.
As an engineer who lives practically next door to one of the hubs of so-called 'Silicon Beach', let me tell you that there is more publicity than business behind this concept. Don't get me wrong--there are legitimate reasons for considering the Los Angeles area a decent tech hub. A number of my favorite companies (Dreamhost!, and others) are located here, typically somewhere between the downtown area and Santa Monica. One of the biggest benefits is the thriving venture capital communities in the downtown and Pasadena areas, which is an understated-but-critical component to any truly substantial claim to 'Silicon [noun]'. (Strong venture capital communities also come with excellent startup support, commonly in some form of incubator.) You also get some great synergies between the educational institutions in the area (USC, UCLA, CalTech, Claremont colleges...), ongoing technology business efforts, and the parallel (not-as-mighty-as-it-once-was-but-still-substantial) aerospace community. We're fortunate to have a new (at least moderately) technically literate mayor, who's been pushing this 'Silicon Beach' idea quite a bit.
But that's the end of the good news. Here's why the TFA totally misses the mark, and (most likely unintentionally) buys into one of the latest political fads here in southern California.
First, the MySpace influence is strongly overrated. Businesses fail and shrink all the time, and--surprise--when they do, talented engineers will go off and do other things. The article paints a picture that implies that MySpace was this huge supergiant of a tech star, which went nova and whose subsequent remnants collected to spawn a whole new constellation of stars. In reality, MySpace was never really that big of a tech phenomenon or local influence. It's nowhere near as substantial as the unprecedented collapse of the southern California aerospace community (a PDF--page 11 is most interesting) after the Cold War. If you don't want to click the link, here's a summary: southern California employed 271,700 aerospace jobs in 1990; that number dropped by 57% by 2000, and continues to plummet (88,4000 in 2011). It really makes MySpace look like a drop of piss in a thunderstorm.
Second, it's easy to underestimate the fact that southern California--even just 'Los Angeles'--is a really, really big place. The Silicon Valley is ~46km long (I'm measuring from San Mateo to downtown San Jose--the width, of course, is mere miles), and Wikipedia puts the population between 3.5 and 4 million. By comparison, Los Angeles county alone is 76km (Santa Clarita to Long Beach) by 74km (Santa Monica to Claremont), with a population of 10 million souls. Why is that relevant? It shouldn't be a surprise that, in a really big area, there are going to be a few winning tech companies. Few people can even agree what 'Silicon Beach' constitutes. Is it supposed to be Playa Vista, with the new Fox technical studios (a la MySpace), Electronic Arts offices, and a few new offices in newly-remodeled air hangers? It is sort of the west side in general, where Google has recently consolidated a new office (in Venice Beach), and Activision-Blizzard is headquartered (Santa Monica)? Is it the general downtown vicinity, including North Hollywood and other light industrial areas, where established tech businesses have high-rise offices and new startups are renting out old movie studios for a steal of a rate? Is it the city of Los Angeles in general, with a new tech-friendly mayor, or the county, including tech-friendly Pasadena (CalTech and JPL, plus a lot of venture capital organizations)? Or does it also include Orange County, host of a whole slew of tech-sector ecosystems centered around U.C. Irvine (including the
Johnson's biography is quite a good read--not going to win a Nobel prize in literature any time soon, but the content is a delight for aerospace engineers like me. Johnson WAS Skunk Works, for many many years.
Funny note about Rule 4: He's advocating version control for engineering projects. If he was alive today, I suspect Mercurial would give him a hard-on.
Rule 4: A very simple drawing and drawing release system with great flexibility for making changes must be provided.
Last point: It's funny how many of the 14 Rules are anathema to modern management practice, particularly as implemented by the dominant aerospace firms. I'm not saying you can solve all of the industry's problems by requiring 14 Rule adherence, but you'd come close, The parent post already mentioned Rule 14, and implied it's laughable contradiction with current pay-scales in the engineering industry; Rule 5 directly contradicts the micro-managed, hyper-documented approach for modern systems engineering standards. Rule 12 has been repeatedly blown away by deeply-ingrained contractor dishonesty w.r.t. pricing and scheduling estimates, and by contractees' fanatical devotion to requirements creep and abrupt project changes (although in fairness, the budgeting environment doesn't help things), and as a result it's hard to imagine that this kind of trust will ever again exist between the government and the large aerospace contractors. Rule 10 is also a victim of this phenomenon.
I try to avoid becoming involved with ./ articles that are little more than glorified blogposts, but this is a subject near and dear to my heart. I am an engineer who graduated from a 'liberal arts' college that offered six majors: math, physics, engineering, chemistry, biology, and computer science. There was, however, a Humanities and Social Sciences department, and students are required to take eleven courses (including an introductory course on random topics that emphasizes writing skills) from the 'Hums' before they can graduate, regardless of their major.
It's my conclusion, from experience, observations, and a lot of thought on the topic, that this is a good approach. It forces highly-intelligent technical people to spend significant time ourside of their comfort zone, which in itself is a valuable experience. What's more, because so many of these highly-intelligent technical people are able to follow Hum topics that actually interest them (you are required to choose an area of concentration for at least four of your eleven course), there's a lot of critical thinking going on between the students and Hum professors. This prevents the latter group from being too fring-idealogical (you know what I'm talking about--the avowed communist economics teacher who tells engineers that it is immoral for them to make a profit from their work, for one arbitrary example); professors actually have to stay on their toes, and some of them even enjoy dropping marginal / controversial / partisan topics into their courses every know and then just to watch the students react and critically tear it apart. Lots of fun discussions occurs.
That having been said, TFA is completely the wrong approach. This idea of 'science-vs-non-science' is absurd, but even worse than the condescending elitism shown by the scientific side of the discussion is when you find gentlemen like this author, who somehow manage to convince themselves that they are the Secret Guardians of the Superior Non-Rational Secrets to the Universe, which mere reason (and scientists who use it) can never hope to comprehend. (Don't tell me you haven't meet anyone like this--there are at least four in every Coffee Bean at any given point in time, reading their latest Jenny McCarthy blog post and trying to pass head shots off to anyone who looks like an acting agent.) This isn't skepticism (which is a profoundly scientific trait, by the way, despite what TFA tries to advocate); this is blind contrarianism with a dash of well-read, modern pseudo-intellectualist voodoo.
Not just a model (no one would make a high-performance plane with that amount of composites--any failure mode worth considering would be catastrophic to anyone within 100s of meters)... It's the nation-level equivalent of a 3rd grader drawing pictures of giant robots shooting flame from their eyes and terrorizing Tokyo. That particular design couldn't fly above 0.15 Mach without an incredibly sophisticated suite of controls--the forward canards are far too big and the plane itself is inherently unstable--far beyond the capabilities of any nation but the U.S. and Russia. You also won't be able to generate enough lift with that small of wing area unless you are traveling far too fast (boundary layer will separate by the second airfoil) and with an engine that, again, is far beyond the efficiency and miniaturization capabilities of Iran's industrial and scientific base. An enumerated on this page, there are hundreds of other reasons to laugh--which is really what this is all about; Iran technological developments are to aerospace nerds what Joe Biden's quotations are to the political analyst community.
Social changes are hard and difficult to enforce--the most reliable way is to thoroughly screen who you hire and, reciprocally, who you work for, both of which are moot points for situations like this. Therefore, I am going to enumerate three easy steps, albeit brute-force, that should help change the way you and your engineers work and think. Devious, yes--but wait on your judgement until you've read through the list, they're not all that bad.
I'm assuming, of course, that you haven't already done these things. If you have, there are many ways to take it to the next level: start using Bugzilla (or a similar tool) to track bugs and features; organize your documentation into User Guides, ICDs, and ADDs; define a small but standardized set of processes for complex challenges; etc. You get the idea--incremental is good, as you can't simply dictate, from top down, the behavior and practices of your engineers (unless... are you on a management track?). Of course, if you're in a CMMI-4 organization in which each person has their own HG clone of the primary code base, with your own QA and support staff, these are hopefully already in your rear-view mirror.
One additional practice I would recommend is periodic release cycles--that is, release a major version every year, minor every month (or some variation thereof), and include in each release only the features and updates that are ready. If you can get to a point where your schedule and release cycle is no longer at the mercy of your requirement creep problems or an almost-done set of patches, you will find the atmosphere becomes much more productive and stress-free; quality will skyrocket as a result.
Last but not least... I'm sure there will be many fine suggestions from knowledgeable slashdotters on this page. Pick and choose the ones you think will work (feel free to ignore all of mine, except this one) for your team / company / project--and when you sit down to implement them, don't expect to get away with 100% of your changes. Do what you can, what you are allowed, and what keeps you productive. Too many idealistic junior managers or engineers-turning-managers try to bring their 'brilliant ideas' into an environment where they simply don't work, and the lack of pragmatism leads to total failure of all of their efforts, when they could have gotten away with 60% (which is better than 0%). Throw in the vast world of methodologies, process monkeys, and paradigm acolytes, and you'll see why it's worth being cautious and flexible.
As a long-time contributor to Wikitravel, I'm very glad to see Wikivoyage managed by Wikimedia. Internet Brands, the organization that took over Wikitravel some time ago, has been turning their site into a classic example of ham-handed monetization; compare intrusive travel booking banners and horrendously limited search to their respective alternatives. For a while, they were even several versions behind the MediaWiki platform itself. I abandoned contributing to Wikitravel last year, and I'm very happy to have a new place to which I can contribute content. More importantly, I suspect I'm not the only one.
It seems like a lot of contributors here are missing the point. Discussions like this--and particularly the analysis that provokes them, regardless of how perfect it may be--are highly valuable and productive, for the same reason as project post-mortems. Too often, debates about development (where it's styling, methodologies, or rules of thumb) are done before coding begins, and as a result, several things invariably happen:
This, of course, is a reflection of the principle that a good engineer learns from his mistakes, while a great engineer learns from other people's mistakes. Both pictures and hindsight are worth a thousand pre-emptive, ill-informed words. I'm particularly pleased with the focus on coding quality, which (in post-mortems and hindsight analysis like this) takes second place to project and management practices. I will take, and have learned infinitely more from, 10 /.-ers debating an informed and evidence-based review of a quality codebase over 1000s of discussions about programming theory, the latest development paradigm fad, or some wannabe game designer's blog post.
You missed the part where he said it was a deliberate feature of the Prod build:
A program that doesn’t run uses a lot less CPU.
Not to say it wouldn't be impressive, but you clearly have to define your conditions for success. I'll bet both sides will (in fact, effectively have already) released conclusions in hindsight claiming victory--Anon. for executing so many attacks, with visible successes here and there, and Israel for not really loosing anything critical and demonstrating a well-designed and operated CSec environment.
Sort of like a 5th-grade bully pissing on a main battle tank. 'Success' might mean the tank got wet, but it's not like you're going to slow it down.
...when you forget to put the correct cover on your TPS report.
So nice to read a decent post about the original topic and not another who-to-blame-in-the-middle-east piece. Let's discuss.
I can count the number of serious players in large-scale cyberwar on one hand. Anonymous isn't one of them--and Israel is. Defacing websites and conducting DDoS is something you do to make a point--not make a difference in full-scale military conflict or subversive operations.
One of the things I am most amused by is the explicit reference to Israel's threat to cut off Palestinian internet access as the trigger for their actions. The death of multitudes of innocents on both sides isn't enough reason to take action, but if a Palestinian can't check his email, it's war! That, combined with the stance they took and the targets they are choosing, is a pretty clear indicator of their scope and level of maturity.
I would add one more interesting note worthy of a Slashdot post: In the constant P.R. war that is the Israel-vs.-Palestine conflict, Israel has converted their live blog of events into some sort of a web-based achievement game. They're getting a lot of flack, and it's fair to say it lacks taste, but to me it seems more of a P.R. failure and less an indication of eeeevil. Don't think I'll be trying to grind my Level 11 IDF Rifleman any time soon.
Computer science is a branch of mathematics; software engineering is a collection of methods for applying that math in the "real world."
Close, but I would add the following:
This is actually different from the developer-vs.-software-engineer discussion the other week--'developer' is a generic term for anyone who can write code. It can therefore also be a nearly-derogative term to people who write code but are neither computer scientists nor software engineers--for example, a computer scientist or software engineer might call someone a developer if they can write a web page or script a game, but aren't familiar with the underlying architecture of the server or engine they're using.
There are some very interesting studies regarding the links between meat consumption, testosterone levels, and related impacts. Most point to zinc shortages in one's diet, and the corrected testosterone levels incurred when said shortages are addressed by increased meat consumption. Not to say, especially as I happen to be a male, that increased testosterone levels will guarantee lying, cheating, and stealing. There does, however, seem to be a (single-sample-point, empirically-backed, possibly-placebo) link between consumption of multiple medium-cooked 2/3-lb burgers from The Counter and one's libido over subsequent days. (Not to spam a business link, but it's by far the tastiest way to get a testosterone boost I know of.)
I'm surprised a government-funded project would qualify at all. I mean, NASA's landed rovers on Mars--do we really doubt national governments' abilities to put something similar on the moon? I was under the impression that the whole point was to encourage privately-driven efforts. After all, if government-funded rovers were eligible, the USSR would have won with Luna 17 / Lunakhod 1--42 years ago.
TV is, strangely, one of those things that's begging to be reinvented in a way that integrates all of the great potential of internet + TV + consoles + disc players + multi-channel / caching devices, etc. Typically we'd look to Apple to show everyone how a problem like this really should be solved, but I think we all know how well that's gone. Speaking for myself, I will continue to simply plug in my laptop to my flatscreen's HDMI port and not bother with silly things like cable or satellite subscriptions. Until you can give me a way, for example, to watch HBO (and not Lifetime, or MSNBC, or any of the other 500 channels I'd never touch with a 31.5-foot pole) without paying hundreds of dollars a month for the Super Platinum Ultra cable package, the value just isn't there. A handful of networked (and some cable) shows are already doing this on Hulu, but the push for Hulu Plus subscriptions (and accompanying limitations on free Hulu) is really starting to get annoying.
In the long run, I think Google's approach is the one that time will show to be the winner. They're constantly looking for ways to extend search for better monetization (and after all the hammer thinks everything is a nail), but I think that's going to be the sustainable market path that can eventually take us to a day when I can--for example--pay a $10 subscription fee to watch real-time releases of Game of Thrones in the same way I can pay a modest fee for privileged access to my favorite Twitch channels. When the monetization comes full circle, and starts feeding back into investment and production of shows, it will produce a much tighter feedback loop and much better programming, much the same way cable did when it originally had its heyday so many years ago.
Because, if you (as the government) insist on getting your money back for a program you cancel after overruns and delays, you get unending lawsuits and are stuck in litigation for several decades. There's a better way to do things, to be sure, but payment on delivery (or from another perspective, 100% refunds) are out of the question for cases in which much of the cost has been sunk into hundreds of man-months of up-front professional (engineers, developers) labor or even purely scientific research.
Major projects in software and aerospace, especially when boundaries are being pushed (frequently, though not always, the case in aerospace--less so in ERP), can require a lot of up-front investment before a single product roles off the line. The B-2, for example, has a flyaway cost of $555M, but the total program cost $44B. We call it NRE--non-recoverable expenditure--and if there were absolutely no guarantees regardless of outcome, boundaries would never be pushed by interested parties of a certain size (i.e., DoD / enterprise software corporations / aerospace companies) because such entities are, by their, nature, VERY risk-averse.
Perfect application of Hanlon's Razor: Not so much a conspiracy to waste money as the worst combination of both world (defense acquisition and enterprise software development). Both fields are very prone to overruns, scope creep, and repeated waste of funds as manager after manager--or contractor after contractor--throws away work to start over again. Another great example is the FAA's version of enterprise software, which is currently at $63.4 BILLION and counting (though, to be fair, it's quite possible the most complicated software project in the world).
Still, there are worse examples--specifically, when these kinds of overruns, violations, and program restarts are done deliberately to ensure continued funding to entrenched players in a limited field and / or to pursue minor permutations on someone's pet dream of a project. This can occur at the cost of throwing away many years and billions of dollars of decent work while never really getting closer to a functioning system. Space Launch System, anyone? (Not a software example, but the line between software and aerospace engineering is a lot thinner than most people realize.)
Permit me to interject a perspective into my favorite bastion of anarchical Democrats. Read or ignore at your own prerogative.
First and foremost (that is, most relevant to the OP) is the following observation: If any state has a chance of seceding, and doing so successfully in a way that leads to a growing and stable nation-state, it is Texas. The reasons are too many to list here--suffice it to say, there is precedence, will, and ability. (If you doubt it, consider the following: You are POTUS, and Texas secedes. You lose the Marine Corps. Immediately. In a closely-related event, 12 hours later you will also lose the capitol, Norfolk, and New York.)
Second, schisms embodied by secession movements highlighted here do not strictly adhere to red-vs-blue state correlations. (Note, for example, that Oregon, New York, and New Jersey are also on the list.) Instead, movements like these are built around a perception that the governing body does not represent the best interests of a subset of their constituents--sometimes even a perception that they are actively working to their detriment. In many red states, this is realized in the perception that the federal government ignores, if not mocks and holds in contempt, those states, their residents, and their values. In the three aforementioned blue states, there is a sizeable portion (as measured by population or geography) that is soundly overruled by a larger subset (or a subset with stronger influence over state policy).
I can speak from experience that non-Willamette Oregonians feel like they are ruled by those who live in the 'Valley'--Portland, Salem, Eugene, and surrounding burbs. Tax money flows from industries outside of the regions into one or two metropolitcan areas to build local light-rail projects, subsidize regional interests, and fund other policies exclusive to those areas. This is a major driver behind the movement to create a state of Jefferson, consisting of southern Oregon and northern California (residents of the latter face similar problems with their state government in Sacramento and the population centers of the Bay Area & southern California). I suspect there are similar sentiments in upstate New York and mid/southern New Jersey (i.e., urban and commuting populations effectively nullifying the idealogies of their rural and local counterparts).
Lastly, it's worth pointing out the nature of the ongoing discussions (some would say civil war) within the Republican party. One major driving factor that is often downplayed (if noticed at all) is the degree to which ideology drives conservative politics--much more so than counterpart mechanisms on the left, which are typically more issue- and demographically-oriented. Here's an example, in which I attempt to list some of the major factions in the ongoing discussions: