Hacker Newsnew | past | comments | ask | show | jobs | submit | bdd's commentslogin

Works on this Postgres 17.7:

postgres=# show server_version; server_version ------------------------------- 17.7 (Debian 17.7-3.pgdg13+1) (1 row)

postgres=# SELECT sum(blks_hit)/nullif(sum(blks_hit+blks_read),0) AS cache_hit_ratio FROM Pg_stat_database; cache_hit_ratio ------------------------ 0.99448341937558994728 (1 row)



I don't think in this very case it has anything to do with digital rights management. It detects an Intel SATA SSD, SSDSCKJF360A5L a disk that supports ATA Trusted Send/Receive commands used to interface with on-disk encryption features. Specifically 5B to 5F (reference: https://wiki.osdev.org/ATA_Command_Matrix).

To make things even more confusing, kernel refers to the command between 5C and 5F with the acronym TPM, and requires `libata.allow_tpm=1` command line parameter to be passed to allow issuing them. (kernel source reference: https://github.com/torvalds/linux/blob/v6.12/drivers/ata/lib...), which has _nothing to do_ with the trusted platform module TPM, just another TLA clash.

Here's the original commit from 2008. The naming is very likely through misassociation. TCG: Trusted Computing Group is most known for creating TPM specification. Another thing they work on is the OPAL specification for self encrypting drives. Author possibly clumped them into the same thing. https://github.com/torvalds/linux/commit/ae8d4ee7ff429136c8b...


> I don't think in this very case it has anything to do with digital rights management.

From your kernel source link

> DVR type users will probably ship with this enabled for movie content management.

Indeed where the DRM error message comes from https://github.com/torvalds/linux/blob/ffd294d346d185b70e28b...

> CPRM may make this media unusable

CPRM?

> Content Protection for Recordable Media and Pre-Recorded Media (CPRM / CPPM) is a mechanism for restricting the copying, moving, and deletion of digital media on a host device, such as a personal computer, or other player. It is a form of digital rights management (DRM) developed by The 4C Entity, LLC (consisting of IBM, Intel, Matsushita and Toshiba).

How can we be sure which CPRM it is though? Ah the kernel maintainers actually had an argument about it at the time https://www.linuxjournal.com/article/5091 https://www.linuxjournal.com/article/5092


> Indeed where the DRM error message comes from https://github.com/torvalds/linux/blob/ffd294d346d185b70e28b...

That's for compact flash cards. Based on the kernel message from the StackExchange post we can tell it isn't a CF. So it's not coming from the line you linked, but 11 lines below.


I believe https://github.com/nixos/nixpkgs/pull/372196 fixes this if you are using systemd-networkd. It was merged to master last week and made it to unstable branches (https://nixpk.gs/pr-tracker.html?pr=372196).


If you want to read more about cryptographic key wear out, Soatok wrote an excellent explainer on this a few years ago https://soatok.blog/2020/12/24/cryptographic-wear-out-for-sy...


> if you want a non-Python runtime for some reason [...]

Magic Wormhole project has its own alternate implementation https://github.com/magic-wormhole/magic-wormhole.rs, which is also used by delightfully designed GNOME and Android apps; [Warp](https://apps.gnome.org/Warp/), and [Wormhole](https://play.google.com/store/apps/details?id=eu.heili.wormh...), respectively.


There's also a Haskell implementation (besides the Go one pointed out above). They all interoperate.


Thank you. What protocol are they using to interoperate?


The Haskell implementation uses the same protocol as the Python implementation. The main difference is that there are some features the Python implementation has that the Haskell implementation still lacks (most notable "Dilation").

See also https://github.com/magic-wormhole/magic-wormhole-protocols/


Yes. And that was 4 years ago. Must add that figure does NOT include static asset serving path.


> I'm not sure if KVM switching can be controlled over DDC but it's likely.

They do. Here's my shell function that helps me switch between DisplayPort-1 + USB uplink cable to the host AND USB-C cable with DisplayPort Alt Mode+Charging+uplink to display's USB hub.

  # x0f: DisplayPort-1
  # x1b: USB-C
  DDC_SOURCES=("x0f" "x1b")

  switchkvm() {
    local vcp_input_src="x60"
    local current next src
    current=$(ddcutil -t getvcp ${vcp_input_src} | awk '{ print $4 }')
    for src in "${DDC_SOURCES[@]}"; do
      if [[ ${src} != "${current}" ]]; then
        next=${src}
      fi
    done
  
    if [[ -z ${next} ]]; then
      echo "No eligible alternate input in \$DDC_SOURCES" >&2
      echo "\$DDC_SOURCES=(${DDC_SOURCES[*]}); current=${current}"
      return 1
    fi

    ddcutil setvcp "${vcp_input_src}" "${next}"
  }


Thanks for sharing that - its very useful to know that there is a way to do this, I just need to select the right hardware ..


Reflowing the controller worked for me twice for now. Once with an Intel Optane drive that worked without issues for 3 years and started overheating one day. And another one from a fanless machine that used an mSATA drive that chose to die on a Sunday, with no spare mSATA disk lying around. In both cases I went for short hunting under a microscope, looking for that one guilty shorted cap, yet finding none. It was the controllers with "tired" BGA solder balls, which could use some tender loving care of 225°C (soak) -> 400°C (peak) -> 325°C (hold) reflow.


That's quite aggressive. I typically reflow with peak 225C.

https://microchip.my.site.com/s/article/SAM-Cortex-M3-M4-M7-...


Dunno. This works for me without damaging the parts, pads, or traces. Your link is for PCBA reflow ovens. Talks about minutes long of exposure. I'm using a Atten ST-862D hot air station with questionable temperature and airflow accuracy. For an M.2 drive I'll probably soak 225 for 15 seconds 3 times the size of the chip areas in circles. Hit my memory-1 button to go to 400 and focus on the chip for 3 seconds. Hit memory-2 to go down to 300 and one up arrow for 325 for 5 more seconds while watching nearby caps' solder pads and ensuring they don't fly away. ¯\_(ツ)_/¯


Yes, those temps are absolutely sane for hot air. You didn't specify that.


The trick is staying below the chip's rated processing temps because many of these temps are far too high and could easily lead to semiconductor degradation, especially with the mechanical shock of thermal stresses from rapid or uneven heating and cooling. Hot air is far more uneven and uncontrolled than a BGA oven.


That sounds low, unless you are using one of the commercial brands notorious for displaying too-low temperatures (so that their iron/air/oven will be "the good one" that works when others don't).


According to that datasheet peak temp should be above 245C for at least 20s.


Katriel Cohn-Gordon is also a Meta employee.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: