[–] 8 points 1 month ago

Wero is based on SEPA, the Single Euro Payments Area, which only covers countries in Europe. In order to use Wero, your bank (in a SEPA country) has to explicitly support it (not all of them do; I have checking accounts with 3 banks and only one of them has announced plans to support it). And to use it when shopping, the merchant also has to support it.

Apparently there are plans to link European and Canadian payment systems. But no way the US will do this.

  • source
  • parent
  • context
  • [–] 5 points 1 month ago (1 child)

    In my current setup, I think my reverse proxy does not detect certificate updates (done by a different service), and I am just lucky that usually the service restarts because of some update before the old one expires.

    Once that is solved, I am tempted to try the six-day expiration.

  • source
  • [–] 3 points 1 month ago* (last edited 1 month ago) (2 children)

    B21 is the booster (which launched Starlink Group 31-1 on Monday), and it had a soft-then-RUD landing in the Gulf of Mexico.

    However, S40 (previous flight) is listed as destroyed in the Indian Ocean; but it is currently in the Atlantic Ocean sitting on the deck of Forte (status: totaled because of water damage?)

  • source
  • parent
  • context
  • [–] 43 points 3 months ago* (last edited 3 months ago) (4 children)

    You have to carry a piece of paper in your wallet that contains a PIN. The piece of paper contains no further information, just a PIN. You decline to answer any questions regarding this piece of paper or your phone’s PIN.

    This might not be a good idea, depending on your jurisdiction.

  • source
  • [–] 2 points 3 months ago (2 children)

    With V2, the booster performed very well, but it took the ship a few tries to reproduce all milestones V1 had already accomplished. With V3, we are seeing the opposite. Still, the booster performed better than on the previous flight.

    My impression is that the ship has performed exceptionally well for all (controlled) reentries and landings, even far outside of the expected operating regime. Without a flap to watch that gets slowly eaten by plasma, the last reentries were delightfully boring. Of course, we cannot judge if the landing precision was sufficient for all those flights, but they seem to be confident.

  • source
  • parent
  • context
  •  

    A kernel patch series titled "Deprecate Legacy IP" was submitted by David Woodhouse:

    RFC1883, the IPv6 standard, was published in the final decade of the 1900s. That's closer in time to the Apollo 11 moon landing than it was to today.

    Even our esteemed Maddog has worked with computers for longer in the IPv6 era, than he ever did before it.

    Yet Linux still can't even be built with only IPv6 support and without support for Legacy IP. This long overdue patch series fixes that, and immediately marks Legacy IP for deprecation.

    It also cleans up a few tautological "INET && IPV6" and "INET || IPV6" checks, since IPV6 (and now LEGACY_IP) cannot be selected without the overall CONFIG_INET option.

    For now, we only add a warning when a process listens on a Legacy IP socket (since you can listen on IPv6 and still accept connections which have come through a timewarp from the 20th century. Adding warnings for making outbound connections or accepting on Legacy IP can come later.

    I would be happy if "Legacy IP" ceased to be the "industry standard" and IPv6 be the default, even if I had to beat IPv6 into the head of every single network administrator's head with a shovel.' said Jon 'maddog' Hall, ancient supporter of Free and Open Source Software.

    Also see this follow-up post:

    Yeah. The date notwithstanding, I do actually think we should do most of this for real.

    Maybe we don't get away with the actual deprecation and the warnings on use just yet, and maybe we won't even get away with calling the config option CONFIG_LEGACY_IP, although I would genuinely like to see us moving consistently towards saying "Legacy IP" instead of "IPv4" everywhere.

    But we should clean up the separation of CONFIG_INET and CONFIG_IPV[64] and make it possible to build with either protocol alone.

     

    Fedora 45 (to be released in ~October 2026) will enable IPv6‑mostly networking in NetworkManager by default, automatically recognising DHCPv4 option 108, PREF64 and starting CLAT to provide IPv4 connectivity over an IPv6‑mostly network. This transition eases the shift to IPv6‑only while preserving legacy IPv4 support. No user configuration is required.

     

    ipxlat is a new virtual network device for stateless IPv4/IPv6 packet translation (SIIT, RFC 7915). It is intended as a building block that lets Linux systems support every IPv6↔IPv4 connectivity scenario in RFC 6144. While the core translation is stateless, stateful NAT64 can be added simply with nftables/iptables SNAT or MASQUERADE rules.

    The code is based on the Jool out-of-tree kernel module implementation. ipxlat is part of the IPv6 Monostack project

     

    NetworkManager now implements CLAT for the 464XLAT transition mechanism, auto‑detecting NAT64 prefixes via PREF64 router advertisements and exposing configurable properties for controlling CLAT behavior. The PR adds two new configuration options: ipv4.clat, defaulting to “no” (for now), and ipv4.dhcp‑ipv6‑only‑preferred, defaulting to “auto”. CLAT is implemented using an eBPF program.

     

    Ein Inhaftierter in Bayern hat kein Anrecht auf vegane Kost. Das hat das oberste Landesgericht im Freistaat entschieden. Im konkreten Fall beantragte ein zu einer fünfmonatigen Haftstrafe verurteilter Mann im Gefängnis vegane Mahlzeiten. Die JVA bot ihm stattdessen vegetarisches und laktosefreies Essen an und verwies darauf, dass er in der Anstalt auch auf eigene Kosten vegane Lebensmittel erwerben könne. Dieses Vorgehen sei nach Auffassung des Strafsenats rechtens, teilte eine Sprecherin des Landesgerichts mit.

     

    With the IPv6-only option, a host can indicate that it supports operation in an IPv6-only network. This is useful in combination with 464XLAT CLAT: IPv4 applications can connect to legacy addresses using a NAT64 gateway provided by the network. In this situation, the host can operate without IPv4 addresses assigned, and all network traffic is IPv6, without loosing connectivity to IPv4 hosts.

    NetworkManager currently does not support CLAT, and thus, this new option is disabled by default. Various CLAT implementations exist (jool – out-of-mainline kernel module, upstreaming not planned; tayga – unmaintained userspace application, potentially performance issues), but are not suitable as a general solution.

    An eBPF-based CLAT is already being worked on. Hopefully, we can see full IPv6-only support soon! This will enable IPv6-only home networks for the average user, assuming the ISP provides a NAT64 gateway. Connections to IPv4 hosts can be established using the NAT64 gateway, without any IPv4 connections in the local network or directly to the internet. For legacy devices in the local network, IPv6-mostly networks still provide local IPv4 connections.

    view more: next ›