kokada

Wait, what? ptyxis is not the default GNOME termjnal. It is the terminal of choice for both Ubuntu and Fedora, but the default terminal in GNOME is Console, internally known as kgx: https://en.wikipedia.org/wiki/GNOME_Terminal.

> but then, like, what do you actually want?

As an author of some homebrewed Go software in the past and trying to distribute in all 3 big OSes, I completely understand the blog post author's points. The problem is not Gatekeeper per see, it is just the combination of things that makes everything infuriating:

- I could justify going for the whole "Apple Developer Program" even with all the bullshit things you need to do to get certified if this was a one time payment like in Google Play Store. But it is yearly. Like the author, I would probably get 0 (or close to 0) dollars in recurrent revenue for those apps, I could justify a one time payment but a yearly one is ridiculous, it is not like Apple needs this money to be profitable (they probably get a much higher margins on selling things on Apple Store)

- Gatekeeper UX is infuriating. The equivalent on Windows (SmartScreen, as the author also cited) is still basically the same as Gatekeeper as far I understand (e.g., you need to have a valid certificate on your app or SmartScreen will deny the app execution until you clear the safety bit). But SmartScreen, different from Gatekeeper, has an actual good UX, as the error messages are clear and actionable (and also don't require a command line command to bypass)

- The author was still in a more "happy path" than me since their app seems to be a CLI only app. In this case just removing the quarantine bit with `xattr` works fine. In my case I was trying to distribute a desktop app, and I needed some special permissions to show notifications. This means I need to package my app in a proper `.app` bundle, include the required XML requesting the permissions and I am now required to sign the app. And since I am required to sign my app, I either pay the yearly payment fee to Apple to get a certificate to sign my app or I ask the users to resign the app with a self-signed certificate before launching

So really, I don't want that much actually. I can definitely handle all bullshit Apple wants, but I want at least a cheaper way to develop apps in their ecossystem. Maybe a new basic certification program that you have a one time fee and you can sign your apps but not notarize them. That way Gatekeeper would still complain, but at least my app would work without resign.

Or limit notarization to X amount of users (non-stabled notarized apps talks with Apple servers during the app first run, so they could just limit the amount of allowed tickets to X amount of users). If my app ever pass X amount of users, I will gladly pay the Apple tax, but 99USD/year for something that I will never see it back is too much.

Edit: BTW, I know, maybe 99USD/year doesn't seem too much for some. But Apple also doesn't do any regional pricing as far I know, and 99USD/year is crazy expensive in the country where I come from for example.

Edit 2: I am sure things are better nowadays with Claude/ChatGPT, but also trying to understand how to do the correct thing for your app is very difficult, especially if you're not using Xcode, since Apple assumes you're using it so all documentation refers to Xcode.

I think there is a very specific niche that this notebook is target for, and this definitely doesn't seem for you, the kind of person that having a cheaper laptop is more important than some of the unique features than this one or a Framework 13 Pro have.

For the unique part of this laptop that AFAIK a Dell XPS won't have is the Coreboot BIOS, that also probably means better support in the long term for BIOS updates.

To be clear, this is also not a laptop for me (but I did pre-order a Framework 13 Pro), but saying "nerd tax" or "anyone who buys one is either giving a donation or an idiot" like the other comment is just focusing in one part (the price) and not looking at the other.

> The author sounds knowledgeable enough to me.

Nope, their complaint about having an API ask if you should delete or not clearly shows the author has no idea how API works. They could have said that a deletion API could require 2 different requests, one for the deletion request that returns a token and another for confirmation with the token returned by the first request, but this is not what they said so.

Also as others have said, this wouldn't have helped anyway because the AI could just call both APIs one after another and the result would be the same, especially if the first request returns "call this other endpoint with this token to confirm your deletion request".

Exactly, that just reinforces the fact that the author is just blaming others instead of getting any valuable insights about this "postmortem analysis".

There is a difference between making a mistake like this one and being humble (e.g., lessons learned, having a daily external backup of the database somewhere else, or maybe asking the agent to not run commands directly in production but write a script to be reviewed later, or anything similar) and just blaming the AI and the service provider and never admitting your mistake like this article is all about.

The fact that this seems to be written by AI makes it even more ironic.

I don't think this is a minor point. It seems clear by this point that the author is clueless how even API works and are just trying to shift blame for third-parties instead assuming that they're just vibecoding their whole product without doing proper checks.

Yes sure, there seems to be lots of ways this issue could have been mitigated, but as other comments said, this mostly happened because the author didn't do its proper homework about how the service they rely their whole product works.

If that is true, this is malicious complaint. Unless Safari has the same restrictions, of course.

> As an example, nixos keeps state around regarding user id/username mappings, to avoid giving the same user id to different users across time. So a fresh install of nixos might leave services unable to read their data files, because the file might be owned by a different user id.

One reason to set `mutableUsers = false`: https://mynixos.com/nixpkgs/option/users.mutableUsers.

> And if you activate and enable incus, for instance, it will probably create a bridge device: the device will remain in place after you remove incus, which will have implications for how your network/firewall works that your configuration will depend on but will not enforce or be able to reproduce.

Impermanence: https://github.com/nix-community/impermanence.

To be clear, I don't use neither. But you can get NixOS to be almost completely stateless (if this is something you care) with a few changes. The power is there, but it is disabled by default because it is not the pragmatic choice in most cases.

BetterDisplay allow you to disable the internal monitor while keeping the lid open, this way I can still use TouchID.

I think macOS makes some trade-offs to give a supposedely better user experience as long you're part of the 80%. If you're not though, yes it is painful.

For me the macOS Display management experience is absolute dreadful. I had the same issues as the author's and I even had to pay actual money for a third party application (BetterDisplay) to fix some of the issues.

The most infurienting one for me is that I can't disable the internal MacBook display when I am connected to an external monitor without closing the lid. Why you may ask? Because I want to keep using the TouchID. However this is impossible in macOS without an external app.

I agree with all your points. This was not me complaining, it was just an observation.

I am actually really excited for a Apple laptop for once, since it is kind the perfect replacement for my Chromebook Duet 3 that I was looking for.

So my observation comes from the fact that UTM webpage: https://getutm.app/faq/#what-are-the-limitations.

Now this webpage may be out-of-date, so take my claims with a grain of salt.

To be clear, I am not complaining. I am well aware that the target demographic is students and casual users. It is just an observation.

However, the price argument doesn't make sense. I bought a EUR300 laptop for my wife 3 years ago that has a Intel Core i3 N305 CPU (https://www.intel.com/content/www/us/en/products/sku/231805/...), and that CPU, like any modern CPU from Intel, has virtualization instructions.

Heck, my Chromebook Duet with a Snapdragon 7c Gen 2, that compared to this A18 Pro chip is laughable underpowered, also has virtualization instructions (this is why Crostini, the Linux virtual environment for ChromeOS, works).

I think this has no virtualisation instructions right? Since AFAIK, those are restricted to the Mx series.

Of course the 8GB of RAM is also limiting for running any kind of VM, but this notebooks are almost exactly what I was looking for, except for the 8GB of memory.

> /bin and /sbin, needed for system boot. /usr/bin and /usr/sbin for normal runtime.

Nowadays most Linux systems boot with initramfs, that is a compressed image that includes everything the system needs to boot, so you're basically saying /bin and /sbin is useless.

There was an event without and increase of pizza orders I guess?

The issue I have with `nix-shell` is that the evaluation time is long, so if you need to run the script repeatedly it may take a long time. `nix shell` at least fix this issue by caching evaluations, but I think uv is still faster.

Years of experience working in Enterprise and complex systems.

And that is all on point with the criticism: while an AI can design a new language based in an existing language like Clojure, we need actual experienced people to design new interesting languages that add new constraints and make Software Engineering as a whole better. And we are also killing with AI the possibility of new people getting up to speed and becoming a future Rich Hickey.

I am working (mostly vibecoded) a Git history explorer in Go+modernc.org/Tk9.0: https://github.com/thiagokokada/gitk-go. It is heavily inspired in gitk, this is why the name and usage of Tk for the interface.

The reason for it was because after testing multiple Git history explorers, I still think nothing beats the gitk. Sublime Merge is probably the only alternative that I would seriously consider but I don't really like the UI and the fact that it is proprietary (I am not against proprietary software but I prefer an opensource solution when available). Other alternatives have some bugs or the interface few too slow. gitk itself is mostly fine, but sadly it tries to load the whole repository in memory and this is causing issues every time I try to navigate through nixpkgs (I can see the memory consumption going through the roof while the UI slow down to a crawl).

gitk-go loads a batch of commits (1000 by default) and once you get at the end of the list it loads more. I also add a few features that I miss from gitk, for example if you do any change in the repository (change branches, add files to stash, etc) it will automatically reflect in the UI.

Again, the code is mostly vibecoded since this is the first time I decided to try this from scratch. The code works well for my use cases and it is enough to replace gitk for me, but I can't guarantee there is no bugs and the amount of tests are small. But still, it was fun to see something that I wanted to create for a while (I had this idea for a long time since the issues with gitk that I was having) finally taking form. Probably the program is not useful for anyone but me, but if anything this is a feature, not a bug.

One thing that I am interested in is the performance of Fil-C compared to other compiled programming languages that are also GC'd, especially Go.

Nix with Flakes never randomly break, I still have projects from 3 or 4 years ago that I can still run `nix build` and getting it running. Yes, if you try to update the `flake.lock` this may introduce breakages, but this is expected if you're pining `nixos-unstable` instead of a stable branch.

I am using purego indirectly in two pet projects of mine. While it has its own issues it definitely solves the issue of cross-compilation.

In this particular case it may be that they will need to write a wrapper to abstract differences between the systemd C API if it is not stable, but at least they still can compile a binary from macOS to Linux without issues.

The other issue as other said is to use journalctl and just parse the JSON format. Very likely that this would be way more stable, but not sure if it is performant enough.

> FF7 really had this nailed - flashy, mysterious cut-scene to first battle in, what, 3 minutes?

Except when you use the Knights of the Round summon, then you go grab a coffee while waiting for the animation to finish :).

