Orphis

There are definitely some uses for a washer and drier with "smart" capabilities. Just alerting me when the program is done so I can put the next load is great. The cycles are not "fixed time" anymore, they all weigh the load and end up variable.

I could do without them, and it's not the end of the world if the laundry stayed 20m or 1h longer in the drum. It's practical, and hopefully not a critical feature of the internal board. One could argue if alerting is really a "smart" feature either.

There's also a chance the people claiming to do clean room are cheating and took some shortcuts.

It's easy to make random claims that are impossible to prove or disprove.

They could claim that some employee one day used their model to ask a question about internal stuff and they trained on that.

It doesn't have to necessarily have to make sense to make a claim, but it doesn't necessarily bear any weight.

If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.

You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).

One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.

A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.

There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.

The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.

People say they care about the "story" behind the PR. But no one cares about that story if it's about forgetting to fix a test and a typo in a comment.

The extra commits are just noise that make you think the original commit is a source of truth in a blame when it has been amended 3 times more in the same PR, but the link isn't apparent anymore.

Force pushing is bad to a published branch, not a feature branch (not that you really have force pushes in Gerrit anyway). There are versions of Gerrit tooling where you can have a branch as dirty as you want locally, but only the final aggregated change is visible for review of that's what you prefer too.

Thinner modular systems also require some good tooling and a good platform that ensures many security properties.

You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.

C++ ended up in that situation because they don't want to break backwards compatibility (ABI, API) or change contracts, except in some rare cases, even on major releases. Quite often, it is a vendor issue to break the ABI and fix issues, and some have refused to do that.

It's a self-inflicted issue that most other languages with "batteries included" don't have since they will document breakage and upgrade paths when anything changes, or they are not impacted as much since they are using an intermediate language as interface and avoid most ABI issues.

The implementation is fixable though, you can break the ABI and address your issues. A lot of standard library defects are fixed in an unstable ABI mode they have, but that requires you to link it statically or dynamically and then ensure all your shared object dependencies are using the same exact version. It's not trivial for everyone, but many do this (usually the static version).

You mostly hear about the bad ones. Mine has been doing great for almost 2 years now. I use it in a clean environment, I'm very careful and not clumsy, so that helps.

It's not that noticeable when you use the device. It will depend on your ambient lights usually and how you hold it. It's a lot easier to see when someone else is holding the phone too, so if that was your reference, you may want to use them a bit more first.

I think the clumsiness can be improved. I always make a conscious effort when I grab my phone or put it away, so that is is always secure. No "I thought it slid into my pocket but apparently it was still outside it and then dropped". I would grab my phone with both hands in a lot of situations that are risky etc.

It's a bunch of small habits to change, then you may be ready for a fragile foldable. Until then, yes, probably not the target audience!

Turns into a small tablet which is great for reading, for impromptu client demos, and for playing some games like puzzles.

It also enables multitasking by having applications side by side which can be very useful on a phone too.

You don't have to use it all the time, but it's nice when you need it.

And mine is almost 2 years old and in great condition. It's hard to know what is responsible in those cases, a manufacturing defect or a rough user. And knowing what I've seen people do with their non-foldable phone, I'm not sure who to trust.

Practice helps!

What also helped me is being so knowledgeable about the topic that I didn't need to prepare the presentation much (except for the slides and the general plan). When you know what you have to talk about, it becomes a lot more natural and relaxed for me.

I would be a lot more stressed if I had to learn a presentation by heart and it would probably be a robotic delivery.

So I did quite a few "surprise" presentations, with very light prepared material and a topic I cared about. Got me the practice I needed and I learned not to get "stuck" as if I forgot the next sentence. The presentation always flows!

Now, I have a talk at a major conference, and I'm afraid this won't work there, so I'll prepare my talk better this time, maybe even have speaker notes!

Curious, Windows is not supported by this.

Ultrawide curved are amazing. Put your main activity in the middle since there's no screen bezel and enjoy your neck-pain-free work hours. 2 monitors force you to usually have one on the left, one on the right and always face your head towards either.

Also, it's fine to have side activities on the side, but you usually won't be looking at those all the time, so they shouldn't cause any strain.

Why not just embrace Content Based Addressing and the Bazel action cache? Not necessarily adopt the RBE protos, but you could have on-disk cache that are similar or even identical.

