willglynn · HackerTrans

willglynn

no profile record

投稿

Unsoundness and accidental features in the [target_feature] attribute

predr.ag

3 ポイント投稿者 willglynn昨年0 コメント

コメント

3 か月前議論

Glorious: https://seri.tools/blog/announcing-rust9x/

6 か月前議論

AWS has the notion of "partitions", which is a technical boundary encompassing multiple regions. This mostly doesn't come up, but it does poke through in certain implementation details, like how AMI manifests for groups of regions (partitions) need to be encrypted for different public keys. Each partition has a specific region which must be targeted for certain partition-wide actions, such as managing IAM endpoints in other regions.

https://docs.aws.amazon.com/whitepapers/latest/aws-fault-iso...

Normal AWS (`aws`) traces to `us-east-1`. AWS GovCloud (US) (`aws-us-gov`) is distinct, based in `us-gov-west-1`. AWS in China (`aws-cn`) is distinct again, based in `cn-north-1`.

The AWS European Sovereign Cloud is implemented as a distinct partition – `aws-eusc` based in `eusc-de-east-1` – so it has exactly as much in common with normal AWS as AWS GovCloud (US) or AWS in China.

12 か月前議論

For example, "An HTTP Status Code to Report Legal Obstacles":

https://datatracker.ietf.org/doc/html/rfc7725

12 か月前議論

This was TAMDAR data, which is a self-contained instrument package intended specifically for meteorological observations.

https://en.wikipedia.org/wiki/TAMDAR

Observations definitely fell off a cliff as commercial air travel slowed to a crawl. In terms of impact, though… it turned out not to be a big deal.

> Aircraft reports suffered a 75% decline in numbers from mid-March to mid-April 2020; in May the number started increasing again. Despite the loss of data there is no clear signal in the forecast skill—partly because the skill shows considerable variability on daily, seasonal, and interannual timescales (Figures 3 and 4). …

> …

> Overall, we can find no evidence that the decrease in aircraft observations has handicapped numerical forecasts of extreme weather to an extent large enough to incur significant economic impact.

https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/202...

昨年議論

You might be interested in https://burn.dev, a Rust machine learning framework. It has CUDA and ROCm backends among others.

昨年議論

Yes! Exactly this.

My last EV used 22 MWh over 6.5 years. That works out to 390W.

My solar array is located at high latitudes (northern Minnesota), the mounting angle isn't great, it's occasionally covered in snow, etc. In these conditions, I need 6.3 solar panels to produce 22 MWh over 6.5 years.

The area used by 6.3 solar panels -- enough PV to cover _all_ my EV's energy needs -- works out to be a parking spot large enough to fit the vehicle but not large enough to fully open any of the doors.

昨年議論

I've had great results with N100 mini PCs including Power over Ethernet. Here's an N100, PoE, 2.5GBASE-T, case, 8 GB RAM, 128 GB SSD for $129 refurbished:

https://refurbished.minisforum.com/products/minisforum-s100-...

I have zero applications where a Pi5 makes more sense than either a mini PC or a large microcontroller.

昨年議論

This is not discretionary for the FCC:

> A station authorization shall be automatically terminated in whole or in part without further notice to the licensee upon:

> …

> (d) The failure to maintain 50 percent of the maximum number of NGSO space stations authorized for service following the 9-year milestone period as functional space stations in authorized orbits, which failure will result in the termination of authority for the space stations not in orbit as of the date of noncompliance, but allow for technically identical replacements.

https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B...

_Congress_ can change this, but as written, Federal law compels the FCC to automatically terminate the authorization for failing to deploy half the satellites under 47 CFR § 25.161(d), just as they must automatically terminate the authorization when the license expires under 47 CFR § 25.161(b).

昨年議論

ESPHome fills much of this niche for me. It's a framework for turning YAML device definitions into custom microcontroller firmware, with myriad supporting tools. The official device database at https://devices.esphome.io lists 554 devices but that's nowhere near the end of it.

Most manufacturers bolt on IOT functions by dropping an off-the-shelf module onto their device-specific board. It's sometimes possible to replace the factory firmware with ESPHome, sometimes even using over-the-air updates. For example, AirGradient air quality sensors: https://github.com/MallocArray/airgradient_esphome

Even when it isn't possible to commandeer the factory IOT module, the fact that it _is_ a module is still useful, because it's almost always possible to inhibit or remove the factory module and connect your own instead. The factory IOT module controls and senses the device, so your replacement module can too, using the same pins. For example, an IOT air filter: https://github.com/mill1000/esphome-winix-c545#final-assembl...

Some devices are designed around multidrop communication busses. These are usually even easier, since the ability to join the bus is an intended design feature, even if the device you're using is not intended. For example, many Samsung residential HVAC systems: https://github.com/omerfaruk-aran/esphome_samsung_hvac_bus/d...

昨年議論

On the topic of fail-deadly nukes:

https://en.wikipedia.org/wiki/Dead_Hand

2 年前議論

This is true for many but not all weather models.

GFS and IFS are both medium-range global models in the class Google is targeting. These models are spectral models, meaning they pivot the input spatial grid into the frequency domain, carry out weather computations in the frequency domain, and pivot back to provide output grids.

