plq

They have a computation to do, and they want to do it using a particular instruction. That's the only reason they are fiddling with the compiler. You would have to do so too, if you had decided to solve a problem at hand using a similar method.

The author is talking about a way to get a particular (version of) C/C++ compiler to emit the desired instruction. So I'd call this clang-18.1.0-specific but not C/C++-specific since this has nothing to do with the language.

Also such solutions are not portable nor stable since optimization behavior does change between compiler versions. As far as I can tell, they also would have to implement a compiler-level unit test that ensures that the desired machine code is emitted as toolchain versions change.

> The whole idea of the internet (and even some of our infra, like suburbs or highways/rail) is that there's no one single point of failure. Like designed-to-survive-nuclear-war redundant.

Sure, the routing algorithms can quickly adapt to changes in network topology, but they assume infinite bandwidth, which hasn't been the case since a long time now.

In other words, if a couple of important pipes disappear between tier1 peers, alternate routes will certainly have trouble handling all the new traffic, which would make everything grind to a halt, and will only be solved by pissed network admins null-routing that additional load.

Sqlite calls this an "amalgamation" build

Details here: https://sqlite.org/amalgamation.html

It's also touted as an easy way to embed sqlite.

Perhaps I am not making myself clear here:

- RefCounted: It's like shared_ptr but refcount load/modify/store operation is not atomic, thus not thread-safe. No synchronization for pointed data.

- RefCountedThreadSafe: It's like shared_ptr. This means refcount load/modify/store is atomic, so has overhead, yet safe to pass across thread boundaries. Again, just like shared_ptr, no synchronization for pointed data.

- Locker class above: It's an (incomplete) wrapper around shared_ptr where read-only access goes through a shared lock and rw access goes through an exclusive lock. I suppose this is what rust's ARC guarantees at compile-time with less overhead the sketch above?

So;

> Both are true, Rust just has more restrictions.

No, both are not true, my understanding of ARC ~= Locker && ARC > shared_ptr

You say:

> Rust `Arc` = C++ `std::shared_ptr`

GP says:

> Rust requires shared pointers (Arc) to also explicitly implement some sort of Mutex-equivalent runtime safety check in order to mutate the data.

Which is it?

> An example of a big C++ codebase using something similar is Chromium ...

Chromium's smart pointers are similar to their standard counterparts -- no mutexes for write access to pointed data.

Also, tangent but interesting: From https://www.chromium.org/developers/smart-pointer-guidelines...:

> Reference-counted objects make it difficult to understand ownership and destruction order, especially when multiple threads are involved. There is almost always another way to design your object hierarchy to avoid refcounting

So ARC is something like the following?

    template <typename T>
    struct Locker {
        using M = std::shared_mutex;
        struct Locked {
            Locked(mtx, value) : m_lock(mtx), m_value(value) {}
            // operator->, operator*, get, etc.
        private:
            std::lock_guard<M> m_lock;
            std::shared_ptr<T> m_value;
        };

        struct Shared {
            Shared(mtx, value) : m_lock(mtx), m_value(value) {}
            // operator->, operator*, get, etc.
        private:
            std::shared_lock<M> m_lock;
            std::shared_ptr<const T> m_value;
        };
    
        Shared shared() { return Shared{m_mutex, m_value}; }
        Locked locked() { return Locked{m_mutex, m_value}; }

        // a nice forwarding ctor that prevents null m_value

    private:
        std::shared_ptr<T> m_value;
        M m_mutex;
    };

First, here's the actual guide: https://google.github.io/styleguide/cppguide.html#Names_and_... . Of course they still have to use stuff like #include <windows.h> but it's very very limited.

They also are not removing any info -- most of it IS project headers. To me that's the actual bonkers bit :)

With GCC/Clang, headers found in paths passed with -isystem are headers that are immune to compiler arguments like -Werror because they are, by definition, out of your control. In Google's case, ALL code is already checked in the project repo, including language stdlib. So none of them are system headers "per se".

In the chromium repository, the use of angle brackets in #include statements is banned -- they only use double quotes. They also don't use any system headers per se since their flavor of clang comes with their flavor of libcpp vendored in.

So if the chromium repo is representative of the state of C++ in rest of Google, they ditched it silently like this probably because it's so natural to them :)

The title actually means "How do GPS receivers receive signals from the GPS satellites?" It's not about other satellites communicating with GPS satellites.

TL;DR: They use special-purpose antennas.

> Is there any plan from rds to offer it?

I don't think so because Microsoft bought Citus.

It's just a regular 4G phone. They got LTE base stations up on the satellites. Actually, I'm not that surprised that they got the downlink working but I also would love to learn abut the challenges they faced while trying to receive a clean signal from a regular cellphone 600+km away.

Cellphones' transmit power is severely limited due to a) proximity to human brain b) battery considerations.

I imagine it also requires a clear view of the sky. That's how any satellite phone tech I ever laid hands on worked. I'd be astonished if they got it also working indoors. That'd be just pure magic.

https://www.starlink.com/business/direct-to-cell

https://arstechnica.com/gadgets/2023/10/spacex-details-starl...

EDIT: Just to be clear, the link says nothing about the return channel but I imagine they wouldn't have made this announcement unless they got the return channel working as well.

Photos remind me of Pamukkale[1], though Dallol seems to be more colorful.

https://en.wikipedia.org/wiki/Pamukkale

