I have the same question. Both Android and iOS have privacy indicators [1]. I'm still unclear as to whether the claim being made here is
1. that CMG active listening can bypass these indicators (concerning), or
2. that Google Home/Siri/Alexa recording data can be sold to 3rd parties.
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].
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.
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 used it once at work for a niche usecase. It’s main use case seems to be making it easier to simplify platform-specific code when you remove support from old platforms in legacy codebases.
2) All other use-cases that are not directly related to #1.
In other words, if you're a future language designer and you design a macro system for your language, you might wish to distinguish between configuration/platform/build related macros -- and other macros not directly related to build and configuration...
Doing that would allow one set and/or the other set to be selectively and easily evaluated back into the non-macro source of the base language -- depending on what is desired by the language user...
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_... )
I have a nit with this concept being called "dumb" code. I see that term is an ironic rebuttal to clever code. However, calling it dumb is misleading.
Readability, composability and elegance in programming are always a reaction to trauma caused by the shortcomings of some previous system. Therefore I think it is not possible to teach new programmers to write it.
I think this trauma is the most fundamental force in organizational coding standards as well as programming language design.
https://m.youtube.com/watch?v=0s5Du7qrPoM
https://www.obrist.at/powertrain/components/