The intuition here is that, at global scale over many days, the primary dynamics are waves doing what waves do. Representing state in terms of waves reduces the accumulation of numerical errors. On the other hand, this only works on spheroids and it comes at the expense of greatly complicating local interactions, so the use of spectral methods for NWP is far from universal.

2 年前議論

You're right, and in fact S3 does this with the `ETag:` header… in the simple case.

S3 also supports more complicated cases where the entire object may not be visible to any single component while it is being written, and in those cases, `ETag:` works differently.

> * Objects created by the PUT Object, POST Object, or Copy operation, or through the AWS Management Console, and are encrypted by SSE-S3 or plaintext, have ETags that are an MD5 digest of their object data.

> * Objects created by the PUT Object, POST Object, or Copy operation, or through the AWS Management Console, and are encrypted by SSE-C or SSE-KMS, have ETags that are not an MD5 digest of their object data.

> * If an object is created by either the Multipart Upload or Part Copy operation, the ETag is not an MD5 digest, regardless of the method of encryption. If an object is larger than 16 MB, the AWS Management Console will upload or copy that object as a Multipart Upload, and therefore the ETag will not be an MD5 digest.

https://docs.aws.amazon.com/AmazonS3/latest/API/API_Object.h...

2 年前議論

It is common to use multipart uploads for large objects, since this both increases throughput and decreases latency. Individual part uploads can happen in parallel and complete in any sequence. There's no architectural requirement that an entire object pass through a single system on either S3's side or on the client's side.

2 年前議論

> In Rust, the main thread is special. (I consider this unfortunate, but web people like it, because inside browsers, the main thread is very special.) If the main thread exits, all the other threads are silently killed.

Rust inherits this from `pthread_detach()`:

       The detached attribute merely determines the behavior of the
       system when the thread terminates; it does not prevent the thread
       from being terminated if the process terminates using exit(3) (or
       equivalently, if the main thread returns).

2 年前議論

Global lat/long coordinates are defined in terms of coordinate systems like WGS84 or ITRF2020, which are themselves the result of relative measurements between reference stations.

The earth's crust floats on top of liquid rock. This matters at relevant length and time scales; in most places, these effects alone are on the order of millimeters per year. One reason why it's better to use NAD83 over WGS84 in North America is that NAD83 latitudes and longitudes move with the North American plate.

Positions _are_ relative, and the closer you can put your datum, the less drift you'll accumulate.

2 年前議論

The document to which this article refers was published in the Journal of the Royal Society Interface, and the article links there. It is also available as open access, which was not linked:

https://hal.science/hal-04287433v1

https://hal.science/hal-04287433/file/Version%20HALL.pdf

2 年前議論

It's… fine? Unlike certain other brands, I've encountered no network of frothing, territorial, gatekeeping dealers with Beckhoff. For my project, I reached out to [email protected], got a rep, asked for a quote, and went from there.

Secondhand can be viable too. Some of my "jellybean" EtherCAT terminals came from eBay. I won't get help from Beckhoff if they break, but given that I already have replacements on hand, I'm really not worried about it.

Beckhoff also lets you download almost all the development tools, runtimes, and PLC libraries without paying. In their words:

> Trial licenses can be generated in the TwinCAT 3 development environment (XAE) for many TwinCAT 3 functions for a validity period of 7 days. This can be repeated any number of times. An internet connection is not required for this. In this way, these TwinCAT functions can be used simply and cost-effectively in laboratory operations, e.g. in the education sector.

This is obviously useful for development and experimentation. It can also be an escape hatch in production if you need to substitute controllers. Beckhoff wants you to pay for what you use, sure, but their licensing scheme goes out of its way to avoid kicking you when you're down.

2 年前議論

Seconding Beckhoff. EtherCAT is a fantastic protocol, TwinCAT/BSD works great, reliability is excellent. It's super nice to run realtime PLC code on specific processor cores with µs of jitter while other cores run a normal OS with normal applications (e.g. VictoriaMetrics) on the controller itself.

I have a construction project involving several buildings with overlapping infrastructure. Everything gets connected to EtherCAT as quickly as possible. Electric generation: solar panels, batteries, inverters. Energy management: branch circuit monitoring, weather forecasts, solar forecasts, load control for things like EV charging and water heating. HVAC: heat pumps, buffer tanks, circulation pumps, valves. Building automation: lighting, access control. I just add I/O wherever, connect over Ethernet, and glue all the signals together in software.

I wouldn't dare approach a project like this with Arduino.

2 年前議論

Thirded. I connected my stations' local UDP broadcasts to Prometheus push/VictoriaMetrics:

https://github.com/willglynn/tempest_exporter

Their central web API is nice too (and the tool above can extract metrics from it) but the local, offline data access is what got me in the door. Tempest could shut down their services tomorrow without breaking my setup.

2 年前議論

The best treatment is at:

https://blog.rust-lang.org/2024/03/30/i128-layout-update.htm...

Note also that this involves LLVM, so clang < 18 had the same u128 behavior as Rust < 1.77/1.78.