codys

Other CMSIS-DAP compatible probes:

- https://makerdiary.com/products/pitaya-link

- https://www.l-tek.com/web-shop/cmsis-dap-debug-probe/

All of the jobs I've worked have not had any technical restrictions on what software engineers could install on their work laptops.

Most (but not all) had some sort of asset management tool and/or antivirus as standard on computers, but nearly all provided exceptions to having that functional/installed.

I, and I expect many developers, likely select companies with IT policies that avoid potentially harming individual productivity.

They use a custom plug system that doesn't use the standard brick shape as contacts.

https://www.lego.com/en-us/themes/powered-up shows some examples of the connector and socket.

There's also the discontinued "Powered Functions" connection scheme, which can be seen on this model: https://www.lego.com/en-us/product/power-functions-motor-set... . It appears to be post-brick contacts and pre-"powered up" connectors.

There have been many electrical connection schemes over the course of lego's history.

That's a great point, and shows up in annoying ways in Sony's camera line up in whether "high frame rate" support exists. For Sony cameras, HFR implies "can capture a limited length (seconds, typically) of footage at a higher frame rate (240fps, 480fps, 960fps, etc) and reduced resolution as frame rate increases (this is not the same as normal video modes and S&Q video modes, which don't have time limits like these).

Sony includes this feature on cameras without interchangeable lenses (ie: "point and shoots"), and on their high end cinema cameras, but not on their mirrorless (interchangeable lens, but not considered cinema cameras) line.

Seems pretty clear this is designed to avoid their mirrorless lineup have a feature that might make it competitive with their cinema line. But they're ok including it on the point and shoot line because that already is well differentiated from the cinema camera line.

Camera software is an area that is frustratingly closed off, and where manufacturers regularly differentiate new/more expensive cameras with firmware differences: subject detection, auto focus, drive modes (pre-capture, higher frame rates, etc), file format support (HEIC, compressed raw, colorspaces), ui features (how custom modes work, menu systems, etc).

Competition in this space driven by a provider that doesn't have a motive to convince users to buy the next new camera (ie: open source software) would be very useful to users.

