neobrain

Honestly the name is doing Qt Creator a bit of a disservice, given how fantastic an IDE for any C++ codebase it is, Qt or not.

Yes - it's good for this use case! It even has built-in support for fetching dependencies declared in project conanfiles.

> The repeating behaviour and the 'not now' are two sides of the same coin. Per the original post, and my experience, those 'not now' buttons keep coming back.

So you're using "not now" as a shortcut to identify malicious design. That's fine but personally I'm not. I would go as far as claiming as most people don't feel this way about such a tiny wording detail, but I obviously haven't ran any A/B testing to confirm either interpretation.

> And, for the sake of argument, how should respectful software behave? If I clicked 'not now', are you _ever_ going to ask me again? If so, how do you decide on the time-period?

Honestly this question seems bizarrely focused on making the software give you a definite promise on what it will or will not do. It's a valid design question how to respectfully prompt the user for choices, but if that's your concern then this specific wording choice is an unimportant detail to get stuck on.

> If not, why make 'no' more complicated than 'yes'?

The reason was given my my opening argument: "no/yes" demands a conscious choice whereas "not now" doesn't. "not now" is plausibly less complicated than "yes" for a majority of users, and cognitive overhead generally matters more to people than imaginary contracts about future choice prompts.

Are you perhaps more concerned about software that keeps nagging you about the same thing over and over again than about the wording in particular? Because badly designed software will do that whether you told it "not yet" or "no".

While I can see the frustration by repeatedly using such software, it seems fair that a well-intentioned UX designer would use "not yet" if they found it works better for a majority of people. What then matters is that they respect the intent of everyone by not bringing the choice up again.

Playing devil's advocate here: Isn't one advantage of "not now" that it conveys "I don't want to worry about this now, don't change anything and get out of my way" whereas "no" burdens the user with a conscious choice?

The documentation pages are on GitHub, anyone can submit a PR to update this text.

Perhaps check if there are any log files in /var/lib/speakersafetyd/blackbox. The fdr files in particular contain human-readable error reasons. If there are no log files, it's probably something else.

Judging by this note in the docs: Collaboration features.

https://zed.dev/docs/development/freebsd#webrtc-notice

Actively in progress, with related patches submitted to the kernel mailing list as recently as 3 days ago.

> And it's a PITA to install

Curiously I found it a breeze since it didn't require digging out a flashable boot medium and pointing your BIOS to it. Calling a script from your normal desktop environment and having it automatically boot into the installer was really nice.

> with the partitions already in a good state)

What's this about? The script takes care of resizing the macOS partitions and creating new ones for Linux.

> Not to mention it takes minutes for the window of Zed to open, whereas VSCode is almost instant.

That one is interesting. It's much quicker for me, even cold starts are below 1s, and subsequent startups are basically instant.

Unstripped, perhaps?

    ls -lh /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor
    -r-xr-xr-x. 2 root root 3.2M Jan  1  1970 /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor

