petethepig
This is so silly — they only record when you press a button, not continuously, and they can only record for like 3 mins max and there’s a light that indicates to everyone around you when they are recording.
Meanwhile there’s a bunch of people in line with their phones out, which do not indicate when the camera is on. But somehow that’s different.
It’s a bummer because they’re great for taking family photos/videos. Also great as an Airpods replacement. A little flimsy but the tech is 90% there.
I wish Apple made them instead of Meta — I think they’d do a better job of bringing them to the market while maintaining public trust.
Did anyone do this kind of math?
* download Warcraft II voices
* tell claude to wire it all up
Immich has been absolutely awesome for this — I can finally look at all my pictures from any year from anywhere in the world. I’m very happy and hope the creators find a way to sustainably finance the project.
The upload feature in the mobile app is not a 1 to 1 replacement of apple photos import so i still do that via apple photos, but that’s something I can live with.
This is a ChatGPT based Flamegraph explainer. Analyzing flamegraphs can be challenging and we often get questions from users about the best techniques for finding insights from flamegraphs.
We thought maybe we could teach an LLM do this task and turns out it ChatGPT does it pretty well.
You can check out a blog post [0] for a longer explanation for how it all works, or you can upload your own profiles and get insights quickly by going to flamegraph.com [1]
[0] https://pyroscope.io/blog/ai-powered-flamegraph-interpreter/
[1] flamegraph.com
AI-Powered Flamegraph Interpreter in Grafana Pyroscope
The world of art (and especially commercial / corporate art) is very foreign to me, but I bet exploring it would be a fun challenge, so I am planning to do that in a few years.
Decision about public video recordings
This sounds about right.
My favorite little anecdote that I like to tell is that the first thing people often see when they add Pyroscope to their apps is that it takes way less CPU than other signals like tracing or logging. It's pretty common to see logging taking 5-10% of overall CPU utilization.
The other 90% is usually spent doing serialization / deserialization (half-joking).
I work on Pyroscope, which is a continuous profiling platform and so I see a lot of profiles from various organizations.
If you want to save the world some CPU cycles I would look into optimizing deserialization. And it’s not just JSON, binary formats like protobuf are not much better.
It comes down to the overhead associated with allocation and tracking (GC) of many many small objects which is unfortunately very common in modern systems.
Go 1.20 Experiment: Memory Arenas vs. Traditional Memory Management
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)."
They only use this for indexes. It works really well for internal mongo ids (they all start with timestamps if I remember correctly). It also works well for compound indexes. Pro tip: for compound indexes always go from low-cardinality attribute to high-cardinality attribute to get the best results from prefix compression (it's also good for speed of queries).
[0] https://www.mongodb.com/docs/manual/reference/glossary/#std-...
[1] https://medium.com/swlh/mongodb-indexes-deep-dive-understand...
We use them a lot at Pyroscope for compressing strings that have common prefixes. They are also used in databases (e.g indexes in Mongo) or file formats (e.g debug symbols in macOS/iOS Mach-O format are compressed using tries).
We have an article with some animations that illustrate the concept in case anyone's interested [0].
[0] https://github.com/pyroscope-io/pyroscope/blob/main/docs/sto...
* Assuming you can parse faster than you read from S3 (true for most workloads?) that read throughput is your bottleneck.
* Set target query time, e.g 1s. That means for queries to finish in 1s each record on S3 has to be 90MB or smaller.
* Partition your data in such a way that each record on S3 is smaller than 90 MBs.
* Forgot to mention, you can also do parallel reads from S3, depending on your data format / parsing speed might be something to look into as well.
This is somewhat of a simplified guide (e.g for some workloads merging data takes time and we're not including that here) but should be good enough to start with.
[0] - https://bryson3gps.wordpress.com/2021/04/01/a-quick-look-at-...
Pyroscope is open source performance monitoring software, with a focus on Continuous Profiling. Pyroscope was founded at the beginning of 2021 and we've seen a lot of rapid growth / community adoption as well as feedback for what features developers are excited for us to build.
We're looking for Backend Software Engineers (Golang). Our custom storage engine is written in Go (with agents for many other languages as well).
---
Roles:
Senior Software Engineer - Golang: https://apply.workable.com/pyroscope/j/28E1725C98/
Questions?: [email protected]