HN user

DriftRegion

219 karma
Posts20
Comments61
View on HN
www.davidsmythe.org 4mo ago

Kola Superdeep Borehole

DriftRegion
2pts0
cdelker.bitbucket.io 6mo ago

Segmented Turning Designer

DriftRegion
1pts0
www.youtube.com 1y ago

The Journey of HyperPhysics [video]

DriftRegion
3pts0
www.youtube.com 2y ago

The Compiler Explorer Story – Matt Godbolt

DriftRegion
29pts5
www.youtube.com 2y ago

The Soviet Union's Deadly Abandoned Nuclear Generators [video]

DriftRegion
1pts0
thechinaproject.com 2y ago

The China Project Shutting Down

DriftRegion
4pts1
github.com 3y ago

Iso14229 0.5.0 Released

DriftRegion
1pts0
www.chinafile.com 3y ago

Message Control (2020)

DriftRegion
2pts0
en.wikipedia.org 3y ago

Classification of Locomotive Axle Arrangements

DriftRegion
1pts0
discourse.odriverobotics.com 3y ago

ODrive Goes Closed Source

DriftRegion
7pts4
semaphoreci.com 4y ago

Monorepo Culture

DriftRegion
1pts0
news.ycombinator.com 4y ago

Ask HN: Embedded Projects to Learn From?

DriftRegion
2pts0
www.youtube.com 4y ago

Android Phone as Bike Dashboard

DriftRegion
1pts0
blog.adacore.com 4y ago

Ada-Motorcontrol: Ada Brushless Motor Controller on STM32

DriftRegion
2pts0
mitxela.com 4y ago

Polar Coordinate Etch-a-Sketch

DriftRegion
2pts0
github.com 4y ago

Show HN: Unified Diagnostic Services (UDS) server and client in C

DriftRegion
1pts0
github.com 4y ago

Show HN: Mix Rust, C, and compilation targets with Bazel

DriftRegion
2pts0
fccchina.org 4y ago

Foreign Correspondents' Club of China: Report on Media Freedom in 2021

DriftRegion
3pts0
dash.harvard.edu 4y ago

Fear, Friction, and Flooding: Methods of Online Information Control [pdf]

DriftRegion
3pts0
tools.wmflabs.org 6y ago

Wikidata Visualization

DriftRegion
2pts0

Writing unit tests is futile exercise without a specification.

The software under test is always modeling something -- business logic, a communications protocol, a control algorithm, a standard, etc. Behind each of those things is a specification. If a specification doesn't exist then the software is called a prototype. For sustained long term incremental development a specification must exist.

The purpose of unit tests is to assert specification-defined invariants at the module interface level.

Unit tests are durable iff the specification they uphold is explicit and accessible to developers and the scope of the test is small. It's futile to write good tests for a module which has ambiguous utility.

priors: I worked in embedded SW and am now a PhD student.

I found the linked article to be difficult to follow. Vacliv Smil wrote a book called Energy and Civilization (2017) in which he argues that the ability to harness energy is what makes civilizations thrive and enables the production of culture.

Start with the question: what is the problem that you want to solve? Next, find codebases that solve that problem and study how they do it.

Good design is so deeply tied to the domain details. Wonham's Internal Model Principle applies to code.

Example: I wanted to solve the problem of unit testing for embedded targets. I found open source projects that do this and read the code critically to see how and why it is written. As I build my own approach, I revisit theirs to learn more as my understanding of the domain deepens.

This is a wonderfully concise description of why software testing, especially GUI testing is cursed by dimensionality.

Type checking, borrow checking, invariants, hell even MISRA rules are all constraints imposed to reduce unmanaged state in programs. I like them for software reliability because they can help keep the complexity demon locked in the crystal.

Anyone know more about the payload? Here's what I've found: It's carrying the "Blue Ring Pathfinder Payload", part of the "Dark-Sky 1 Mission"

Dark-Sky 1 is jointly funded by DIU and Blue Origin. [5]

DIU is "The Pentagon’s commercial technology arm, the Defense Innovation Unit"

[1] https://www.blueorigin.com/news/blue-ring-pathfinder-payload

[2] https://www.diu.mil/latest/companies-selected-for-diu-orbita...

[3] https://www.meritalk.com/articles/diu-orbital-logistics-awar...

[4] https://www.geekwire.com/2024/blue-origin-ring-darksky-1/

[5] https://spacenews.com/defense-innovation-unit-awards-three-c...

I've had a couple of experiences in the past month where I do respond to the enthusiastic sales engineer's check-in with a genuine product question, only to receive an immediate, lengthy, and subtly wrong LLM generated response. It feels gross.

By all appearances, it just seems like an absolute no brainer....I really dont get it