EDIT: Ah, it was too good to be true. The true binary is hidden in libexec/.zed-editor-wrapped :(

    ls -lh /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped
    -r-xr-xr-x. 2 root root 337M Jan  1  1970 /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped

Extra weight also comes from webrtc, which nixpkgs dynamically links. So yeah, it's quite a large binary indeed.

> I was always under the impresion that Rust apps are pretty lightweight, but that install size is nearing Java levels of binary/dependency bloat.

For what it's worth, the zed executable on Linux weighs 3.2 MB.

EDIT: Sorry, the nix store is too good at hiding things from me. It's actually around 337 MB plus webrtc-sys.

Good and fair comment. Just adding some nuance:

> There is no support for power-efficient sleep

"power-efficient sleep" refers to discharging 1-2% battery over night rather than 10-20%. I.e. there's room for improvement, but the device can still be used without worrying much about battery life regardless (especially given how far a full charge gets you even without sleep).

> Display Port, Thunderbolt

Big item indeed, but it's actively worked on and getting there (as you mentioned).

> video decoding or encoding

Hurts battery performance, but otherwise I never noticed any other effect. YMMV for 4K content.

> touch ID

Annoying indeed, and no one has worked on this AFAIK.

> The speakers overheat and turn off momentarily when playing loud for a longer period of time. The audio stack in general had to be built from ground up and it seems to me like there are bits and pieces still missing or configured sub-optimally.

Sad to hear since I thought the audio heat model was robust enough to handle all supported devices. On my M1 Air I've never seen anything like this, but perhaps devices with more powerful speakers are more prone to it?

LineageOS includes Seedvault for backup and restore. It's not 100% reliably across devices apparently, but should typically work: https://github.com/seedvault-app/seedvault/discussions/331#d...

This requires both phones to use Seedvault though, so it's not an option when moving from the stock OS to LineageOS.

The LineageOS port for the FP6 is already well-underway and close to daily-drivable AFAIK. Support for iodéOS has also been announced as planned within 2025, which seems like a good alternative to Calyx.

There's https://lingonaut.app/ , which is not open-source but at least open data. It's sort of like early-days duolingo with volunteer-driven courses. Some of the courses are surprisingly well thought out (if yet to be implemented to a usable extent), but quality will be mixed. I don't think they have an answer for proper pacing at the moment, but being a free product they're at least not incentivized to keep you repeating the same content indefinitely.

I'm getting a lot out of Anki with premade decks these days, combined with watching tons of video content.

20% is about the general order of magnitude we observed in FEX a while ago, though as you enable all TSO compatibility settings (including those rarely needed) it'll be much higher even. As people elsewhere in the thread mentioned it'd be interesting to see how FEX fares on Asahi with hardware TSO enabled vs disabled (but with conversative TSO emulation as set up by default) since it's less of a blackbox.

> How is it a misinterpretation? To re-quote that last sentence:

I think we agree in our understanding, but condensing it down to "TSO isn't as much of a deal as claimed" is misleading:

* Efficient TSO emulation is crucial (both on Windows and elsewhere)

* The blog claims hardware TSO is non-ideal on Windows only (because Microsoft adapted the ecosystem to facilitate software-based TSO emulation). (Even then, it's unclear if the author quantified the concrete impact)

* Hardware TSO is still of tremendous value on systems that don't have ecosystem support

> [volatile metadata] doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.

That's funny, I hadn't considered third party compilers. Those applications would still benefit from ARM64EC (i.e. native system libraries), but the actual application code would be affected quite badly by the TSO impact then, depending on how good their fallback heuristics are. (Same for older titles that were compiled before volatile metadata was added)

> People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed

This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulated code (such as the emulator itself or in ARM64EC).

The claimed conclusion is that it's better to optimize TSO emulation itself rather than bruteforce it on the hardware level. The way Microsoft achieved this is by having their compiler generate metadata about code that requires TSO and by using ARM64EC, which forwards any API calls to x86 system libraries to native ARM64 builds of the same libraries. Note how the latter in particular will shift the balance in favor of software-based TSO emulation since a hardware-based feature would slow down the native system libraries.

Without ecosystem control, this isn't feasible to implement in other x86 emulators. We have a library forwarding feature in FEX, but adding libraries is much more involved (and hence currently limited to OpenGL and Vulkan). We're also working on detecting code that needs TSO using heuristics, but even that will only ever get us so far. FEX is mainly used for gaming though, where we have a ton of x86 code that may require TSO (e.g. mono/Unity) but wouldn't be handled by ARM64EC, so the balance may be in favor of hardware TSO either way here.

For reference, this is the paragraph (I think) you were referring to:

> Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.

You can think of it as replacing the space between words as wildcards, so `z lin lin` would indeed work to select the first one!

Adding to the other answer: You can also pass multiple keywords to zoxide and they are expected to match in order. So in your example, `z foo src` would reliably cd into `~src/foo/bar/src` even if `src/foo` has a higher visit frequency.

I don't use autojump, but glancing over its readme it's missing nushell integration that zoxide provides.

It being a native binary instead of Python-based might also help it execute more instantaneously. Most Python-based CLI helpers that I tried add a slight but noticeable delay to simple commands, whereas zoxide is so quick it's easy to forget you even invoked a helper in the first place.

Perhaps helpful: There's also a `zi` command, which prompts you with a list of all matches before changing directories. Personally there's only few directories where I need it, and I just memorize using zi instead of z for those.

However I agree z should ideally have some syntax like `thing$` to denote a full directory name instead.

Semantic versioning is culturally widespread in Rust, so the problem of library authors being "less careful about API stability" rarely happens in practice. If pinned packages were the problem, I'd imagine they would have been called out as such in the Debian page linked by parent.

Sorry to hear the laptop you chose has poor Linux support. I wouldn't buy a new system these days without first checking how well it will run Linux, even though in an ideal world that wouldn't be necessary.

Do note that the context of my comment was Asahi Linux though.

Yes, that's known as global application menu (not enabled by default). It's not the most discoverable feature, but it's working great once set up. (For reference, just add the widget to your panel and then make sure to restart plasma for it to take effect).

> the context menu with hundreds of options can’t be simplified to my knowledge

What context menu is this about? When I right click into the terminal area, my context menu has a grand total of... 11 items.

> Just one more question: is my mac hardware (and encrypted data) still protected the way it is protected before installing Asahi on it? Like device/theft protection etc.

Apple devices probably have the strongest security model offered by any otherwise open consumer device these days, so yeah: Installing Asahi won't degrade security of the macOS installation.

Note that the Linux install itself will have weaker protection, since e.g. the fingerprint sensor is not yet supported. I also think disk encryption would be much harder to set up due to Apple's boot process (if it's even feasible at all currently).

This information is very dated. Webcam/audio work fine nowadays, and suspend/resume have never had issues that I recall. IME the feature support page is very accurate (no hidden gotchas like "technically it works but it breaks after sleep").

USB-C output is indeed not working but actively making progress (so actively that some of the related patches have been sent to the kernel mailing list and merged this very week).

> Is Asahi installed side by side on a mac?

Yes, the installer automatically (and reliably) resizes partitions for you. A minimum of about 70 GB for macOS is needed (anything lower is still possible but unsupported).

> You pick it at boot?

There's a default choice that will boot.

> And how “install and just use” it is?

Probably one of the smoothest Linux installs I've had in 10 years or so, since you just run the installer from macOS instead of flashing ISO files to an USB drive.