Sony and Panasonic cameras (and perhaps other manufacturers) are running Linux (and release some of the third party source code they include in their products, but the amount of reverse engineering that has been done on those camera's software.

Canon uses a custom RTOS (DryOS), and lots of work has been done to extend the existing Canon firmware to enhance its capabilities (Magic Lantern[1] and CHDK[2]), but as far as I know fully open software for these devices doesn't exist.

Camera capabilities these days are highly software dependent, and the functionality of dedicated cameras is held back by subpar software development practices and a lack of pressure to make things better.

1: https://magiclantern.fm/ 2: https://chdk.fandom.com/wiki/CHDK

The text states that the back is glass

There's a long history of open source software implementing patented algorithms, especially in the video and audio codec space. Those open source implementations are definitely used by professionals, so I would recommend not being so assured about the scope of use of software that may contain patented algorithms.

The vocal data on public safety channels being reported as encrypted does not necessarily say that there could be no vulnerability there. There's lots of control data that may or may not be encrypted, and encryption does not prevent all kinds of attacks here.

The FDA used to not be funded by the pharmaceutical industry, and instead be directly funded. There are routine questions about how the current arrangement influences FDA decision making in a way that negatively affects their ability to independently review drugs. IOW: the current setup causes the FDA to approve things they probably should not have approved, because they are incentivized to "get along" with the companies paying them.

Whoops: I missed a "not" in the last sentence. Should be:

> So in this case, the plastic straw issue does _not_ necessarily appear to be related to the redesign.

The article indicates the re-design in question was "launched" in January 2008. This is the date where planning the redesign began.

Another article [1] indicates that the new design was deployed on January 8th, 2009, and Tropicana announced a return to the old design on February 23rd, 2009.

A quick search shows an article [2] indicating around 2018 was when the panic around plastic straws began (with, for example, Seattle banning plastic straws starting in July 2018).

So in this case, the plastic straw issue does necessarily appear to be related to the redesign.

1: https://www.thebrandingjournal.com/2015/05/what-to-learn-fro...

2: https://www.eater.com/2018/7/12/17555880/plastic-straws-envi...

what tools/methods exist for MitM-ing iphone traffic in this case?

The lack of parallelization is also a pain point. When I needed something to test platform specific stuff and set defines/etc, I found that writing something to generate ninja & integrate the define generation (which ended up in some generated headers) into the total build process. This was very snappy.

These days I use meson mostly, but I would love to see a complete build system really get into parallelizing platform checking and merge it into the normal build process.

- a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186...

- A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/

I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.

I've found https://dancharblog.wordpress.com/2021/02/05/usb4-tb4-docks/ has a nice comparison of the many very similar (only slightly differentiated) thunderbolt 4 docks.

It notes that the Kingston, Sonnet, and others are rebrands of the Goodway DBD1100.

Field ids are not (necessarily, especially when doing localization) something shown in the UI. The point made by the original commenter is that a field in the error should refer directly to which field has an issue. It does, via an id that happens to be "email". It's still up to the clients to decide how to represent that to the user, but they're given a distinct field rather than needing to infer which field an error code refers to.

(While the comment I replied to can be read differently, I assume we all know that changing actual field names (in APIs) depending on localization is nuts)

To be clear, the linux approach doesn't need to "generate" functions: one can define the common operations as functions (and indeed, the linux kernel does this) that can be used for all list types.

The list operations themselves (iterating, adding list nodes, removing list nodes) are all type safe (and can be placed in normal functions), the piece that gets funky is only examining the element content (which uses `container_of`).

There's no reason to speculate on the origin of the the bsd and linux approaches here, and the speculation given is highly questionable.

The difference appears to be:

`sys/queue.h` has it's pointers to the next element rather than the next list_node, while `ccan` and `linux` have pointers to the next list_node, which then are adjusted if needed to obtain the containing element.

In practice, this means that `sys/queue.h` is entirely macros, while linux & ccan's lists can use normal functions for most operations (with primarily obtaining the element pointer being handled by macros). Whether or not this is useful is somewhat dependent on compile time costs for macros vs code, and how small the list operations are in code size (ie: are they always inlined, or is it useful to be able to have a single instance of them). With the linux model, this can be determined at any time (by the compiler, or by the linked list library by changing it a bit), with the bsd model it is somewhat more difficult to make work (one could possibly do this by passing in the offset of the list_node structure to functions).

For more advanced intrusive lists in C, I've found that ccan's tlist2 (https://github.com/rustyrussell/ccan/blob/master/ccan/tlist2...) provides a decent model here.

Compared to the linux kernel's intrusive lists, it also tracks the offset of the list_node within the structure contained by the list, which eliminates another class of problems. It does still have the "using the iterator after the for loop is over" issue discussed in this article, but it also already tracks the types as Linus proposed doing in the article to resolve the issue.

Not the OP, but I deployed btrfs on tens of embedded systems that had their power consistently cut on a daily basis. Ended up with unmountable filesystems repeatedly. Switched to ext4 and never had an unmountable filesystem again.

These were single disk systems, no raid at all.

That sounds a lot like a tying arrangement, which could be unlawful under US anti-trust laws.

This article mis-represents criticisms of Angewandte Chemie publishing Tomáš Hudlický's essay (opposing efforts to increase diversity in organic synthesis) by attributing them to a "Twitter firestorm" while other publications note this event caused members of Angewandte Chemie's international advisory board to resign in protest, and other Chemists criticized the essay [1].

There may be a way to thoughtfully discuss this issue, but this article is a poor attempt at it.

1: https://cen.acs.org/research-integrity/ethics/Essay-criticiz...

One can also get the commit from github itself.

Also, see https://news.ycombinator.com/item?id=29932282 for a newer hash.

    # clone the old repo noDRM/DeDRM_tools forked from
    git clone https://github.com/apprenticeharper/DeDRM_tools
    cd DeDRM_tools

    # fetch the commit hash archive.org tells us about:
    git fetch origin 8c819c71376ab76445dd79d5cf2b28b6c0c2819e
    git checkout -b noDRM FETCH_HEAD

Slack has made using their API much trickier over time: getting a token to post these days (officially) is under the control of the server admin (as one needs to add a "slack app" to get one). One can extract a token and some cookies from a web browser slack session still, but it's not as clean as it used to be (where one could just generate account associated tokens that didn't randomly expire).

In other words:

- to use the slack APIs, you probably need company level buy in _before_ any code is written against the API from IT folks

- in contrast, with IRC one could just try something out and at some point in the future _maybe_ create a seperate IRC account for it, if your IRC server even has logins enabled. If it doesn't, which when I worked for IBM was the case, one can just pick a new username for the IRC bot.

"Simple Jack panel, but computer controlled" is not novel and should not be patentable.

Alternately, there's this: https://news.ycombinator.com/item?id=28515306

Last I checked, ytdl when used standalone has poor behavior with live: it will fetch the live stream, but if ytdl gets up to "current time", it considers the live stream complete instead of continuing to capture it in real-time.

This may or may not affect using mpv's ytdl integration (where mpv internally calls ytdl to obtain a stream).

That adapter certainly looks like it is.

PS/2 may not be hotpluggable, but USB certainly is. Not clear what would have prevented unplugging/replugging the USB side of your PS/2 to USB converter.

That's with purchase sharing enabled. Otherwise, there is no shared billing for apps when using iCloud family.

If you only want a single field in json, you define a struct with just that single field. Serde does have the ability to return an error about unknown fields, but it is not enabled by default.

This also informs your second question. If new optional fields in json are added, unless you tell serde to complain about them, it won't, and you can add the new Option at your leisure.