Nowadays, I think a build tool that doesn't natively support distributed caching (and possibly remote execution) is a weird choice. And I don't think that spawning layers of processes allows for good parallelization as you don't know if an action is going to be network bound or compute bound and the job slot is then spent. So you either oversubscribe or undersubscribe.

This is not purely a CMake problem, this is a maintainer problem. It's absolutely possible to not define the man page targets if the related tools are not found, or to add a variable to disable that.

In practice, it does show the limitations of the CMake model though. You should not be paying the price to generate the build files for bits you don't care about. You should be able to just load the CMake files and build a target, ignoring the rest.

This is how tools like Bazel function and that allows them to scale to very large monorepos. Build files are only processed when a target from that folder is built directly or used. CMake has to load everything as it does not know about the build tree and the maintainer has to manage exclusion lists or inclusion lists.

Xerces is an old library, probably ported from autotools and will do a lot of autotools like checks which for CMake means: creating a CMake project with the probe, generating the build files from it, building it, gathering results. Once for each test. It's SLOOOOW.

I recently (a few weeks ago) made a project to batch those type of commands together and parallelize tests as much as possible. You can check a merge request for CMake upstream here: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1226... and the associated issue for more details.

In general, CMake is fast enough, the only slow bit on the critical path is detecting the toolchain. The rest is quick, but if your build scripts are using slow serialized functionality, you'll be paying that price. But only once as the slow results are cached, so next incremental run should be pretty fast!

> I want the build stages to communicate in one direction for sanity

That's easy to do if you control the whole pipeline and can integrate all the features together, not so much with the CMake model unfortunately. I think it would be nice if CMake had Ninja integrated as a library, it could lead to some nice optimizations later.

Simple CMake projects using the Ninja generator are very efficient, unless you create generated files.

And if they are in their own targets, they are not really an issue (they would serialize everything that depends on them as you'd expect), but if you have them in a library grouped with other files to compile, then the whole library compilation is serialized.

And obviously worse if you also have to build the generator for the generated files, but that's not a big surprise, you can observe that in full builds of Chromium or its libraries too waiting for protoc if you crank the parallelization a lot.

Last time I checked (a while ago), it wasn't. You needed to compile musl and exclude a few files from the archive to then provide your own allocator.

Depending on the toolchain, I'm assuming you could use some tricks or hacks to make it work better, but the tooling I used (Bazel) did that automatically and I haven't bothered to look at the internals yet .

That's to be properly measured. Assuming that the allocator will not cause issues there is to be proven.

The application I recently improved by changing the allocator had a similar profile (a C++ include scanner) and thread parallel I/O functions had terrible performance originally with mallocng. Adding threads almost had negative value because of the contention.

ripgrep is there to be FAST. Trading any speed to improve memory efficiency over a longer period of time for a process with a short life-time doesn't make sense in this case.

It's also a development tool. If your development machine is having RAM issues because it's doing a grep, you have bigger problems to solve.

As for other workloads that might use less RAM with mallocng compared to other performant ones, I'm curious to know about the magnitudes we're talking about. From 10MB to 20MB or from 100MB to 2GB? How was the speed of the program? Was there any multithreading involved?

That's good! But I wonder why it wasn't then enabled for that configuration or why the override wasn't "global" enough and the default allocator was still partly used.

Sure, but the problem isn't that the bug exists, is that it has surfaced in a performance application using musl and exerting code paths in a slow allocator.

mallocng should not be used at all.

I get why people don't bother replacing the default allocator from musl all the time (it's there, convenient). But in an application whose purpose is to be FAST, I find it weird they haven't bothered replacing it with another more performant one.

mallocng is bad at dealing with contention during multithreading. I've had applications that usually were I/O bound suddenly become "malloc" bound when building with musl in multithreaded scenarios (and only just 8 threads). Switching to mimalloc improved performance by 20x, very close to what glibc offers by default, and just a bit under a glibc + mimalloc configuration.

I get that there's a real issue there and it's interesting (to some) to address it, but it should have never surfaced this way in the first place.

Chrome uses those already, and a few other pointer types that are fit for purpose.

For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected.

Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).

They did roll this policy for Chromium changes a few years ago too.

And it wasn't just 2 humans but 2 Googlers. One Googler author and one Googler reviewer works. But an external author needed 2 Googlers to review changes, and all files needed to be reviewed by one author at least.

So if you touched multiple files owned by different people for a more complex feature, you would naturally get there.