This looks like backwards. I would understand using a LLM to generate a GitHub Actions YAML, but always running your action from a Markdown file seems extremely wasteful in terms of resources.

Edit: ok, looking at example it makes more sense. The idea is to run specific actions that are probably not well automated, like generating and keeping documentation up-to-date. I hope people don't use it to automate things like CI runs though.

And now we have things like `__attribute__((always_inline))` for GCC where you are completely, 100% sure that you want to inline :).

Doesn't work as seamless, NixOS has this option but you can't quit the session unless you go to TTY and type `steam --kill` (the button for `Switch to desktop` exists but doesn't work). For it to work AFAIK you need to give SteamOS kind like a Display Manager permission (and also have some shims that does the actual work for switching sessions).

I don't think it is only for bragging rights, while in a vacuum the mainline kernel should be good enough for gaming, it is not really good when there are multiple tasks competing for the CPU attention (and this is especially bad for gaming because this can create a frame spike, ruining the game experience especially for multiplayer games). I think fixing this particular issue is one of the reasons Bore scheduler was created.

At least for Bazzite, Nobara and CachyOS, there is the SteamOS desktop option that boots directly to Steam's Big Picture that is quite unconventional in some ways (e.g. this desktop mode kinda also acts as a display manager, so there is the option to boot to your desktop from Big Picture mode and this option is generally broken without specific integration with the session manager).

Sure this could probably be a package in a more "traditional distro", but I'm almost sure most people don't expect their Display Manager to be replaced with Steam when they install a package.

I don't think they're downplaying. Most users will be perfectly happy with the included KDE application for screenshots/screen capture (it is really fully featured, much better than the default options for Windows or macOS).

And they're not saying that no third party applications will work either, it is just that old screenshot applications that were created for X11 will need to be ported.

In the end that is not really much different from macOS dropping Rosetta in the next release of macOS (yes, I know there is a difference of effort). Old applications will stop working, applications that still get support will eventually support it (if they don't support Wayland already).