HN user

another

1,739 karma
Posts233
Comments45
View on HN
www.centauri-dreams.org 2y ago

Reflections on Breakthrough Starshot

another
2pts0
computationalculture.net 2y ago

Computational Culture: a journal of software studies

another
2pts0
www.semianalysis.com 3y ago

AMD AI Software Solved – MI300X Pricing, Perf, PyTorch, FlashAttention, Triton

another
60pts23
www.niche-museums.com 3y ago

Misalignment Museum

another
141pts59
github.com 3y ago

The Diff Challenge

another
29pts3
www.nasa.gov 3y ago

Lunar Crater Radio Telescope

another
2pts1
www.infoq.com 3y ago

The Wonders of Postgres Logical Decoding Messages

another
2pts0
energyathaas.wordpress.com 3y ago

California’s Duck-Belly Blues

another
1pts0
www.tor.com 3y ago

The Age of Sail: Nautical Fiction and the Origins of Space Opera

another
4pts0
www.nasa.gov 3y ago

NASA Selects Experimental Space Technology Concepts for Initial Study

another
1pts0
www.eaa.org 3y ago

Tips for Flying in to AirVenture

another
2pts0
www.python.org 3y ago

A Python Quick Reference (1994)

another
2pts0
hackaday.com 3y ago

All About USB-C: Framework Laptop

another
4pts0
www.youtube.com 3y ago

Are R/C Ground Effect Vehicles Even Real?

another
1pts0
www.bunniestudios.com 3y ago

Non-Destructive Silicon Imaging

another
10pts0
www.armscontrolwonk.com 3y ago

Detecting Missile Launches with Ionospheric Disturbances

another
1pts0
www.eia.gov 3y ago

U.S. battery storage capacity to increase significantly

another
38pts48
steveblank.com 3y ago

Why The Pentagon Can’t Count: It’s Time to Reinvent the Audit

another
2pts1
blog.computationalcomplexity.org 3y ago

Would you be more productive if you didn't log on? Worked for Christopher Havens

another
1pts0
www.lastweekinaws.com 3y ago

AWS’ Infinite Service Launches and Counterproductive Culture

another
4pts0
www.mining.com 3y ago

UN at COP26: “Enough of mining we are digging our own graves”

another
2pts1
blog.computationalcomplexity.org 3y ago

The Structure of Data and Machine Learning

another
1pts0
gcaptain.com 3y ago

US Shipyards – Record Revenue, Firesale Valuations

another
3pts0
deepgeothermalheat.engineering.cornell.edu 3y ago

Deep Geothermal Heat Research at Cornell University

another
4pts0
link.springer.com 3y ago

A Billion SMT Queries a Day

another
1pts0
constructionphysics.substack.com 4y ago

The Ups and Downs of Automated Code Checking Software

another
2pts1
constructionphysics.substack.com 4y ago

Interview with Alice Leung, VP at Brick and Mortar Ventures

another
1pts0
twitter.com 4y ago

Smart home company Insteon apparently shut down its servers

another
2pts0
phys.org 4y ago

California's first lab-grown mosquitoes may take flight

another
2pts0
fivethirtyeight.com 4y ago

How the NBA Uses Its Data on Referees

another
4pts0
PostgreSQL 14 5 years ago

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/

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.

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.

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.

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.

In addition to this helpful guide, note that statsd / graphite both spring some unfortunate surprises on new users, e.g., graphite changing your data across retention rates and time scales [0], graphite changing your data at different plot widths (?!) [1], statsd believing that only count and time data deserve to be aggregated [2], etc.

I have no alternative to suggest, however. Perhaps Cube [3], but unclear if it has any user community.

[0] http://stackoverflow.com/questions/10820119/graphite-is-not-... [1] http://graphite.readthedocs.org/en/1.0/functions.html#graphi... [2] https://github.com/etsy/statsd/issues/98 [3] https://github.com/square/cube

If we define "general purpose" as "equally mediocre in all domains", then what you say makes sense.

If we define "general purpose" as "works well in as many domains as possible", then I'd argue that the correct response to an easily-remedied weakness in an important domain should be to address that weakness.

As you imply, the challenge here is to decide which requests to grant and which to deny, but the mere fact that a request is "domain-specific" (ignoring, for the moment, the questionable idea that _linear algebra_ is domain-specific) should not be enough to rule it out.

(As an aside, scientific / numeric Python is, I believe, one of its two or three most important application areas, and perhaps the most important historical factor in its success: that community has been championing Python since the days when people were using Perl for the web, or for anything else. Notice, for example, that Travis mentions working on SciPy in 1999---and the original "Numeric" package was written in 1995.)

To provide additional context (the NYT article is fine, but doesn't give a sense of the technical issues with the study, or of how difficult/impossible it was to bring attention to those issues; the behavior of Duke seems particularly scandalous)...

If you have a few minutes, Baggerly's talk---on the "forensic bioinformatics" undertaken to pinpoint the study's flaws---is fascinating:

http://videolectures.net/cancerbioinformatics2010_baggerly_i...

The associated paper:

http://arxiv.org/abs/1010.1092

Recent small steps toward preventing similar problems in the future:

https://groups.google.com/d/topic/reproducible-research/UipZ...

Exactly. I'd go further: in industry, the software is typically the end product, and the quality of the software is inherently relevant. In science, the output (the prediction of the simulation, the result of the analysis, etc.) is typically the end product, and the quality of the software is relevant only insofar as it affects the quality of the output.

In practice, of course, the quality of the software often does affect the quality of the output---but time spent on software quality creates less immediate value than it does in industry.