If you're using Linux (especially with Gnome), I can highly recommend Pods[1] as a desktop client for Podman. It's much less cluttered than Podman Desktop, but still supports most of its features.

[1] https://github.com/marhkb/pods#readme

Only for their managed solution at the moment.

I got similar improvements when porting hashicorp/golang-lru[1]

  name         old time/op    new time/op    delta
  2Q_Rand-16     1.22µs ±10%    0.52µs ± 8%   -57.69%  (p=0.000 n=20+19)
  2Q_Freq-16     1.03µs ±10%    0.44µs ±12%   -57.42%  (p=0.000 n=18+20)
  ARC_Rand-16    1.51µs ± 9%    0.70µs ±15%   -53.63%  (p=0.000 n=20+20)
  ARC_Freq-16    1.22µs ±12%    0.54µs ± 7%   -56.20%  (p=0.000 n=20+20)
  LRU_Rand-16     401ns ± 9%     215ns ± 6%   -46.46%  (p=0.000 n=20+20)
  LRU_Freq-16     376ns ±13%     194ns ± 7%   -48.51%  (p=0.000 n=19+20)

[1]: https://github.com/hashicorp/golang-lru/pull/111

Storage space is cheap

While fwupd does have a windows client, the obvious mechanism to use would be windows update, but anything is better than custom software for each vendor.

The patched version is in testing https://src.fedoraproject.org/rpms/git

For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.

I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?

IMO using Optional type means the inner value must be not null. And if it's Some(null), it should mean exactly same as None.

distinguishing `Some(null)` and `None` is often considered a feature of Optional ;)

to use a tired example: when getting a value out of a map via some `myMap.get(key)`, you may want to distinguish "not present" = `None` and "present, with value null" = `Some(null)`

the right solution is to just not have nulls in the first place, then there's no problem ;)

It's trivial to store a null pointer in an Option::Some().

  struct Foo;
  
  fn main() {
      let option_with_null: Option<*const Foo> = Some(std::ptr::null());
  
      dbg!(option_with_null);
      dbg!(option_with_null.is_none());
  }

Output:

  [src/main.rs:6] option_with_null = Some(
      0x0000000000000000,
  )
  [src/main.rs:7] option_with_null.is_none() = false

https://play.rust-lang.org/?version=stable&mode=debug&editio...

As the creator of the function, you should try to adhere to the conventions and not try to break them.

I don't disagree, but:

> Some(null) is not a valid result.

It is a valid result. Null pointer and Option::None are still different things, is all.

It's currently impossible to write alert rules for Prometheus vectors. https://github.com/grafana/grafana/issues/35663

Missing basic functionality like that is a dealbreaker.

Hoping to see cleaner ways to integrate across data sources, but developing that contract is going to take some time I think. In the meantime, should be able to get this supported with prometheus data source in a Grafana managed alert: https://github.com/grafana/grafana/pull/44865

x Nanometer or y Ångström isn't based on physical size anymore and is just a marketing term.

From the article:

>A lot of the industry, for whatever reason, hasn’t learned that these numbers aren’t actually a physical measurement. They used to be, but when we moved from 2D planar transistors to 3D FinFET transistors, the numbers became nothing more than a marketing tool.

> Intel 20A: Previously known as Intel 5nm. Moving to double digit naming, with the A standing for Ångström, or 10A is equal to 1nm

Was going to say wtf.. I could be half asleep but the numbers don't add up. 20a == 5nm != 10a == 1nm

> ... is just a marketing term.

Who are they trying to fool?

Terms like nanometer and Angstrom obviously don't mean much to average consumers, so these are not the target.

But engineers rightfully call bullshit on the use of these terms.

So who are they targeting with this?