I develop using these on Linux for Windows. The current version (2311) is not usable on Virtualbox (see known issues towards the end) so we are still sticking to version 2210 (it's expired but slmgr /rearm works)

Reinstalling it every couple of months is not much of a problem if you have a provisioning script. I actually like to do it that way because keeps bloat to a minimum.

You make it sound like it's one of the laws of physics.

ON part of JSON doesn't know about objects. When serialized, object entries are just an array of key-value pairs with a weird syntax and a well-defined order. That's true for any serialization format actually.

It's the JS part of JSON that imposes non-duplicate keys with undefined order constraint.

You are the engineer, you can decide how you use your tools depending on your use case. Unless eg. you need interop with the rest of the world, it's your JSON, (mis)treat it to your heart's content.

Symbol tables, compression, etc seem one level of abstraction above what msgpack provides. Such features could be implemented on top of vanilla msgpack as long as all parties agree on the msgpack schema.

Sorry I wasn't clear -- my point was that a typical python programmer won't be able to troubleshoot these bits -- it'd be way outside their skill set.

Before anyone jumps in to say nobody ever has/will ever have to troubleshoot this because it's so stable and used everywhere and so forth, please have a look at the comments at the top of that file. This code had to be patched eg. due to a compiler update.

Remember, this is open source and this code is offered without any guarantees. And non-existing guarantees of greenlet/gevent is quite different from the non-existing guarantees of CPython (no idea about PyPy).

Implementing cooperative multitasking at this level is way off the beaten path and should only be attempted by those who know what they are doing.

Today, I'm sure this code works perfectly on linux 6.4.7 when compiled by gcc 12.3.1 against python 3.10 on amd64 architecture in release mode. But can you guarantee it will it work on linux 7.8.17 when compiled by gcc 15.2 against python 3.21 on AARCH64 10.4 architecture? No you can't. If you are lucky, it'll just die with a general protection fault or something. But it can also break in subtle ways that only a seasoned systems programmer can realize, let alone fix.

So if you are a professional, you care about maintainability, you care about forward compatibility, you are starting a greenfield project, you are sure you need cooperative multitasking and you ask nicely my opinion about which async framework you should choose, I would strongly advise you to steer clear of gevent/greenlet based libraries.

Or, you know, just hack away :)

Here's the said black magic (for amd64/unix) that the gevent project relies on:

https://github.com/python-greenlet/greenlet/blob/master/src/...

I still think it's too much for a Python project -- if you think you need this in 2023, maybe you need to reevaluate? I'd seriously have another look at Go.

returnValue raises a specific exception that inlineCallbacks understands and translates to a normal return value. It was a hack that was only needed for python versions that couldn't have generators return non-None values. With modern versions, you don't need it anymore -- just use return.

I think JAR (Java Archive) and WAR (Web Archive) make sense.

But wheel? It's a wheel of cheese, because pypi used to be called cheeseshop? I mean sure, but doesn't it feel a bit like that 20-year-old tatoo that you got during your teens that you got mixed feelings about today?

My suggestion: Call them pypacks -- extension: .pyp

Can't plus-one this enough. The Gentoo [installation] handbook is a true treasure for the linux newbie.

Especially if you are the kind of learner who needs to be challenged to truly ingest the material at hand, just read every word and apply what you have learned. You'll be astonished by the distance that you covered in a month!

Whenever Gentoo is brought up, somebody always brings up LFS.

LFS becomes repetitive fast. I also don't think trying to use esoteric build systems that come with cryptic readme files is newbie-friendly. Just learn to read ebuild scripts if you are after that kind of skill :)

It's just a guess but this sounds like a physical machine with threadripper 3970x (128gb memory is the max it can handle without memory bandwidth contention) though I'm also curious about the details.

... and hugged to death

https://archive.li/yl7z2

This is only a tangent given we are talking about snapshots and reflink, but just wanted to mention that LVM has snapshots, so if you need XFS snapshots, create the XFS filesystem on top of an LVM logical volume.

Thanks! Still learning my way around the fmt library.

> What's wrong with std::regex?

In my experience, stdlibc++ <regex> is VERY slow, especially on debug builds. We are using g_regex instead, which in turn uses pcre2.

> And iostreams

<iostream> achieves too little with too much code. We instead use:

    std::cout << fmt::format(...);

for simple output, loguru[1] for everything else. I feel like the fmt grammar/mini-language is both nicely extensible and has hit the expressiveness sweet spot -- not too verbose (iostreams) nor too terse (printf).

I also like that fmt has helpers for pointers (fmt::ptr), enums (fmt::underlying) and arrays (fmt::join). It's both easy on the eyes and feels consistent.

[1]: https://github.com/emilk/loguru

> Android isn't quite Linux

If we're being pedantic, let me be clear that Android is Linux. It just doesn't use the traditional userland, mostly implemented by GNU. So it's Linux but not GNU/Linux.

I know it's not free software, but I find the Jolla/Sailfish phones, the spiritual successors to the OS of the N9, a decent tradeoff between freedom and usability. It even runs android apps!

Man, what a masterpiece, even the title gives me chuckles :) Thanks for bringing it up

Last I looked, BoringSSL[1] was a drop-in replacement for 1.1, as long as:

1. Your usecases intersect with Google's (they removed bunch of stuff during the initial forking phase).

2. You can handle the following:

   > Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

[1]: https://boringssl.googlesource.com/boringssl/

Hey, I just would like to let you know that DistCC always has a special place in the hearts of loyal Gentoo users like me :) Kudos!