I drank the Erlang Kool-Aid around the same time this was published. In 2013 I worked for a company that had a few Erlang services (as well as some JVM services, a mix of Scala and to a lesser degree Java).
One thing I was tasked with was replacing the ingress data collector. One of the limitations of Erlang at the time was that all SSL termination was funneled through a single core. Once the Java replacement was deployed, we saw a massive decrease in latency, the p95s and p99s especially, and all the weird operational overhead of trying to understand what the Erlang VM was doing at any given moment.
Say what you will about Java and the JVM, but it's a fantastic platform for reasonably high performance servers. Erlang might have a lot of claims for high concurrency and scalability, but practically I've had considerably more success with the JVM.
I haven't touched Erlang since 2013, so in the intervening 11 years I can only hope that it has gotten better. Though I have zero interest in trying it again.
> 100% they would pay a lot of money to be able to hang out with Joe Rogan, or some only fans person, and those pornstars or podcasts hosts will never disagree with them, never get mad at them, never get bored of them, never thing they're a loser, etc.
This is the stuff of Brave New World. It's happening to us in real time.
I inherited a go project that has two different commands under `cmd`, and it seems when I run this against one of those `main`s, it incorrectly detects what it thinks as dead code that is used in the other command.
YouTube TV injects ads on certain content. I know it's there for on-demand TV shows, and some live sports. It's literally overlaid on top of the channel's ads in the live example.
I think years ago when I first subscribed one of the major benefits was the ability to skip through these ads just like DVR, but you can no longer do that.
Cable TV broadcasts include both the network's ads and slots for the carrier to run their own ads. They're not inserting bonus ads on top of the actual content. Again, this is exactly the same as any cable provider has always worked.
We don't have a choice. That's how cable works, and YouTube TV exists for those of us who need it. They can't magically create an ad free broadcast of TNT or something. How would that even work?
You don't have to like broccoli but it'd be weird to complain that it doesn't taste like chocolate.
> The name "Slashdot" came from a somewhat "obnoxious parody of a URL" – when Malda registered the domain, he desired to make a name that was "silly and unpronounceable" – try pronouncing out, 'h-t-t-p-colon-slash-slash-slashdot-dot-org'".
I really do mean the root directory! As in, a kinda joke that meant the site was a central place for news, so it would act as a root directory for that
It’s virtually impossible to do free threading safely, especially with large codebases developed by multiple people. This includes tiny Python scripts that pull in a bunch of dependencies.
It’s like saying that C is a safe language, just “get good” at it.
There are safe alternatives such as structured concurrency.
Rust is a brilliant lesson in using traditional threading safely. It uses & for thread-shared types and constrains &mut to a single thread, which naturally causes people to keep single-threaded data on an object only accessible from a single thread, and make multithreaded data either immutable, mutex-protected, or atomic.
Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are another way to approach concurrency or parallelism.
In my experience with multi-threaded programming, C++ code with "careless sharing issues" is often filled with multiple threads accessing the same object and relying on convention to avoid calling the wrong thread's methods, pervasive data races and unsynchronized variable access, mistaken use of mutexes on only one side of shared memory, and logical race conditions that require adding mutexes (risking deadlock) or rewriting code to address. Whereas Rust code tends to not have these issues to begin with (outside of the implementation of synchronization primitives), store reader and writer methods on separate handle objects, use Arc to manage cross-thread shared memory, and similar which makes the code either correct or tractable to learn and make correct.
I also struggle to understand the threading model of COM and C libraries like libusb (https://libusb.sourceforge.io/api-1.0/libusb_mtasync.html), though that might just be me, and each library tends to have a different threading model. Rust's Send/Sync is a 90% solution which you can learn upfront, is checked by the compiler, and applies to all libraries and works for most use cases.
> In my experience with multi-threaded programming, C++ code with "careless sharing issues" is often filled with multiple threads accessing the same object and relying on convention to avoid calling the wrong thread's methods
Right, I can see the kind of codebase you're referring to.
I don't see Rust as a magical weapon solving concurrency issues though. Namely because Rust (the compiler) has a very limited view of what happens in the lifetime of a multithreaded system, and no view at all of the lifetime of a multiprocess system.
Even when writing purely single threaded Rust, you quickly end up having to let go of the strictly static memory sharing checks and switch to dynamic ones.
I have yet to find a use case where Rust solves anything but the most blatant synchronization issues.
I'm not sure how far the author has gone, but they should check out Gorilla compression[1] (just the compression part, not the whole database). It works well for time-series data, and might be suitable here? Basically if your numbers don't deviate massively--think of a CPU metric that stays in the same place throughout the day, inside the bounds of 0-100--the compression is really effective.
Clickhouse supports Gorilla and some others[2] that might also be of use.
Gorilla is XOR compression which is better for timeseries where the metrics change smoothly from one to the next point, because it just XOR checks against the previous value.
Floats should really not be thought of as byte streams, instead they are 3 bit fields in a single word. Sign, mantissa, exponent split up into 3 streams compresses way better than them all together. At that point you are just dealing with "how to compress integers" which is much simpler problem.
I played with zstd and it compresses way better if you take 8 float64 and shuffle bits side ways. This is a trick that blosc popularized [1].
Adding a shuffle filter ahead of the zlib or zstd worked way better for reducing the size of the data when dealing with float streams. This does group the bits in a similar fashion to splitting up the floats into components, but is much simpler on the decode path with SIMD.
Sadly, we were forced to dissolve PDPC, freenode’s parent organisation.
When the organisation transferred across from the US to the UK we wanted to keep the organisational structure as close to what it had been before (change is scary, right?) — however, we made the conscious decision to no longer have any paid employees after Rob Levin passed away. This meant that everyone involved with the organisation were volunteers and we no longer had anyone who could invest the time and effort required to do fundraising and similar tasks, meaning that the organisation was unable to sustain the levels of donations required to obtain and maintain charitable status in the UK.
Due to the massive reduction in financial support we found ourselves in a position where being an incorporated organisation cost more than what we were able to bring in in donations and after years of operating at a loss it was decided that we would apply for the dissolution of the corporation in order to drastically reduce costs. The application has been processed and the organisation has been dissolved; to further reduce costs we have also discontinued the majority of infrastructure services for which the organisation paid, together with the reduced administration and organisational fees this means that we are now in a position where our outgoings are restricted to domain renewals! We would like to thank everyone who has contributed to the organisation in the past, users, organisations and staff in particular, who have always been (begrudgingly?) happy to contribute towards the difference in order to cover the deficit.
What does this organisational change mean for freenode?
In practise it means very little, the PDPC has never been involved in the day to day operations of the network and there will be no changes to the way in which the network is run. freenode is staffed entirely by volunteers from all over the globe who contribute their time and expertise to keep the network up and running in between contributing to various other FOSS projects.
What about other PDPC projects, such as fosscon, geeknic, and the fossevents site?
These projects will continue as they have before, and we invite you to attend fosscon for real world talks and collaboration, to join a geeknic picnic or plan your own at http://geeknic.org, and to check out http://fossevents.org for events in your neighbourhood and around the world.
I appreciate the work you do and I still want to contribute
The best way in which to help the network is to contribute time — help out in #freenode or elsewhere on the network, assist users in finding answers to their questions and help us try keep the channel and network temperature at a nice, comfortable level which encourages collaboration!
If you are low on time but still want to help out you might be able to help us through your company or organisation by becoming a server sponsor (See “Hosting a server” for more information).
If you feel that one particular volunteer has helped you out and you want to say thank you — ask them if they have a preferred charity to which you could make a small donation! With time we might update our website to provide links and information of such preferences.
Alternatively, you may consider donating to one of the following projects:
Software Freedom Law Center
Electronic Frontier Foundation
Open Rights Group
Existing PDPC donor cloaks
Existing PDPC donor cloaks will remain valid for a full year, after which they will be converted to unaffiliated cloaks. Ongoing donations will be cancelled by us. If you have previously donated to PDPC you’ll still qualify for your donor cloak as normal. If you believe you’re due a cloak and we haven’t processed it yet please contact us.
One thing I was tasked with was replacing the ingress data collector. One of the limitations of Erlang at the time was that all SSL termination was funneled through a single core. Once the Java replacement was deployed, we saw a massive decrease in latency, the p95s and p99s especially, and all the weird operational overhead of trying to understand what the Erlang VM was doing at any given moment.
Say what you will about Java and the JVM, but it's a fantastic platform for reasonably high performance servers. Erlang might have a lot of claims for high concurrency and scalability, but practically I've had considerably more success with the JVM.
I haven't touched Erlang since 2013, so in the intervening 11 years I can only hope that it has gotten better. Though I have zero interest in trying it again.