Adding to your list of options that still require _some_ downtime: we used Bucardo [0] in lieu of logical replication. It was a bit of a pain, since Bucardo has some rough edges, but we made it work. Database was ~2 TiB.
Just guessing at the parent's intent, but the specification of a function can be decoupled from the production of an optimized implementation of that function, especially if the structure of the function is constrained in some way.
This approach is used to some degree in producing, for example, optimized BLAS implementations and other similar routines:
Of course, you do then need to juggle multiple languages. Different languages can be better at expressing different things, though (e.g., "what the function does" versus "how the function does it"), so it's not inherently crazy.
Furthermore, any security system that effectively relies on the user possessing more than one computing device (e.g., using your laptop for access to a password manager or email address) fails for the significant and increasing swath of humanity for which their phone is their [first and] only such device.
> At Volume Pricing 8 Bit PICs are pretty much incomparable to ARMs. A quick check on Digikey shows that for 10000 pieces, the cheapest 8 Bit Micro is a PIC10 - 35Cents/Unit (that's for today only)... The cheapest ARM Cortex M3/M0 or even a ARM7 is $1+.
I don't think that statement reflects the situation today.
Cost differences at the low end have become increasingly narrow, where they are present at all. Using just Digikey pricing at 10k, as above, it's easy to find M0/M0+ parts in the range of $0.40--$0.50/ea at 10k.
> The smallest 8 Bit micros from Atmel or Microchip or any 8051 is around 3x3mm. Most ARM micros are much larger.
These parts are obviously available in a range of package sizes, but the smallest M0+ MCUs are also 3x3mm.
If you live on the peninsula and care about these issues:
(1) Look at getting involved in a local group advocating a vision beyond car-centric suburbia. Palo Alto Forward is one example.
(2) At the very least, vote in the local elections, especially (and carefully) for the city council positions!
The future of the Bay Area is ultimately in the hands of town governments, not Google, and the only way to genuinely improve it is for residents to get politically involved who have a different and positive vision of the region's future.
Yeah, Knockout has also served us well: has been flexible as our architecture has shifted, and has progressed steadily without forcing us to pay a "framework churn" tax. It's become a mature, stable, pragmatic option, IMO.
Reliable network interaction on mobile is enormously difficult if you are trying to deploy code globally: each MNO mangles your packets in its own special way. Good to see tools like this, wish there were more, but the other half of the picture is empirical data on how particular pathological networks behave (I don't mean "EDGE", I mean "EDGE in poor coverage on MTN in Afghanistan"). Haven't found any real information, even in general terms, along these lines. Pointers welcome.
This area would be a great place for someone like Internet.org to add value, and they've announced some related work, but nothing seems real yet.
Even if your belief were true, it is an odd definition of a "flourish" that assigns all weight to the material dimensions of a society and none to the moral.
It becomes particularly odd when discussing the leadership of an organization with a substantial moral component to its stated mission [1].
Not to support the "evil executives" hypothesis---obvious market(ing) forces are a sufficient explanation for the dominance of LiCoO2---but I would easily opt for a laptop that offered an LiFePO4 ("iron phosphate" [0]) option. The drawback would be slightly reduced initial capacity; the advantage would be much greater cycle life. Also, less spontaneous combustion.
Even if you disagree with him (and to some extent I do), Brin was quite prescient on this topic. _The Transparent Society_ [1] anticipated most of this debate, 15 years ago, and it is well worth [re-]reading.
Oh, yeah, it's weird but not even a serious limitation: it's being fixed, other statsd clones have more features, and you can always pretend your data are time intervals. statsd is limited but nicely simple.
> If you never want your data downsampled, keep data at a single resolution...
Sure, and many people do exactly that. The point is that a new user to graphite is likely to be surprised by this behavior. (I would further bet that a reasonable fraction of statsd+graphite users end up viewing incorrect data without realizing it, especially given the statsd focus on count data, for which the default aggregationMethod setting is exactly the wrong choice.)
(And even awareness of this behavior isn't quite enough, since every user needs to also remember their server's exact storage configuration, lest they inadvertently expand their plot across a retention boundary.)
> How would you expect the presentation layer to present n data points using n pixels?
The same way that most plotting tools do so: by overdrawing. Yes, one ends up with a solid block of pixels if the data are noisy and the plot is small, but that outcome is easily understood and has the easily understood solution of explicitly aggregating appropriately. Graphite instead takes the approach of implicitly aggregating based on how wide the plot is rendered in a given interface. That behavior is, at the very least, surprising.