I understand the policy around hydrogen (Bipartisan Infrastructure Law allocated $8 billion to hydrogen production) as a technological pivot for the United States which leads the world in oil and gas extraction and logistics tech. The US has a lot of gas handling experience.

Optimistically, green hydrogen will diversify the energy supply, bringing "energy resilience", a key policy buzzphrase. Batteries and pumped hydro are undeniably superior in round trip efficiency, but hydrogen does have some desirable properties such as relative ease of overland transport, very long term storage, and being a chemical precursor for some industrial processes.

Pessimistically, green hydrogen is a way for oil and gas companies to siphon many taxpayer dollars while doing superficial work similar to the compliance EVs of the 90s and 00s.

I'm optimistic mainly because my PhD in electrical engineering is being funded partly with the green hydrogen taxpayer dollars. Shout-out to my fellow taxpayers and my advisor's grant writing skills! I'm working on power electronics which are fundamental in renewable energy and by extension green hydrogen electrolysis.

The article writes:

they had not asked me to explain git, they had asked me to explain GitHub

This is often the case for me as well.

Hey, at least git owns it by calling the shell commands "porcelain" (with git itself being the plumbing -- https://stackoverflow.com/questions/6976473/what-does-the-te... ).

The core value proposition of GitHub, GitLab, etc is to provide a nice GUI atop git. That's huge. I think that user-studies to improve one of the many existing foss git GUIs would be much better use of brain than deprecating git checkout.

Hydrogen electrolyzers perhaps makes sense as a backup load: something that can be turned on when there's too much electricity production (as is increasingly the case in renewable-heavy grids). But then what to do with the hydrogen?

Fertilizer? sure. Heating? maybe.

Cars? the infrastructure still has a long way to go. See https://www.reddit.com/r/Mirai/ for the deets.

Mecanum Wheel 2 years ago

The two uses of mecanum wheels are: 1. rolling on clean flat surfaces and 2. nerd-sniping.

What a fascinating read. Not the linked article but the actual proceedings:

see the docket: https://decisions.fct-cf.gc.ca/fc-cf/decisions/en/item/52504...

Which reads: Mr. Xu, a 43-year-old Chinese national, is inadmissible to Canada on security grounds pursuant to paragraphs 34(1)(a) and (f) of the Immigration and Refugee Protection Act, SC 2001, c 27 [IRPA].

Relevant Canadian Law: https://laws.justice.gc.ca/eng/acts/I-2.5/page-6.html#docCon...

    34 (1) A permanent resident or a foreign national is inadmissible on security grounds for
    (a) engaging in an act of espionage that is against Canada or that is contrary to Canada’s interests;
    (f) being a member of an organization that there are reasonable grounds to believe engages, has engaged or will engage in acts referred to in paragraph (a), (b), (b.1) or (c).
I am so not a lawyer, but the law seems to be written in present tense. Huajie Xu retired from the PLA in 2018 and came to Canada legally with a valid permanent resident visa in 2021. This case cites very similar one: Geng v. Canada (2023) in which the applicant was ultimately granted admission.

I agree that EFF calling it a "Ban" is not accurate. Like it or not that's what everyone seems to be calling it.

The linked 1965 SCOTUS ruling "Lamont v. Postmaster General, 381 U.S. 301" is fascinating: https://www.courtlistener.com/opinion/107064/lamont-v-postma...

The USPS detained this piece of communist propaganda ( https://www.marxists.org/subject/china/peking-review/1963/PR... ) addressed to the appellant who responded by suing them.

The USPS was acting in accordance with the following statute:

  When it is determined that a piece of mail is "communist political propaganda," the addressee is mailed a notice identifying the mail being detained and advising that it will be destroyed unless the addressee requests delivery by returning an attached reply card within 20 days.
The contentious thing was the reply card. It was ruled that the added friction of the reply card system infringed on first amendment rights.

IANALegal Scholar, but an outright ban seems to violate precedent. A forced sale however? I'll be watching this issue closely as it develops.

Figure 1 spoke to me. It's an expanded syntax tree that branches depending on on the value of a preprocessor definition "CONFIG...X". I've often found myself doing the kind of code archeology that this paper seems to be trying to automate: exploring all the configuration possibilities implied by the codebase / build system. A C program that makes heavy use of the preprocessor is generally harder to grok by both h humans and static analysis because 1. the C preprocessor syntax is different from C, 2. the inputs are not necessarily bounded by what appears in the source files alone ("-DCONFIG...X=foo" passed in from the build system), and 3. the resulting program and its control flow may be quite different depending on preprocessor options. As a simple example embedded systems often define an "ASSERT(X)" macro as either noop, an infinite loop, a print statement or the like.

This is definitely a niche space but I see clear use for large, portable and configurable c codebases (e.g. Linux kernel, FreeRTOS) for providing better visibility into the configuration system.

I think when bringing up embedded rust it is necessary to specify an application.

For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_... )