Hacker Newsnew | past | comments | ask | show | jobs | submit | another's commentslogin

see also: https://www.youtube.com/watch?v=MDYkL0krPmw (NASA NIAC Symposium 2022)


David Roberts and Canary have some worthwhile articles on this question

https://www.canarymedia.com/minerals-and-clean-energy-a-seri...

looking at lithium along with other relevant minerals.


We faced this migration, too. My sympathies.

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.

[0] https://bucardo.org/


> Additionally, Trader Joes ONLY sells white-labelled products, so it is even less applicable...

Their mix is heavily skewed toward private-label products, but "ONLY" is not accurate.

To pick one example: they sell name-brand beer alongside their private labels.


Fair enough. They also don't slap a Trader Joes marque on the produce they resell.


I would add Peter Watts.

We shouldn't restrict this club to authors that provide citations, but he does satisfy that criterion as well.


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:

http://view.eecs.berkeley.edu/wiki/Autotuners

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.


Could you please provide links [to DigiKey]?


Digikey has a pretty good web site for search, start with ARM M0+ and then select for what you want. I picked the 3x3MM QFN package as a selector and got a number of Kinesis parts, here is one that in 100 unit quantities is .50 each. In 10K I'm sure that is under 40 cents. http://www.digikey.com/product-detail/en/MKL03Z8VFG4/MKL03Z8...

This particular part 8K flash and 2K RAM. Now the M0+ is better for these low end parts because it has the Thumb instruction set which gives it better code density than the original M0


Thank you, will do :)


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: