home.social

Search

252 results for “alternativeto”

  1. What a week. It was planned to be a very relaxed week with mostly food, drinks, conversations and not much else. Which it almost was. I was quite lucky on Wednesday when the whole patch business started that it was a very rainy day anyway, so I could patch my little server here without disrupting the vacation proceedings too much.
    If you want to read more about what happened there, I can really recommend the blog post by Larry Garfield about The real lessons of php2shell and the posts he links to. Very well written and I absolutely agree with his assessment that what we saw was actually a masterclass in how to react to this kind of situation.

    Lately I’ve been mostly carrying one of my small Micro-Four-Thirds cameras around and I’m mostly happy with their JPGs. I tend to crop and rotate a bit, but that’s it. Last week I brought my big chunky Sony along, with adapted Contax G lenses and mostly took black and white photos. Straight out of the camera they are still very impressive – but somehow more so than with the other cameras I feel the need to fiddle around with the raw files. Alas, I refuse to rent Lightroom and I haven’t really found an alternative that works for me. Such a bummer.

    In other news, I had the first snowfall of the year, made a very good deal on my favorite socks (Falke Walkie Lights, if you need to know. Not an ad.) and got talked into another SailNavSim Jules-Verne-Trophy.

    #Lightroom #php2shell #sailnavsim
  2. DATE: October 25, 2026 at 06:00AM
    SOURCE: PSYPOST.ORG

    ** Research quality varies widely from fantastic to small exploratory studies. Please check research methods when conclusions are very important to you. **
    -------------------------------------------------

    TITLE: Your body makes its own cannabis-like chemicals as you run, and neuroscience research finds they keep rising all the way to the marathon finish line, a possible clue to the runner’s high

    URL: psypost.org/your-body-makes-it

    A long run appears to keep the body’s own cannabis-like chemical messengers active for hours. New research published in BMC Medicine indicates that one of these compounds, anandamide, climbs steadily during a marathon and stays elevated 45 minutes after the finish, and that levels are also higher after ultramarathons of up to 230 kilometers. These chemical changes occurred alongside shifts in mood, such as reduced anxiety after running, although the study did not test whether one caused the other.

    The runner’s high is a state some people report during or after endurance exercise, marked by euphoria, reduced anxiety, less pain, and a sense of calm afterward. Early explanations credited endorphins, the body’s natural opioid painkillers, but endorphins are large, water-soluble molecules, and there is no convincing evidence that they cross the blood-brain barrier, the protective filter between the bloodstream and the brain, in meaningful amounts.

    Endocannabinoids offer an alternative: they are small, fat-soluble molecules made on demand from cell membranes, they can cross that barrier, and they act on the same cannabinoid receptors targeted by THC, the main psychoactive compound in cannabis. The two best studied are anandamide and 2-arachidonoylglycerol, often shortened to 2-AG.

    Laboratory experiments began supporting this shift in thinking when a 2015 animal experiment led by Johannes Fuss, the senior author of the new study, showed that wheel-running mice relied on cannabinoid receptors, rather than opioid receptors, to experience reduced anxiety and lower pain sensitivity. Human research soon followed, including a 2021 clinical trial by the same group where researchers gave participants a medication that blocked opioid receptors. The runners still reported the typical calm and euphoric sensations of a runner’s high, suggesting that endorphins were not required for those effects.

    In a 2022 systematic review, the same group found that 14 of 17 studies detected a rise in endocannabinoids after a single bout of exercise. But as the authors of the new study note, nearly all of that human research involved workouts lasting under an hour, leaving open what happens during true long-distance events.

    “Humans are capable of running for many hours, sometimes even days, and we wanted to understand what happens to the endocannabinoid system during such extraordinary endurance efforts,” lead author Michael Siebers, a psychiatrist at LVR University Hospital Essen, told PsyPost.

    “I believe that our ability to run long distances cannot be explained by anatomy alone,” Siebers explained. “We probably also need an entire orchestra of neuromodulators that reward us for sustained physical activity and help us continue running despite fatigue and discomfort. Thanks to a wonderful collaboration with researchers from Ulm and the German Sport University Cologne, we were able to investigate these processes during marathon and ultramarathon running, including distances of up to 230 kilometers.”

    To investigate these biochemical and emotional shifts under real-world conditions, Siebers and his colleagues, including senior author Johannes Fuss of the University of Duisburg-Essen and collaborators at University Hospital Ulm and the German Sport University Cologne, designed two field studies of trained endurance athletes.

    The first investigation examined 19 experienced runners, including seven women and 12 men, who completed a marathon course consisting of three 14-kilometer loops around Lake Baldeney in Essen, Germany. To establish a realistic comparison, each runner returned one to two months later to complete an identical-duration walking session along the same route at their preferred pace. Blood samples were drawn at the start, at the 14-kilometer and 28-kilometer marks, immediately after the full course (about 43 kilometers), and after a 45-minute rest period. Alongside blood draws, participants completed visual rating scales to score their current levels of euphoria, anxiety, and physical pain.

    The second investigation followed 36 athletes (16 ran 100 kilometers, 7 ran 160, and 13 ran 230) taking part in the TorTour de Ruhr, a non-stop ultramarathon in central Germany. These athletes, comprising 13 women and 23 men, provided blood samples and mood ratings before the race and shortly after crossing the finish line. In both studies, laboratory technicians measured several key lipids, including anandamide and 2-AG.

    In the marathon study, levels of anandamide rose progressively across the entire run. By the mid-race mark, anandamide was higher during running than during walking, which produced only modest changes, and it remained higher 45 minutes after the marathon ended. Running was also far more intense, with runners averaging about 83 percent of their estimated maximum heart rate, compared with about 58 percent while walking. The compound 2-AG displayed a different trajectory, showing lower levels early in the run compared to walking, but climbing during the final kilometers and staying elevated during early recovery.

    The ultramarathon runners exhibited similar biochemical patterns upon completing their races. Anandamide and 2-AG concentrations were both higher after the race across all three ultramarathon distances compared to pre-race baselines. In an exploratory comparison, post-race anandamide levels after the marathon were nearly double those seen after the ultramarathons (32.4 versus 17.1 in the study’s measurements), which the authors suggest may reflect the higher running intensity of the shorter race.

    Mood ratings also shifted during running. Marathon participants reported higher euphoria while running than while walking at several points, although at the 28-kilometer mark, a stage where runners often describe “hitting the wall,” euphoria was no longer different from walking. Anxiety ratings started slightly higher before the marathon than before the walk, then fell toward the end of the run, and pain ratings showed little change after 14 kilometers but rose markedly from 28 kilometers on. In the ultramarathon group, anxiety decreased after the race, more so at 100 and 160 kilometers than at 230, while pain rose and euphoria did not change in a statistically significant way.

    When asked afterward, only 3 of the 19 marathoners said they had experienced a runner’s high during the marathon, while 8 said they had not and 8 were unsure; among the ultramarathoners, 12 said they had and 19 said they had not.

    The findings are in line with research covered by PsyPost in 2022, which found that acute exercise consistently increased endocannabinoid levels, especially anandamide, with moderate intensity yielding stronger boosts than low intensity.

    “This is an interesting study, particularly because it’s not easy to investigate physiological responses to exercise over marathon and ultramarathon distances,” said Danielle McCartney, a research affiliate at the University of Sydney who was not involved in the study. “The key finding is that circulating concentrations of anandamide (AEA), an endocannabinoid, increased progressively throughout the marathon and were also elevated following ultramarathons of 100, 160 and 230 km.”

    “Previous studies have consistently shown that moderate-intensity running increases blood concentrations of AEA,” McCartney told PsyPost. “However, most of this research has focused on relatively short bouts of exercise (less than 60 minutes). This study fills an important gap by examining much longer running distances, and shows that increases in AEA also occur during marathon and ultramarathon running.”

    The researchers see the sustained activity as a possible clue to how humans manage hours of running.

    “One of our most important findings is that the body’s own cannabinoid system remains active even during extremely prolonged exercise,” Siebers noted. “We observed substantial increases in endocannabinoids, particularly anandamide, not only during marathon running but also after ultramarathons lasting many hours.”

    “These molecules are sometimes described as the body’s own cannabis-like substances because they act on the same cannabinoid receptor system targeted by THC,” he said. “They may contribute to the rewarding, calming, and potentially pain-modulating effects of running. From an evolutionary perspective, I find this particularly fascinating. Humans have an extraordinary capacity for endurance running, and the endocannabinoid system may be one of the biological mechanisms that make prolonged running not only physically possible but also psychologically rewarding.”

    Siebers described the shift many runners report over the course of a run.

    “At the beginning of a run, everything may feel uncomfortable,” he observed. “Your calves are aching, your back feels stiff, and every step requires some effort.”

    “But after a while, something can change,” he noted. “Your movements become smoother, running feels increasingly effortless, and you may enter a state of flow. Sometimes this develops into euphoria, while everyday worries and stress seem to fade into the background.”

    Siebers also sees potential relevance for mental health.

    “As a psychiatrist, I find this especially interesting because running can become a valuable tool for coping with stress, improving mood, and supporting mental well-being,” he added. “Of course, exercise is not a replacement for professional treatment when it is needed, but for some people, it can be an important part of their recovery and everyday life.”

    The study did not test whether runners whose anandamide rose the most felt the most euphoric or calm.

    McCartney cautioned, however, against assuming that these chemical increases directly generate the emotional sensations reported by participants. “It’s important to recognize that this study doesn’t establish that increases in AEA are responsible for the ‘runner’s high,'” she explained. “It shows that prolonged running increases blood AEA concentrations and is associated with changes in mood, including increased euphoria and reduced anxiety. While these findings are consistent with the idea that AEA contributes to the runner’s high, they don’t establish a causal relationship.”

    The TorTour de Ruhr presented extreme physical demands, requiring runners to navigate unfamiliar routes for up to 230 kilometers, often through the night and in isolation.

    “What impressed me most was witnessing what humans are capable of achieving,” Siebers recounted. “Some of our participants ran distances of up to 230 kilometers, maintaining their effort for many hours, sometimes running alone through the night on unfamiliar trails. Equally fascinating was the atmosphere among the ultramarathon runners. Despite the enormous physical demands, there was a remarkable sense of community and positivity.”

    “I was particularly struck by participants who reported very little anxiety after these extraordinary distances, even after spending hours alone in unfamiliar surroundings,” he said. “Some runners also reported surprisingly little pain despite covering distances that would seem almost unimaginable to most people. These observations make me wonder how strongly our internal neuromodulatory systems can influence the way we experience physical effort, pain, and fear.”

    Pain was still common: 29 of the 36 ultramarathoners reported pain during the race, only five reported none, and eight said they used pain medication, particularly in the longest race.

    As with all research, there are some caveats to consider. The marathon study used walking as a comparison rather than having participants sit quietly, meaning the control condition still involved mild physical exertion. Participants also selected their own running and walking speeds, which preserved a realistic race environment but introduced variation in how hard each individual was working.

    “I have reasonable confidence in the main findings, particularly because the increases in AEA were consistent across the marathon and ultramarathon studies and align with previous research,” McCartney told PsyPost. “However, there are some limitations worth considering. Measuring endocannabinoids in blood can be technically challenging, and although the authors used established analytical methods, they don’t explicitly report whether these methods were validated.”

    “I’d also have liked more information about what participants ate during and after exercise,” McCartney added. “We know that nutrient intake can influence blood AEA concentrations, so it’s possible that dietary behavior affected the measures.”

    The authors describe their laboratory analysis as following established, standardized protocols, including adding chemically labeled reference versions of each compound to every sample to allow exact measurement. They also acknowledge that participants’ nutrition, rest, and time of day were not fully controlled.

    Every participant also ran the marathon before doing the walking session, which the authors note may have raised anxiety at the start of the running day. The samples were also small, with 19 marathoners and between 7 and 16 runners at each ultramarathon distance, and no blood was drawn during the ultramarathons themselves.

    The emotional measures relied on brief, single-item rating scales, which capture only a snapshot of complex mental states like flow or emotional relief. Logistics during the ultramarathon also meant that pre-race samples for the 230-kilometer group had to be collected the previous evening rather than right at the starting line.

    “One important distinction is that we measured endocannabinoids in the blood, not directly in the brain,” Siebers pointed out. “Although our findings show substantial changes in circulating endocannabinoid concentrations, we cannot yet determine precisely what happens in the brain during prolonged running.”

    “Another important point is that the runner’s high is not simply caused by one molecule,” he added. “Endocannabinoids are probably part of a much larger and highly complex orchestra of neuromodulators, including dopamine, serotonin, endogenous opioids, and other signaling systems. Furthermore, not everyone experiences a runner’s high, and running does not necessarily become more enjoyable the longer someone continues.”

    When considering future research, McCartney highlighted both pharmacological and nutritional avenues for follow-up testing. “Ideally, I’d like to see whether blocking cannabinoid receptors prevents the runner’s high,” she said. “Unfortunately, the safety concerns associated with drugs like rimonabant make that a difficult experiment to conduct in humans!”

    Rimonabant, a drug that blocks the main cannabinoid receptor, was pulled from the European market in 2008 after it was linked to depression and suicidal thoughts.

    “More realistically, I’d be interested in seeing whether nutrition influences the endocannabinoid response to prolonged exercise,” McCartney told PsyPost, “particularly given that runners typically consume substantial amounts of carbohydrate during marathon and ultramarathon events.”

    Looking ahead, the authors hope to examine how these chemical messengers operate directly within the central nervous system during physical exertion.

    “One of my main interests is understanding how running influences mood changes and the brain itself,” Siebers said. “So far, our research has primarily focused on measuring endocannabinoids in peripheral blood. However, the runner’s high ultimately involves processes within the central nervous system, and we still know surprisingly little about what actually happens in the human brain during running. I would therefore like to investigate these central mechanisms more directly, potentially through neuroimaging and other methods that allow us to study neuromodulation in the brain.”

    “In addition, I am particularly interested in how the endocannabinoid system interacts with pain regulation during prolonged exercise,” he continued. “Why can some individuals continue running for hours despite considerable physical stress, while others experience increasing discomfort? Understanding these mechanisms could provide valuable insights not only into endurance exercise but also into pain regulation and mental health.”

    Beyond laboratory measurements, the researchers also reflected on the broader personal and evolutionary dimensions of sustained running.

    Siebers emphasized that the effect requires no outside substance. “What fascinates me is that our bodies can produce their own cannabis-like substances simply through physical activity,” he told PsyPost. “Under the right circumstances, this can contribute to a completely natural high, without consuming any external substance.”

    “For me, the most exciting message is that running is much more than moving our legs,” Siebers said. “It is a fascinating interaction between our body and brain, and understanding this interaction may help us discover why humans have developed such an extraordinary relationship with endurance running.”

    The study, “Endocannabinoid dynamics across marathon and ultramarathon running: evidence from two field studies,” was authored by Michael Siebers, Dana Huvermann, Christoph Siebers, Deborah Canales-Romero, Alexandra Florea-Ghile, Lina Keite, Lucas John, Moritz Munk, Roman Bizjak, Jens Witzel, Sebastian Schulz, Johannes Kirsten, Laura Bindila, Anke Hinney, Marijke Grau, Daniel A. Bizjak, Harald Engler, and Johannes Fuss.

    URL: psypost.org/your-body-makes-it

    -------------------------------------------------

    Private, vetted email list for mental health professionals: clinicians-exchange.org

    Unofficial Psychology Today Xitter to toot feed at Psych Today Unofficial Bot @PTUnofficialBot

    -------------------------------------------------

    #psychology #counseling #socialwork #psychotherapy @psychotherapist @psychotherapists @psychology @socialpsych @socialwork @psychiatry #mentalhealth #psychiatry #healthcare #depression #psychotherapist #RunnersHigh #Running #Marathon #Ultramarathon #EnduranceRunning #SportsScience #Neuroscience #Endocannabinoids #Anandamide #MentalWellness

  3. ACH Return Codes Explained: R01–R85 and How to Handle Them in Production

    ACH Return Codes Explained: R01–R85 and How to Handle Them in Production


    When you send an ACH debit or credit, you're not guaranteed it will settle. The National Automated Clearing House Association (Nacha) defines 85 possible return codes—each one a specific reason why a bank rejected your transaction. As a developer building payout systems, understanding these codes is critical: they determine whether you retry, escalate to support, or switch payment rails entirely.

    This guide covers the most common return codes you'll encounter in production, what triggers them, and how your code should respond.

    The Big Three: R01, R03, R10


    R01 — Insufficient Funds

    The account exists and is valid, but the account holder doesn't have enough money. This is the most common return you'll see on debit transactions.

    • When it fires: ACH debit posted, but balance dropped below the transfer amount.
    • Developer action: Log the return, notify the customer, and do not retry immediately. Implement a dunning flow: wait 3–5 days, then retry once. If it fails again, flag for manual review or offer an alternative payment method.

    if (returnCode === 'R01') {
    await markTransactionForRetry(transactionId, {
    retryAfter: Date.now() + (4 * 24 * 60 * 60 * 1000), // 4 days
    maxRetries: 1
    });
    await notifyCustomer(customerId, 'Payment failed due to insufficient funds');
    }

    R03 — No Account / Unable to Locate Account

    The account number or routing number is invalid, or the account was closed.

    • When it fires: Bank can't match the account details you provided.
    • Developer action: Do not retry. This is a data quality issue. Validate the account number and routing number with the customer, or ask them to re-enter their banking details. Consider integrating microdeposit verification before accepting ACH details.

    R10 — Customer Initiated Return

    The account holder disputed the transaction or called their bank to reverse it. This is a chargeback equivalent for ACH.

    • When it fires: Within 60 days of the original transaction (per Nacha rules).
    • Developer action: Treat this as a customer service issue. Log it, contact the customer to understand why, and adjust your onboarding or communication. Do not retry without explicit customer consent.


    Secondary Returns: R04, R07, R29


    R04 — Reserved (Not Currently Used)

    Ignore this; it's in the Nacha spec but not actively returned by banks.

    R07 — Authorization Revoked by Customer

    The customer asked their bank to block future ACH transactions from you (similar to stopping a check).

    • Developer action: Stop all ACH attempts for this customer. Reach out to understand why, and offer alternative payment methods.

    R29 — Corporate Customer Advises Not Authorized

    A business account holder says they didn't authorize this transaction.

    • Developer action: Escalate immediately. This is a fraud or authorization dispute. Do not retry; contact the customer and your compliance team.


    Rare but Critical: R82, R83


    R82 — Duplicate Entry

    You submitted the same transaction twice in the same batch window.

    • Developer action: Your code has a bug. Check for idempotency failures in your ACH submission logic. Implement unique trace numbers (ODFI trace) to prevent duplicates.

    R83 — Routing Number Check Digit Error

    The routing number's checksum is invalid.

    • Developer action: Validate routing numbers client-side before submission using the Nacha checksum algorithm (weighted sum mod 10). Catch this before it reaches the bank.


    Building a Return Handler


    Here's a production-ready pattern:

    javascript
    const returnActions = {
    'R01': { action: 'retry', delay: 4 * 24 * 3600 * 1000, maxAttempts: 1 },
    'R03': { action: 'escalate', reason: 'invalid_account' },
    'R07': { action: 'block', reason: 'customer_revoked' },
    'R10': { action: 'investigate', reason: 'customer_initiated' },
    'R82': { action: 'escalate', reason: 'duplicate_detected' },
    'R83': { action: 'reject', reason: 'invalid_routing' },
    };

    async function handleACHReturn(transactionId, returnCode) {
    const policy = returnActions[returnCode];
    if (!policy) {
    await logUnknownReturn(returnCode);
    return;
    }

    switch (policy.action) {
    case 'retry':
    await scheduleRetry(transactionId, policy.delay, policy.maxAttempts);
    break;
    case 'escalate':

    ---

    *Decoding ACH return codes programmatically? The [ACH Return Codes API](rapidapi.com/payoutrail-ach-re…) returns the full Nacha R01–R85 set with plain-language descriptions and handling guidance.*#backend #fintech #programming #softwareengineering #software #coding #development #engineering #inclusive #community
    ACH Return Codes Explained: R01–R85 and How to Handle Them in Production

  4. Yesterday, I helped troubleshoot a failed GBase Database(GBase 8a) installation in a POC environment. The error was a Python SyntaxError near the beginning of SetSysEnv.py.

    The engineer confirmed that Python 2 was installed. But when we checked the default interpreter, we found the real problem:

    which python
    python -V

    The python command pointed to /usr/bin/python3.

    Python 2 was installed, but the installation script was running under Python 3.

    That small difference can prevent a GBase Database installation script from parsing correctly. Reinstalling the package or changing file permissions won't fix an interpreter mismatch.

    1. Check the Python Version Before Installing


    Some GBase Database(GBase 8a) installation packages use Python 2 scripts. The required runtime depends on the product release and installation package, so verify the official documentation before changing the environment.

    Start with these checks:

    which python
    python -V

    which python2
    python2 -V

    rpm -q python2 python-libs

    On newer systems, including CentOS 8, RHEL 8, and Kylin V10, the default python command may point to Python 3 or may not exist at all.

    Having Python 2 installed does not guarantee that the installer will use it.

    2. Verify Which Interpreter the Installer Actually Uses


    If the supported GBase Database package requires Python 2, check the interpreter entry point expected by that release.

    Also check whether different users resolve python differently:

    su - gbase -c 'command -v python; python -V'

    Replace gbase with the actual database operating system account used in your environment.

    The root user's PATH may differ from the database user's PATH. Shell profiles, custom environment variables, and tools such as Conda can all affect interpreter selection.

    For multi-node deployments, perform the same checks on every node. Correcting the template machine does not guarantee that manually modified or previously cloned nodes have the same configuration.

    3. Configure Python Carefully


    If the official installation instructions require Python 2, install the appropriate runtime and dependencies using the supported method for your OS.

    On systems that provide the alternatives mechanism, a configuration might look like this:

    alternatives --display python

    If your OS and product documentation explicitly permit changing the system-wide python alternative, configure it accordingly. For example:

    alternatives --install /usr/bin/python python /usr/bin/python2 100
    alternatives --set python /usr/bin/python2

    python -V
    type -a python

    Important: Do not apply these commands blindly to every Linux distribution. Changing the system-wide Python interpreter can break OS utilities or other software that expects Python 3. Prefer a product-supported runtime, isolated environment, or documented configuration when available.

    After changing the configuration, open a fresh login shell and verify the result again.

    4. Don't Confuse Interpreter Errors with Other Failures


    The error message often provides the first useful clue.

    • SyntaxError near the start of a script: Check whether the script is running under the required Python version.
    • Missing Python module: Verify the required packages and module search path.
    • External command failure midway through execution: Investigate the command, permissions, environment variables, and dependencies.
    • Different results between users: Compare PATH, shell profiles, and interpreter locations.

    A Python version mismatch is a useful hypothesis, not proof that every installation failure has the same cause.

    5. Use the Documented Installation Entry Point


    Follow the installation procedure for your specific GBase Database release. If the script expects to be invoked through the python entry point, do not assume that calling it directly with python2 is equivalent; the installer may perform additional environment checks.

    For example, if the official instructions specify:

    python gcinstall.py

    use that documented command rather than improvising a different invocation.

    Apply the same principle to SetSysEnv.py: confirm the supported interpreter and invocation method before running it.

    6. Add Python Checks to Your Pre-Install Checklist


    For a multi-node GBase Database deployment, record these details before installation:

    • Hostname and operating system version.
    • Kernel version and CPU architecture.
    • Required Python version.
    • Resolved path of the python command.
    • Python version under the account that runs installation.
    • Relevant package and dependency versions.

    A quick check can save hours of troubleshooting:

    hostname
    cat /etc/os-release
    uname -r
    command -v python
    python -V

    Run it on every node and compare the results before proceeding.

    Final Takeaway


    When GBase Database installation fails with a Python syntax error, check the interpreter before replacing packages or editing scripts.

    The important question is not simply whether Python 2 is installed. It is whether the installer is using the interpreter required by that particular release.

    TIL question: Have you encountered a database installation failure caused by the default Python interpreter pointing to the wrong version?

    Keywords: GBase Database, GBase 8a installation, Python 2 compatibility, Python SyntaxError, CentOS 8, RHEL 8, Kylin V10, database troubleshooting#gbase #database #数据库 #todayilearned #software #coding #development #engineering #inclusive #community
    TIL: Why GBase Database Installation May Require Python 2

  5. Case of the day: Whoop v. Shenzhen Wonlex Technology

    The old Citgo sign. Bostonians will understand. Credit: Caleb Spicer (CC BY)

    The case of the day is Whoop, Inc. v. Shenzhen Wonlex Technology Co. (D. Mass. 2026). As you might guess from the case name, it’s an IP infringement case involving a Chinese defendant. Whoop sought a preliminary injunction. It made an emergency motion for leave to serve the Chinese defendant with process by email before the hearing on the motion for a preliminary injunction.

    The longtime Letters Blogatory view, now blessed by the federal appellate courts that have considered the question, is that you cannot serve process by email on a defendant in China whose address is known. The reason is that under the Service Convention, email service is permissible, if at all, only because it qualifies as service by postal channels.1 The Convention permits service by postal channels and certain other alternative methods, but only if the state of destination has not objected. But China has objected to all alternative methods of service. QED.

    The judge, without much discussion, agreed with the orthodox view. But Whoop pointed to Article 15 of the Convention, which provides:

    Notwithstanding the provisions of the preceding paragraphs the judge may order, in case of urgency, any provisional or protective measures.

    Okay, but what are the preceding paragraphs? They explain when a court can enter a judgment in cases where “a writ of summons or an equivalent document had to be transmitted abroad for the purpose of service, under the provisions of the present Convention, and the defendant has not appeared,” or in other words, when a court can enter a default judgment in cases where the Convention applies.

    Whoop argued that service of process by email is a “provisional or protective measure” that the court can authorize “in case of urgency.” There are courts that have taken that view. But the judge in today’s case (Judge Saylor, here in Massachusetts) disagreed, holding, correctly in my view, that Article 15 simply means that a court can order measures such as preliminary injunctions or temporary restraining orders, even if the court could not yet enter a default judgment. The purpose of the sentence Whoop relied on is simply to make it clear that there has to be a way for courts to act on applications for emergency relief even if they cannot enter a final judgment unless and until service of process has been effected.

    But that doesn’t mean Whoop was barred from seeking a preliminary injunction. It’s true that under the law of the forum, namely FRCP 65(a)(1), a preliminary injunction may issue only “on notice to the adverse party.” There is also, of course, a due process issue here. But notice is not service.

    Think twice before wading into this semantic morass. The Convention refers in English to “service,” but in French it refers to “signification” and to “notification.” I am not a civil law expert, but at a high level, signification is the more formal method of notification, executed by a judicial officer, and roughly equivalent to service of process, while notification is a broader term that reaches less formal methods of notifying a party of something.

    The judge’s view was that because giving notice of a motion for a preliminary injunction does not require service of process, and because email is adequate notice both under FRCP 65 and under the Due Process Clause, providing notice by email does not violate the Convention. As a practical matter, he has to be right. Otherwise it is hard to see how a US court could issue preliminary injunctions in cases where the defendant is in a state that has objected to service by alternate methods. But I am not so sure that getting to that conclusion is a simple matter under the Convention.

    Here is how Article 1 of the Convention, in English, defines the Convention’s scope:

    The present Convention shall apply in all cases, in civil or commercial matters, where there is occasion to transmit a judicial or extrajudicial document for service abroad.

    And here it is in French:

    La présente Convention est applicable, en matière civile ou commerciale, dans tous les cas où un acte judiciaire ou extrajudiciaire doit être transmis à l’étranger pour y être signifié ou notifié.

    The problem is that “service,” in English, should have the same meaning as “signification ou notification” in French. That is, it should not be limited to formal service of process. I have also written previously about the Convention’s reference to transmission of any “judicial or extrajudicial document” rather than simply to summonses in order to demonstrate that the Convention can’t easily be limited to service of process in the strict sense, as we conceive of it in American law.

    I don’t think there can be any real argument that a motion for a preliminary injunction, with the accompanying papers, is a “judicial document,” and that, at the beginning of a case, where a defendant abroad is not (yet) represented by US counsel, there is occasion to transmit the motion to the defendant abroad. So what is a court to do? One possibility is to look to Schlunk v. Volkswagen, 486 U.S. 694 (1988), which suggest that the Convention really is limited in its scope to service of process, though that solution is not persuasive for the reasons I’ve just given. Of course I acknowledge the discussion of the drafting history in Schlunk, but I have to say that it seems to me that the court’s view begs the question, because it seems to say that the use of the word service, or signification or notifcation, rather than delivery (remise), shows that the Convention means to refer to service of process. But the whole point is that signification and notification together apply to many more kinds of documents than just the kinds used to bring a defendant before the court. And that’s true if we consider the English word service without worrying about French. FRCP 4 governs service of the summons and complaint and explains the methods that can be used. FRCP 5 governs service of all other documents in a lawsuit and explains the methods that can be used. So even in a purely American context, focusing on the use of the word “service” doesn’t make the case.

    A better view, maybe, is to look at the “notwithstanding” language from Article 15, but in a different light than Whoop or the court considered it. The question shouldn’t be whether service of documents by email is a “provisional or protective measure,” but rather, whether a court’s power to grant provisional or protective measures necessarily implies the power to do the things that are necessary conditions precedent to granting those measures, for example, giving notice of the proceedings to the adverse party via a method that would not ordinarily be permissible under the Convention. I’m not sure that’s perfect, but it seems the most defensible way to get to the necessary conclusion: that even if the plaintiff will ultimately have to serve the defendant via the Chinese central authority, in case of urgency, it can get a preliminary injunction after giving notice in a less formal way.

    1. If service by email is not service via the postal channel, then China’s objection isn’t relevant, and the key point becomes the lack of any provision in the Convention that can fairly be read to authorize or permit service by email. ↩︎
    #China #Email #HagueServiceConvention
  6. Artemis Plan Analysis?

    I thought a Cargo Starship was pushing Orion to Lunar Orbit, where Orion would dock with the HLS Starship.
    ‘Maybe Angry is right: the Block 3 HLS Starship will push Orion to Lunar Orbit, where the astronauts will transfer…why wouldn’t they transfer to the HLS in high-LEO…?’

    https://youtu.be/fZ8HF5hY4Sw

    I shared my concerns about risking human astronauts onboard unprepared spacecraft in the previous comment. Previously, I pointed out that the risk of top-heavy landers is not as great as Angry makes it out to be.
    ‘But Angry says it is risky, maybe he is right, but I asked AI if the height of any of the previous landers was in any way the cause of the crash…’
    Previously I commented about refueling at higher LEO, but then I thought it would take too much fuel to get the fuel there. Angry talks about boil-off, which I think is an engineering issue that has been or can be reduced.??
    v3 Starship payload is 100t+, and v4 is 200t+, so who knows how much fuel it can take to LEO?

    Bonsai 27B Prompt:
    Pasted transcript: Write a review of the video as an AI Scientist for a futurist.
    @Web Fact-Checking via Google Search: Share insights about the use of billionaire contractors.

    Bonsai Said:
    🚀 AI SCIENTIST REVIEW: Artemis Acceleration Plan Analysis

    ⚠️ CRITICAL FINDING: ARCHITECTURAL PHYSICS VIOLATIONS

    The video presents a detailed technical critique of NASA’s proposed 2028 lunar landing timeline. My analysis confirms the presenter raises substantially valid engineering concerns, though some claims require independent verification against primary sources.

    ✅ Verified Technical Claims:

    1. Delta-V Budget Crisis: The video correctly identifies that Starship cannot execute the original Apollo-style mission profile (launch to NRH, wait for crew, descend to lunar surface, return to NRO) due to insufficient propellant efficiency in deep gravity wells.
    2. Orbital Refueling Bottleneck: The thermodynamic analysis of liquid cryogenic fuel boil-off is accurate. Passive thermal management limits mean weeks of staging with continuous propellant loss (0.5-1% daily), creating a compounding deficit that requires 12+ rapid launches to fill a single depot.
    3. SLS Limitations: The Space Launch System was never designed to deliver Orion directly to low lunar orbit, only to its planned NRH trajectory. Forcing this creates structural inefficiency.
    4. Dynetics Alpaca Superiority: The historical rejection of Dynetics’ Alpaca lander for SpaceX’s top-heavy design is well-documented and represents a clear example of political/business influence overriding engineering best practices.

    ⚠️ Unverified/Overstated Claims Requiring Independent Verification:

    1. Kathy Leers Conflict of Interest: The claim that the HLS contract awarding official left NASA shortly after making the decision is compelling but requires primary source verification (internal memos, congressional testimony).
    2. Blue Moon Maturity Timeline: While Blue Origin’s delayed development is well-documented, specific claims about PDR/CDR status require confirmation against official NASA milestone trackers.
    3. “Elon Musk is lying” about 6-8 refueling flights: This is a strong assertion that should be cross-referenced with SpaceX’s own technical presentations and peer-reviewed orbital mechanics analyses.

    📊 FUTURE PROJECTIONS (2028-2040)

    Near-Term (2028-2031): The 2028 Target

    The video’s skepticism is well-founded from a physics standpoint. However, historical precedent shows NASA can accelerate programs when political will is extreme:

    • Apollo was originally planned for 1963; actual landing was 1969 (6-year delay)
    • Artemis I flew in 2022 despite planning delays of ~4 years

    Verdict: A 2028 target is optimistically aggressive but not impossible if SpaceX achieves its rapid cadence and Blue Origin’s backup plan matures simultaneously. However, the physics gaps are real and require either:

    • Breakthrough in cryogenic storage/refueling technology
    • Additional SLS launch capability
    • Acceptance of a more complex, multi-year staging architecture

    Medium-Term (2031-2040): Moon Base Viability

    The video correctly identifies that corporate-driven timelines create structural instability. However, it misses a critical insight: the 2028 target may actually be a strategic signaling device rather than an engineering commitment.

    Projected trajectory:

    • 2028-2030: LEO-only Artemis 3 mission (as proposed) — achievable with current capabilities
    • 2031-2033: First crewed lunar landing — likely possible but high-risk
    • 2034+: Permanent lunar presence — requires massive infrastructure investment

    🧠 FUTUREURIST ANALYSIS FRAMEWORK

    DimensionCurrent State (2026)Projected Trajectory (2040)Key Risk FactorsHuman PresenceLEO-only missionsLunar surface operationsFunding volatility, political cyclesPropulsion TechnologyMethalox rockets dominantPotential for nuclear thermal/electric hybridsRegulatory hurdles, safety certificationInfrastructureEarth-orbit prototypesPermanent lunar habitatsRadiation, life support, resource extractionGovernanceNASA-led with private partnersLikely multi-stakeholder or internationalJurisdictional conflicts, liability frameworks

    💡 ACTIONABLE RECOMMENDATIONS FOR FUTUREPLANNERS

    1. Monitor 2028 Mission Architecture: The LEO-only Artemis 3 design is a testbed for docking and life support integration. Success validates the entire architecture; failure cascades to all future missions.
    2. Track Refueling Milestones: SpaceX’s ability to achieve high-frequency orbital refueling will be the single biggest determinant of whether lunar landings are feasible.
    3. Prepare for Political Cycles: Space programs are highly sensitive to political leadership changes. Build contingency plans for 4-8 year funding cycles.
    4. Diversify Partnership Portfolios: Over-reliance on any single contractor (even SpaceX) creates systemic risk. Maintain qualified backup options.

    📝 CONCLUSION

    The presenter’s critique is primarily valid from an engineering and physics perspective, though some claims require independent verification. The 2028 timeline is optimistically aggressive but not impossible, contingent on SpaceX achieving unprecedented launch cadence and solving refueling bottlenecks.

    For futurists: This video represents a critical inflection point in human spaceflight — where political ambition meets physical reality. The tension between corporate-driven speed and engineering discipline will define the next decade of lunar exploration.

    🏗️ INSIGHTS ON THE USE OF BILLIONAIRE CONTRACTORS

    🔍 Structural Overview

    Billionaire-owned companies and individuals increasingly function as alternative contractors, bypassing traditional procurement systems and creating a parallel contracting ecosystem with distinct characteristics.

    Key Characteristics:

    • Capital-Rich: Access to deep pockets of capital enables rapid prototyping and high-risk experimentation
    • Speed-Oriented: Bypasses traditional procurement cycles (months/years → weeks/months)
    • Vertical Integration: End-to-end control from vision to execution
    • Political Influence: Often maintain significant government relationships

    ⚖️ Evidence-Based Analysis

    Case StudyKey InsightRisk ProfileSpaceX & Unpaid Bills (Fast Company, 2024)$2.5M+ in liens filed by contractors; delayed paymentsHigh financial risk to smaller contractorsAnduril’s Autonomous Development (Forbes, 2022)Builds weapons tech independently without waiting for Pentagon requirementsInverted contracting model — high reward, high riskMercor’s Wage Reductions (Forbes, Nov 2025)Young billionaire co-founders slashed contractor wages by ~33% after project cancellationLabor relations crisis; experience gap concernsLegalist’s Government Contracts (Business Insider, Aug 2025)Received $100M+ in government contracts via Peter Thiel’s fellows networkPolitical dependency creates vulnerability to policy shifts

    📈 Comparative Analysis: Traditional vs. Billionaire Contractors

    FactorTraditional ContractorBillionaire-Owned ContractorFunding SourcePublic/private sector bidsFounder equity/VC backingTimeline PressureProject-driven, risk-mitigatedFounder-driven urgencyRisk AllocationShared with clientsHeavily on founder/companyRegulatory OversightStandard contracting lawsMinimal, novel legal structuresScale ConstraintsLimited by company size/infrastructureLimited only by capitalGovernanceBoard oversight, fiduciary dutiesFounder-centric decision making

    🔮 Future Trajectory (2030-2045)

    1. AI-Augmented Contracting: Machine learning will optimize contractor allocation, predict payment risks, and automate compliance tracking — reducing the “unpaid bills” problem seen in SpaceX cases.
    2. Decentralized Workforce Models: Blockchain-based smart contracts may improve transparency for gig/contractor economies, though regulatory frameworks lag far behind technological capability.
    3. Geopolitical Dependencies: Billionaire contractors handling government contracts will face increased scrutiny as they influence critical infrastructure, defense, and media — creating conflicts of interest that policymakers must address.
    4. Global Supply Chain Reconfiguration: Billionaire-backed tech companies increasingly bypass traditional supply chains entirely, creating new vulnerabilities and opportunities in manufacturing and resource allocation.

    ⚠️ Critical Risks to Monitor

    1. Contractor Exploitation: Unpaid bills, wage reductions, and poor payment practices are emerging patterns that could normalize across industries
    2. Experience Gaps: Young billionaire founders may lack the institutional knowledge required for large-scale project management, leading to catastrophic failures when political cycles shift
    3. Single-Point Dependency: Over-reliance on any single contractor (even SpaceX) creates systemic risk — a lesson learned from the Apollo program and modern government contracting

    📚 Further Reading & Verification Sources

    • Fast Company: “‘We never got paid’: SpaceX contractors call out unpaid bills” (May 2024)
    • Forbes: “Facebook Made This 29-Year-Old Rich; War Made Him A Billionaire” (June 2022) — Anduril analysis
    • Forbes: “The World’s Youngest Self-Made Billionaires Just Slashed These Workers’ Wages by a Third” (Nov 2025)
    • Business Insider: “How DOGE Boosted Legalist’s Government Contracts Business” (Aug 2025)

    🔚 FINAL ASSESSMENT

    YouTube Video: Represents a critical analysis of NASA’s lunar program timeline. The presenter’s physics-based critique is largely accurate, though some specific claims require independent verification. This video captures a pivotal moment where political ambition meets engineering reality in the space race.

    Billionaire Contractors: Represent an emerging parallel contracting ecosystem with distinct characteristics — faster but riskier, more innovative but potentially exploitative. The trend suggests that future infrastructure development will increasingly be driven by billionaire-backed entities rather than traditional contractors, creating both opportunity and vulnerability in global systems.

    #Artemis #Contractors #Spacex #Starship #ANGRYASTRONUAT #AstroAngry #TheAngryAstronaut #moon #NASA #news #science #space #spacex #technology
  7. A CPU-bound Python job split across four threads took 3.6 seconds on my machine. The same job split across four of Python 3.14's new subinterpreters took 0.9 seconds, roughly what one thread alone takes to do a quarter of the work. That part matched what I expected from the PEP. What I did not expect was that asking one of those subinterpreters to run two things at once does not slow it down. It refuses outright.

    concurrent.interpreters is new in the standard library as of Python 3.14, released on 7 October 2026. Subinterpreters themselves are not new - they have existed in the C API since Python 1.5 and CPython has used them internally for years - but PEP 734 is what makes them usable from ordinary Python code, with no C extension required. Each subinterpreter gets its own Global Interpreter Lock, which is the part worth testing: it is the thing that is supposed to let CPU-bound Python code actually use more than one core without reaching for multiprocessing.

    I tested it against a CPU-bound workload (counting primes below 400,000, a plain Python double loop with no C extensions to hide behind), compared against threads, processes, and a single thread, three runs each, inside a python:3.14-slim container with four cores available.

    The headline number

    approachtime for 4x the worksingle thread (1x unit, for reference)0.77 - 0.80s4 OS threads, classic GIL3.51 - 3.70s4 subinterpreters (new in 3.14)0.89 - 0.98s4 processes (multiprocessing)0.95 - 1.30s


    Four threads doing four units of CPU-bound work took more than four times as long as one thread doing one unit - 3.6s against roughly 0.8s, which is actually a bit worse than the 3.2s you'd get from perfect serialisation, because the GIL has to keep stopping one thread to let another run. Four subinterpreters doing the same four units took about 0.9s: close enough to the single-unit baseline that the extra three units of work were, for practical purposes, free. That is real parallelism, not a scheduling trick, and it lands in the same place multiprocessing already does.

    What it refuses: one thread per interpreter, not shared


    The PEP's selling point is that each interpreter has its own GIL. I wanted to see what happens when two threads try to use one interpreter's GIL at the same time, expecting it to behave like classic Python: both threads run, the shared GIL makes them take turns.

    That is not what happened. A single Interpreter object only tolerates one caller. A second concurrent call doesn't queue, and it doesn't share time with the first - it is rejected immediately:

    Exception in thread Thread-2 (_call):
    Traceback (most recent call last):
    File "/usr/local/lib/python3.14/concurrent/interpreters/__init__.py", line 226, in _call
    res, excinfo = _interpreters.call(self._id, callable, args, kwargs, restrict=True)
    concurrent.interpreters.InterpreterError: interpreter already running

    I confirmed the shape of this with three variants of the same interpreter, run in sequence:

    scenariotimeoutcomeone call0.84sfinetwo sequential calls, same interpreter1.63sfine, roughly 2xtwo concurrent calls, same interpreter0.84s wall-clocksecond call raises InterpreterError


    interpreters.create() is documented as returning "a new (idle) Python interpreter", and that word is accurate: idle or running, nothing in between. If you want N things running at once, you need N interpreters, one each. A thread pool aimed at a single shared interpreter - the pattern every ThreadPoolExecutor tutorial uses with regular threads - does not translate. You get one interpreter's worth of work and an exception, not graceful serialisation.

    The opposite number: interpreters are not obviously cheaper to start than processes


    The other assumption I walked in with was that subinterpreters, being lighter than OS processes, would be cheap to spin up. I measured the cost of creating four workers and giving each one some real state (a 200,000-element list), steady state after the first warm-up run:

    approachcreate + populate, 4 workersfork (Python 3.13's Linux default)0.037 - 0.038sforkserver (Python 3.14's Linux default)0.057 - 0.065s4 subinterpreters0.076 - 0.078s


    Creating four subinterpreters and running a small amount of code in each took about twice as long as a classic fork-based process pool, and somewhat longer than the new forkserver default too. None of this matters once the work inside each worker takes more than a few milliseconds - the 3.6s-versus-0.9s number above swallows an 80-millisecond setup cost without noticing. But it means "subinterpreters are lighter than processes" is not something I could verify at creation time; the saving, where it exists, is in not forking a second copy of the process's address space, not in any faster start.

    That forkserver row was an accident. I wrote a timing script that called multiprocessing.Process(...).start() directly from the module's top level, the way plenty of tutorial code still does, and it crashed:

    RuntimeError:
    An attempt has been made to start a new process before the
    current process has finished its bootstrapping phase.

    Checking multiprocessing.get_start_method() explained it: Python 3.14 changed the default start method on Linux from fork to forkserver. Python 3.13 reports fork; 3.14 reports forkserver. forkserver re-imports your module in the child, which is exactly the thing if __name__ == "__main__": exists to guard against, and which fork never required you to bother with. Every piece of multiprocessing code I'd written without that guard over the years happened to work by accident, on Linux, until this release. It's a one-line fix, but it is a real break, and it landed in the same release that gives you an alternative that doesn't have this problem at all.

    What it costs: closing an interpreter doesn't give the memory back


    I ran four rounds of "create four interpreters, give each a 200,000-element list, close them", watching my own process's RSS the whole time:

    round 1: 16920 -> 55648 KB
    round 2: 55648 -> 57140 KB
    round 3: 57140 -> 59476 KB
    round 4: 59476 -> 61096 KB

    .close() does finalise the interpreter - a destroyed interpreter can't be called again, and I checked that it raises if you try - but the process's resident memory never drops back to where it started. It flattens out (each later round adds less than the first) rather than growing without bound, which looks like CPython's allocator holding onto freed arenas rather than a genuine leak, but I didn't chase that further. If you're planning to cycle through many short-lived interpreters inside one long-running process, budget for that memory to stay resident, not to be returned to the OS the way a finished process's memory is.

    What's actually shareable between interpreters


    Subinterpreters don't share objects by default - that is the entire point, it's what lets them skip the GIL - so most interesting values need to cross a boundary. is_shareable() gives a yes/no answer per type:

    int -> True
    str -> True
    bytes -> True
    None -> True
    bool -> True
    tuple of ints -> True
    float -> True
    list -> False
    dict -> False

    Passing a threading.Lock as an argument to Interpreter.call() fails immediately, with the repr of the offending object right there in the message:

    NotShareableError: (<unlocked _thread.lock object at 0x7f61b8b5add0>,) does not support cross-interpreter data

    An ordinary custom class instance fails the same way, with a flatter message:

    NotShareableError: object does not support cross-interpreter data

    But the cross-interpreter Queue that the same module provides does not enforce this. I put a plain custom-class instance onto a queue and it went through without complaint, and came back out as a distinct, working object with the same attribute values - the queue silently pickles and unpickles it:

    q = interpreters.create_queue()
    q.put(Thing()) # no error
    received = q.get()
    # received is not the original object, but received.value is unchanged

    So "not shareable" is enforced differently depending on how the object crosses over. A direct argument to call() is checked against the strict shareable-types list and rejected on the spot. The same object dropped into a Queue gets the softer treatment the docs describe for put(): pickled going in, unpickled coming out as a new, unrelated object. If your code passes data between interpreters by argument, moving it to a queue instead buys you a much larger set of types - at the cost of identity and, for anything mutable, of staying in sync with the original.

    What I got wrong on the way


    My first attempt at the shareability tests put several checks in one script with no if __name__ == "__main__": guard, calling interp.call() with a mix of shareable and non-shareable arguments one after another. Running it printed every result twice, and the second copy sometimes disagreed with the first about which error got raised. My best explanation, which I didn't fully verify, is that call()'s documented pickle fallback needs to resolve names against the target interpreter's own __main__, and since that interpreter had never run my module, resolving anything defined at module level meant running the whole module there first - silently re-executing my test file a second time, inside the subinterpreter, with its own fresh state. Splitting each check into its own small script with a proper __main__ guard made every result reproducible, which is what's reported above. I'd treat any subinterpreter test that imports a lot of top-level code as suspect until it survives being run twice.

    Run it yourself


    This needs Python 3.14 and four-ish cores to see the gap clearly. I ran it in Docker because that's the fastest way to get an exact version:

    docker pull python:3.14-slim

    The core benchmark:

    # bench.py
    import time, threading, sys

    def cpu_work(n):
    count = 0
    for i in range(2, n):
    is_prime = True
    for d in range(2, int(i ** 0.5) + 1):
    if i % d == 0:
    is_prime = False
    break
    if is_prime:
    count += 1
    return count

    def run_threads(n, workers):
    threads = [threading.Thread(target=cpu_work, args=(n,)) for _ in range(workers)]
    t0 = time.perf_counter()
    for t in threads: t.start()
    for t in threads: t.join()
    print(f"threads={workers}: {time.perf_counter()-t0:.3f}s")

    def run_interpreters(n, workers):
    import concurrent.interpreters as interpreters
    interps = [interpreters.create() for _ in range(workers)]
    t0 = time.perf_counter()
    threads = [i.call_in_thread(cpu_work, n) for i in interps]
    for t in threads: t.join()
    print(f"interpreters={workers}: {time.perf_counter()-t0:.3f}s")
    for i in interps: i.close()

    if __name__ == "__main__":
    mode, n, workers = sys.argv[1], int(sys.argv[2]), int(sys.argv[3])
    {"threads": run_threads, "interpreters": run_interpreters}[mode](n, workers)

    docker run --rm -v "$PWD":/w -w /w python:3.14-slim python3 bench.py threads 400000 4
    docker run --rm -v "$PWD":/w -w /w python:3.14-slim python3 bench.py interpreters 400000 4

    And the refusal, which needs no setup at all:

    docker run --rm python:3.14-slim python3 -c "
    import concurrent.interpreters as interpreters
    i = interpreters.create()
    t1 = i.call_in_thread(lambda: __import__('time').sleep(1))
    t2 = i.call_in_thread(lambda: __import__('time').sleep(1))
    t1.join(); t2.join()
    "

    What to do with this


    If you have a CPU-bound Python workload that multiprocessing already parallelises well, subinterpreters aren't an obvious upgrade yet: on this release they start up slower than a plain fork and about the same as forkserver, and you still need one interpreter per concurrent task, with no pooling against a single interpreter. Where they're worth trying now is the code that currently reaches for a thread, because threading is simpler to wire up than multiprocessing, and then quietly gets nothing from the GIL: swap the Thread for an Interpreter.call_in_thread, and check your data either fits the shareable-types list or is willing to cross as a pickled copy through a Queue. And if you have multiprocessing code anywhere that starts a Process without an if __name__ == "__main__": guard, fix that first - 3.14 will find it on Linux even if nothing else in this post applies to you.#python #performance #programming #devops #software #coding #development #engineering #inclusive #community
    Python 3.14's concurrent.interpreters module turns a 3.6-second GIL bottleneck into 0.9 seconds

  8. “Justice is the first virtue of social institutions, as truth is of systems of thought… Each person possesses an inviolability founded on justice that even the welfare of society as a whole cannot override.”*…

    Jacques-Louis David, The Tennis Court Oath, 1790-4 (source)

    Stephen Colbert once observed that “reality has a well-known liberal bias.” And indeed, liberalism— the political/moral philosophy rooted in individual liberty, consent of the governed, and equality before the law– has been a major ideology through modern times… and, of course, the major ideology animating the founding of the United States.

    But as Easten European states turn to authoritarians, Western European nations wrestle with the rise of nationalist far-right parties, and the U.S. is “steered” by MAGA using Project 2025‘s “map,” there’s a concern that liberalism’s days may be past.

    Persuasion is running a series of essays on “Liberal Virtues and Values.”

    The series, made possible with the generous support of the John Templeton Foundation, will make the case that liberalism has its own distinctive set of virtues and values that are capable not only of responding to the dissatisfaction that drives authoritarianism, but also of restoring faith in liberalism as an ideology worth believing in—and defending—on its own terms.

    The latest installment is from Martin Gurri, who argues that Liberalism needs a new foundation (and that how we handle AI will matter fundamentally)…

    That liberal democracy is in a state of terminal decline I take to be beyond dispute. Like Alice in the rabbit hole, those of us who dwell in democratic societies suffer from a nauseating sense of falling without ever landing on solid ground. The usual suspects blamed for this tumble—populism, inequality, the economy—are mere surface symptoms of an internal breakdown. We have arrived at the conclusion of a world-historical cycle. Liberal democracy is the procedural embodiment of Enlightenment ideology—and after two centuries of dominance, that ideology has lost all purchase and stands utterly exhausted.

    Radical alternatives confront us. Either we reorient our system to post-Enlightenment principles or we risk staggering into the nihilist’s paradise I have called the Endarkenment.

    Enlightenment philosophers placed their faith in reason and science. These are purely critical disciplines: liberal propagandists wielded criticism like a scalpel to dissect conservative laggards and utopian revolutionaries alike. Once triumphant at the “end of history,” liberal democracy turned the knife on itself—a process of self-criticism and self-doubt that has shredded its own ideals to ribbons.

    The positive values inherited from the Enlightenment—equality, individualism, compassion—were always parasitic on Christianity. But Christianity, like all religions, has no place in a universe ruled by reason and science. Nietzsche long ago brought us the troubling news: the Christian God is dead. Oblivious to the implications of this calamity, liberal democracy kept marching like a cartoon character over the edge of the abyss, until the laws of moral gravity asserted themselves. So began the Great Fall.

    Criticism is a force for progress so long as there are blatant irrationalities, like slavery or Jim Crow discrimination, to overcome. But under the hammer of Enlightenment ideals, modern society has been flattened, centralized, and rationalized. Deprived of obvious superstitions to debunk and totalitarian rivals to defeat, liberal democracy has been revealed in all its internal contradictions.

    One such contradiction, I contend, pits the cherished principle of equality against the chosen few who actually practice reason and science: let’s call this the problem of the elites.

    A second contradiction finds freedom of the press and of opinion arrayed against the need to protect objective truth: call it the problem of information.

    Finally, freedom of worship and the life of the spirit collide head-on with the materialist criticism favored by Enlightenment ideology: the problem of meaning.

    Each of these contradictions could prove fatal to the democratic project, but none is insoluble, and the search for solutions offers an opportunity for renewal. While there are no guarantees, we could emerge from the crisis with a better understanding of the reach and limits of equality, a more transparent information sphere, and even, it may be, a rich infusion of the transcendental into everyday life…

    [Gurri unpacks each of those contradictions…]

    … So what is to be done?

    The first, obvious step is to move the question to the center of our shared conversations. The most capacious thinkers of the age should contemplate first principles and ultimate goals with at least as much intensity as they invest in Donald Trump or the latest economic report. There’s nothing artificial about this. Science and reason are necessary for modernity. Meaning and moral aspiration are necessary for humanity. A balance must be struck that preserves the one and gives full weight to the other.

    Materialism, we must understand, is a valuable perspective for science but not a realistic appraisal of the human condition. Scientists work as if on a geometric point, abstracted from nature and indifferent to its dispositions. In reality, however, we come from nature, we are of nature, and we are far from indifferent to our place in it. Our intuitions are internal to the system: humanity’s spiritual quest is, in every sense, nature reflecting on itself. One such intuition is agency—the belief that, at the crossroads, I am free to go right or left, and I alone make the choice. Another is faith in causation. These stances are irrational, or rather pre-rational, but without them liberal democracy as well as science itself would be impossible.

    In the end, materialism is self-defeating. To say, “I choose to be a materialist” is to fall into an absurd fallacy. Either our bodies, which consist of matter, obey unchanging laws, or the mind, transcending matter, is capable of choice. There can be no middle ground.

    Politics, in a metaphysical age, will resume its traditional place as a secondary activity—a means to an end. This will leave liberal democracy vulnerable to false prophets who are willing to trample on individual rights in pursuit of some apocalyptic scheme. The interesting question is whether the post-truth condition will make the peril greater or lesser. On the one hand, the lack of universal firewalls might make it easier for a fanatic to flood the system. Yet post-truth itself, I believe, is the strongest kind of firewall. In our fractured, eternally contested environment, the progress of any totalizing doctrine will be painfully slow. The quest for meaning and the struggle over frames of reference are, in the end, really one and the same.

    We have inherited a rich and evocative spiritual vocabulary, but it belongs to a worldview thousands of years old. “King of kings,” to cite just one example, should sound archaic in a democratic age. Can we awaken the scientific world to the spirit? Is it possible to sanctify our largely instrumental relations? This shouldn’t entail a belief in fairies and goblins, or even necessarily in religion. Any good empiricist will admit that the richest human lives are lived symbolically. Can we climb the symbolic ladder to the mountaintop, where meaning and modern humanity come harmoniously together—anchoring, it may be, a loftier understanding of equality and social life, and of the sanctity of truth?

    We won’t know until we try. Pessimism, let me suggest, is unwarranted. History moves in mysterious ways. We may be due for a second coming of historian Karl Jaspers’ “Axial Age”: preachers and philosophers who conceived a drastically updated transcendental vision, with the rational and the sacred, truth and meaning, reconciled with political freedom.

    For 200 years, we placed society under the sway of universal principles. That’s gone with the wind. We have entered an era of radical contingency, in which even truth is indeterminate. The natural tendency is to retreat to the certainties of the past—but there’s no going back. If we hope to preserve the gains from Enlightenment society, and resolve its many contradictions, we’ll have to do so within a new and wildly unstable conceptual framework.

    With the spell of the Enlightenment broken, liberal democracy will have to redefine what “created equal” means. This process could end in a rigid caste system, with the institutions in the hands of self-selected mandarins who wield the power of the state to impose their “solutions.” Preferably, and more likely given the thrust of the new technology, we’ll see a flattening of the institutions and the continued trampling by the public into the sacred spaces of politics and communication.

    Equality, however understood, will be forged in the will of the citizenry rather than granted by a benevolent God. That will make it contingent like everything else, and so liable to variation and in constant need of defense. And if perfect equality is an impossible dream, eternal inequality requires impossible discipline. The current elite class, already under enormous pressure, may lose its cohesion and melt into the impermanence of the age, divided among the various schools and sects and frames of reference.

    The structure of information will follow the definition of equality. The commanding heights will be control over AI. If AI development and deployment is a closed game, the elites could set themselves up as intermediaries in the oracle of an omniscient divinity. If AI is a competitive product, the public will gain the upper hand. In that case, we can expect a flowering of eccentric applications, the individualization of commerce and industry, and the final overthrow of the expert class. The information sphere will remain the mirror to our passions, divisions, and metaphysical longings. Freedom of speech, no longer “endowed by our Creator,” will become the battleground on which the question of equality is ultimately settled.

    Here I finally reveal myself in my true colors. I’m an analyst. My task is to describe reality, and that’s what this essay is about. But I also lead an active life inside the world that I’m describing—and I have preferences. I see equality as a factor of opportunity, law, and human dignity, not of perfect outcomes. I think truth emerges from examining a subject from a large number of perspectives, even those that may seem disturbing or false. I hope that my story—as a person, a father, a grandfather—connects to other stories in the past and will connect to more in the future, in a pattern that is not entirely devoid of meaning. And I believe fervently in liberal democracy, because—born in Cuba—I have tasted the alternative.

    The breakdown of Enlightenment ideology is only the latest challenge liberal democracy has faced in my lifetime. I’m not entitled, as an analyst, to downplay the perils ahead, but I’m allowed, as an American, to have faith that they will once again be overcome…

    Eminently worth reading in full: “The Search for a Post-Enlightenment Democracy”

    * John Rawls

    ###

    As we renew, we might send free-thinking birthday greetings to Henri-Benjamin Constant de Rebecque (or as he’s usually called, Benjamin Constant); he was born on this date in 1767. A French political thinker, activist, and writer on political theory and religion (whose work influenced, among many others, Sir Isaiah Berlin), Constant was a committed republican from 1795, backing the coup d’état of 18 Fructidor in1797, and the following one on 18 Brumaire, in 1799. He became the leader of the Liberal opposition in 1800, during the Consulate. Constant fell out with Napoleon, and had to flee (first to Switzerland, then to Saxony). Nonetheless, after his return to France, Constant sided with the Emperor during the Hundred Days, drafting the Charter of 1815. He became politically active again during the Bourbon Restoration and was elected to the Chamber of Deputies in 1818 (where he remained until his death in 1830). As the head of the Liberal opposition, known as Indépendants, Constant was one of the most notable orators in the Chamber, especially in his role as a proponent of the parliamentary system.

    Portrait of Constant by Hercule de Roche, c. 1820 (source) #authoritarianism #BenjaminConstant #culture #democracy #Elites #Enlightenment #FrenchHistory #history #illiberalism #information #liberalism #MartinGurri #meaning #moralPhilosophy #Napoleon #philosophy #politicalPhilosophy #religion
  9. The tech industry has a strange contradiction right now.
    Companies are investing billions in artificial intelligence, building new platforms, shipping increasingly sophisticated products, and talking about unprecedented productivity gains.

    At the same time, thousands of developers, engineers, designers, QA specialists, and other technology professionals are facing an uncertain future.

    According to TechRepublic's October 2026 tech layoffs report, nearly 200,000 people had been affected by reported technology-sector layoffs as of October 23.

    That number is difficult to ignore.

    But behind every headline is a more personal question:

    How do you build a sustainable career in an industry that keeps changing the definition of valuable work?

    Let's look beyond the headlines and explore what these layoffs mean for developers, why AI isn't the whole story, and how we can prepare for an increasingly unpredictable technology landscape.

    1. The Layoffs Aren't Just Numbers on a Dashboard

    When a company announces a workforce reduction, the news is usually presented through percentages, headcounts, and stock-market reactions.

    For the people affected, the experience is very different.

    It's the developer who spent five years maintaining a critical service.

    It's the QA engineer who prevented production incidents nobody outside the team ever noticed.

    It's the infrastructure specialist who kept systems running during the most difficult outages.

    It's the junior engineer who finally landed their first job after months of interviews.

    These professionals don't suddenly lose their knowledge, experience, or ability to solve problems when their employment ends.

    Yet a layoff can make even experienced engineers question their value.

    One important distinction is worth remembering:

    A company eliminating a position does not automatically mean the person occupying it lacked value.

    Organizations restructure for many reasons, including financial pressure, acquisitions, overlapping responsibilities, strategic changes, and shifting investment priorities.

    Some reductions are connected to AI. Others aren't.

    For developers, understanding that distinction matters. Otherwise, it's easy to interpret every layoff as evidence that a particular skill or career path has become obsolete.

    The reality is more complicated.

    2. Is AI Replacing Developers, or Changing What Developers Do?

    This is probably the biggest question in software engineering right now.

    AI coding assistants can generate boilerplate, suggest implementations, explain unfamiliar code, create test cases, and help developers explore possible solutions.

    These capabilities are useful. Ignoring them entirely isn't a particularly strong career strategy.

    But the conversation becomes less useful when we reduce everything to a simplistic prediction: AI will either replace all developers or never replace any of them.

    Neither assumption helps us make better decisions.

    Consider a typical feature request.

    An AI tool might help generate an API endpoint in minutes. However, delivering that feature safely may still require someone to:

    Understand the business requirements and identify missing assumptions.

    Design the API contract and choose appropriate data models.

    Evaluate authentication, authorization, and data privacy risks.

    Test edge cases, failure modes, and unexpected inputs.

    Review database performance and concurrency behavior.

    Integrate the feature with existing services and deployment pipelines.

    Monitor production behavior and investigate incidents.

    Generating code is only one part of delivering reliable software.

    The challenge is that AI can make some tasks faster while also changing how much work a team needs to complete them.

    That can create real workforce pressure, particularly when organizations expect smaller teams to deliver more.

    And there's an important caveat: AI adoption and layoffs happening at the same time do not prove that AI directly replaced every affected employee.

    TechRepublic's reporting highlights this distinction. Some companies have explicitly connected restructuring to AI-focused strategies, while others have cited different organizational or business reasons.

    For developers, the practical takeaway isn't to panic or dismiss AI.

    It's to learn where these tools are useful, understand their limitations, and become better at the engineering decisions surrounding their output.

    3. The Real Competitive Advantage Is Engineering Judgment

    If AI can generate a plausible implementation, what makes an experienced developer valuable?

    Increasingly, the answer is the ability to determine whether that implementation is actually correct, maintainable, secure, and appropriate for the problem.

    Imagine an AI assistant generates a database query that works perfectly against a small development dataset.

    Will it still perform well when the production table contains 200 million records?

    What happens when two requests update the same resource simultaneously?

    Could the query expose information that the requesting user isn't authorized to see?

    Does the implementation introduce a subtle regression in another service?

    These aren't merely code-generation problems. They require engineering judgment.

    The same principle applies to testing.

    A test suite can report 95% code coverage while missing the business-critical scenario that causes a production outage.

    A generated test can confirm that a function returns the expected result without checking whether the result itself makes sense.

    A passing build doesn't guarantee a reliable system.

    This is where developers can differentiate themselves.

    Focus on capabilities that help you reason about the entire system:

    System design: Understand service boundaries, data flows, failure modes, and trade-offs.

    Debugging: Trace problems across application layers rather than guessing at isolated symptoms.

    Testing: Design meaningful assertions, boundary tests, integration tests, and failure scenarios.

    Security: Recognize vulnerabilities that aren't obvious from a successful demo.

    Performance: Understand latency, throughput, resource consumption, and scaling constraints.

    Communication: Explain technical decisions and their consequences to people with different backgrounds.

    These skills aren't immune to automation. AI can assist with many of them.

    Their value comes from knowing how to apply them, verify results, and take responsibility for the outcome.

    4. Stop Measuring Your Career by the Number of Technologies You Know

    When layoffs dominate the news, it's tempting to respond by learning everything.

    A new framework appears, so you learn it.

    A new AI tool launches, so you try it.

    A new programming language becomes popular, so you add it to your list.

    Soon, your learning backlog becomes larger than any project you could realistically finish.

    The problem isn't curiosity. It's confusing exposure with capability.

    Knowing that a tool exists is different from being able to use it to solve a meaningful problem.

    Instead of collecting technologies, build evidence of your engineering ability.

    For example, rather than creating five small repositories that demonstrate basic syntax, consider building one application that includes:

    A documented API with authentication and input validation.

    Automated unit and integration tests.

    Database migrations and realistic test data.

    Logging, metrics, and useful error handling.

    A CI pipeline that runs checks before deployment.

    A deployment strategy with a documented rollback procedure.

    A README explaining architecture decisions and known limitations.

    This project gives you more than a list of technologies.

    It demonstrates how you approach the complete software development lifecycle.

    If you use AI to build parts of it, document where you used it, how you reviewed its suggestions, and what you changed after testing.

    The goal isn't to pretend you wrote every line manually.

    The goal is to demonstrate that you can deliver software responsibly.

    5. Build a Career That Doesn't Depend on One Employer

    A layoff can be especially disruptive when nearly all your professional identity, network, and sense of security are tied to a single company.

    You can't eliminate that risk entirely, but you can reduce your dependence on any one organization.

    Start by keeping your professional portfolio current.

    You don't need to publish confidential company code or turn every weekend into a side-project marathon. You can document open-source contributions, personal projects, technical articles, or lessons learned from problems you've solved.

    Next, maintain professional relationships before you need them.

    Talk with former colleagues. Participate in technical communities. Share useful findings. Review other people's code. Contribute to discussions where you can genuinely help.

    Networking works better when it isn't treated as an emergency activity that begins the day after a layoff.

    Also, periodically review your accomplishments.

    Don't just record that you worked on a service. Record what changed because of your work.

    Examples include:

    Reduced API latency by identifying an inefficient database query.

    Improved release confidence by introducing integration tests.

    Reduced incident investigation time by improving observability.

    Simplified a deployment pipeline and removed manual steps.

    Identified and resolved a security weakness before release.

    Use real measurements when available. Never invent metrics to make a résumé look impressive.

    These examples help communicate the value of your work beyond a job title or list of responsibilities.

    Finally, if circumstances allow, build some financial breathing room. Even a modest emergency fund can create options when a job search takes longer than expected.

    Career resilience isn't only about technical skills. It's also about having choices.

    6. Don't Assume Every Company Is Hiring for the Same Kind of Developer

    A headline about thousands of job cuts at a major technology company can make the entire industry look closed.

    But company-wide reductions don't tell the whole story about individual teams, occupations, or hiring needs.

    A company can reduce its overall headcount while continuing to recruit for selected roles. Another company may be expanding its engineering organization while a competitor contracts.

    That doesn't mean finding a job is easy. It means the available evidence needs to be interpreted carefully.

    When researching opportunities, look beyond the employer's brand name.

    Investigate the specific role, team responsibilities, required experience, and business context.

    Ask questions such as:

    Is the role associated with a core product or a short-term initiative?

    What problems will the team be expected to solve?

    How does the company measure engineering quality?

    Is the position new, a replacement, or part of an expanding team?

    What expectations does the employer have around AI-assisted development?

    How does the team handle on-call responsibilities, technical debt, and production incidents?

    During interviews, pay attention to how people describe the work.

    An organization that expects developers to use AI responsibly, review code carefully, and understand production systems may offer a different engineering environment from one that measures productivity primarily by the number of tickets closed.

    No interview can guarantee job security.

    However, understanding the role helps you make a more informed decision than relying on a company's reputation alone.

    7. Junior Developers Need a Different Strategy, Not a Reason to Give Up

    For people entering software development, the current environment can feel particularly discouraging.

    Entry-level positions often require practical experience, but gaining that experience can be difficult without an initial opportunity.

    AI adds another layer of uncertainty because some of the tasks traditionally assigned to junior engineers can now be automated or completed more quickly.

    Still, the conclusion shouldn't be that learning to code is pointless.

    Instead, aspiring developers should focus on demonstrating that they understand the fundamentals rather than simply knowing how to prompt a coding assistant.

    Learn how data structures work. Understand HTTP, databases, version control, testing, and debugging. Practice reading unfamiliar code and explaining why a solution works.

    Then use AI as a learning partner.

    Ask it to explain an unfamiliar implementation. Request alternative approaches. Generate test cases and investigate whether they are correct. Compare its output with official documentation.

    Most importantly, practice solving problems without blindly accepting generated answers.

    Build projects that solve real problems, however small. Contribute documentation or bug fixes to open-source projects. Collaborate with other developers. Learn to discuss trade-offs and explain decisions clearly.

    Your first opportunity may take longer to find than you expected.

    That delay doesn't make the effort meaningless, and a difficult job market doesn't determine your long-term potential.

    8. What Engineering Teams Should Learn From These Layoffs

    This discussion shouldn't be limited to individual career advice.

    Engineering leaders also have responsibilities.

    If an organization reduces its workforce and expects the remaining team to maintain the same systems, deliver more features, and adopt unfamiliar AI tools immediately, the result can be increased pressure rather than improved productivity.

    Fewer engineers don't automatically mean less work.

    Someone still needs to maintain legacy systems, investigate incidents, review generated code, manage dependencies, and understand architectural decisions made years earlier.

    If that knowledge leaves with departing employees, the organization may lose capabilities that are difficult to rebuild quickly.

    Teams should therefore pay attention to:

    Knowledge preservation. Document critical systems, operational procedures, and architectural decisions before organizational changes create gaps.

    Quality controls. Establish clear expectations for testing, code review, security checks, and AI-generated contributions.

    Realistic capacity planning. Measure delivery outcomes and system reliability, not just the number of tasks completed.

    Sustainable ownership. Make sure critical services have adequate support and aren't dependent on one remaining engineer.

    Responsible AI adoption. Evaluate tools against real engineering workflows, including their costs, limitations, security implications, and effect on review effort.

    The goal should be to improve the way teams build and maintain software, not simply to make smaller teams absorb more responsibilities.

    9. A Practical 30-Day Plan for Developers

    You don't need to reinvent your entire career because of a difficult news cycle.

    A focused month can help you identify gaps and make tangible progress.

    Week 1: Audit your current skills

    Choose a technical area relevant to your goals. Review your recent work and identify what you can demonstrate confidently versus what you only know in theory.

    Update your résumé with specific, truthful accomplishments.

    Week 2: Strengthen one practical skill

    Choose a skill that supports your existing experience, such as API testing, database performance, cloud deployment, observability, or secure coding.

    Build a small exercise that forces you to apply it rather than just watch tutorials.

    Week 3: Complete and document a project

    Finish a useful improvement or small end-to-end application. Add automated tests, clear documentation, and a short explanation of your design choices.

    If you use AI, verify its output and document meaningful limitations you discovered.

    Week 4: Improve your professional visibility

    Publish a technical article, contribute to an open-source project, share a useful debugging lesson, or reconnect with former colleagues.

    Review relevant job descriptions to identify recurring requirements, then compare them with your current experience.

    At the end of the month, evaluate what you accomplished.

    You may not have a new job, a perfect résumé, or mastery of a new technology. That's fine.

    The objective is to build momentum and make your next step more deliberate.

    Final Thoughts: Your Career Is Bigger Than This Year's Headlines

    The 2026 layoffs are a serious reminder that working in technology doesn't guarantee employment security.

    They also highlight the need to think carefully about AI, organizational change, and the skills that help engineers deliver reliable software.

    But there's a difference between recognizing that the industry is changing and assuming that your future has already been decided.

    You don't control every restructuring decision. You can't predict which company will announce cuts next. You can't guarantee that mastering a particular framework will protect you from a difficult job market.

    What you can control is how you learn, how you demonstrate your abilities, how you adapt to new tools, and how you build relationships with other people in the industry.

    Don't compete with AI at generating code faster. Learn to build better systems, ask better questions, verify results, and solve problems that matter.

    And remember that your worth as a developer isn't measured by a company's headcount spreadsheet.

    The industry will continue to evolve. Our task is to keep learning without losing sight of the human judgment, collaboration, and responsibility that good engineering requires.

    Let's discuss

    I'm curious how other developers are navigating this period of change.

    AI and engineering: Has AI meaningfully changed the way you write, test, or review code?

    Career resilience: Which skills do you believe are becoming more valuable as teams adopt AI tools?

    Hiring: Are you seeing different expectations for junior, mid-level, and senior developers?

    Team culture: What can engineering leaders do to help teams adapt without sacrificing software quality or employee well-being?

    Share your experiences in the comments. Practical insights from people doing the work are often more useful than another prediction about the future of tech.

    Editorial note: This article is an independent, developer-focused perspective inspired by TechRepublic's reporting on 2026 technology layoffs. Layoff totals reflect reported announcements, not necessarily completed job losses. Figures and company circumstances can change as new information becomes available.#discuss #career #ai #programming #software #coding #development #engineering #inclusive #community
    Tech Layoffs in 2026: What Developers Should Do When the Industry Changes the Rules

  10. Aptivi Weekly Tech News Issue #21 (Week 43 – 10/24/2026)

    Every week, we collect every event that happened within Aptivi, our projects, and other interesting tech news. This issue shows you the brief summary of our project releases and some of our articles posted on the Aptivi Blog and on the Newsroom, as well as some links to other interesting resources, such as the most intriguing tech news during the week.

    As technology evolves quickly, we have to move quickly with the current to make sure that we don’t miss any of the interesting technology-related events, such as new releases and other interesting events that revolutionize the tech world.

    What happened at Aptivi?

    During this week, sets of events have happened at Aptivi, and we have chosen to summarize some of the most intriguing events that we have covered here at Aptivi Blog and Aptivi Newsroom, as well as other Aptivi updates in case they happen.

    Linux 7.3 was officially available as a general release after seven release candidates.

    Samsung started globally rolling out the One UI 9.0 update for the Galaxy A37 and the Galaxy S23, starting from Europe. Additionally, the stable update had landed to the LTE version of the Galaxy A07, starting from countries like Indonesia and the Philippines. Additionally, Samsung has prepared the new One UI 9.0 Watch Beta for the Galaxy Watch8 and Watch7.

    Additionally, you can check out this week’s issue of Linux Weekly Digests in this link.

    There are some other updates that happened with Aptivi. We have announced our first big milestone that will happen on November 5th, which is a big leap since our major rebrand that happened back in February. Meanwhile, we’ve officially started supporting our projects that run on One UI 9.0, which is based on Android 17.

    Most intriguing tech news

    Here, we collect some of the most intriguing news that caught our attention, and our readers can explore this list below:

    Please note that the order of events are listed in the descending order from the newest to the oldest.

    Summary

    This week, Aptivi started providing official support for those who are using projects on Android phones and tablets running One UI 9.0, while announcing a big release date on November 5th.

    In the other hand, Linux 7.3 was available as a general release after seven release candidates, and Samsung started pushing One UI 9.0 for the Galaxy S23, Galaxy Z Fold/Flip5, and A37 globally, as well as the Galaxy A07’s One UI 9.0 in countries like Indonesia and the Philippines.

    So, thank you to whoever read our posts, liked them, and commented on them, whether it’s on the Fediverse or not. We appreciate your interaction, engagement, and support, and this motivates us into going ahead moving forward.

    #news #Tech #Technology #update #Weekly #WeeklyNews
  11. SMS2Email, l'app che inoltra gli SMS alla vostra email

    @[email protected]

    SMS2Email è una piccola app Android open source che inoltra automaticamente ogni SMS ricevuto a un indirizzo email, usando il vostro server SMTP.

    #UtilizzoQuotidiano #Android #App #Opensource

    blog.lealternative.it/2026/10/

  12. Dall'archivio di Cassandra/ Internet, il Vaticano ed i pedofili

    @[email protected]

    Il vespaio suscitato dal servizio della BBC spinge alcuni politici a chiedere prudenza, vista la posta in gioco. Quella prudenza che non viene riservata alla rete, ovvero a una posta ben più alta.

    #CassandraCrossing #Chatcontrol #Privacy #Internet

    blog.lealternative.it/2026/10/

Share on Mastodon

Enter the server where you have an account.