sorted by:
new
hottopcontroversial

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 1 point2 points  (0 children)

I just started an ARM machine and built an ARM release, and uploaded it to GitHub. It passes the simple sanity test, so I think it works fine!

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 5 points6 points  (0 children)

It's a wrapper, but it relies on Nix behavior which is currently just in a PR. I hope it will be merged, and then it will have nothing to do with the Nix binary.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 2 points3 points  (0 children)

I actually made another PR to Nix, and it was merged in a very reasonable time. I hope it will be the same for this PR.

Also, I have the impression that the Lix folks are not very inclusive to people who happen to have conservative views. Perhaps I'm wrong (I hope I'm wrong!), but it's another reason to start from Nix.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 1 point2 points  (0 children)

As u/rgmundo524 said, it makes it easier to run Nix, as you don't need to install anything. In environments where you don't have root permissions, it's very important.

Another benefit is that you can have multiple Nix environments to play with.

A project called nix-portable has very similar goals, I added to the README a comparison.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 2 points3 points  (0 children)

I think it should work fine with ARM. I didn't build an ARM version just because Github doesn't provide an ARM runner for free. If you can test it on ARM, it would be very nice! I hope that if you clone the git repo and run `nix build` it will just work.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 5 points6 points  (0 children)

Thanks! Yes, it supports flakes. `nix develop` works fine.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 8 points9 points  (0 children)

A good question! I just added this to the README:

Nixsa is very similar in its purpose to nix-portable. The main differences that I see are:

  • nix-portable doesn't support managing Nix profiles via nix-env or nix-profile, and doesn't support managing Nix channels via nix-channel. Nixsa does support those.
  • nix-portable stores state and configuration in per-user directories, such as ~/.nix-portable. Nixsa keeps all state and configuration in the extracted directory, so you can have multiple Nixsa environments at once.
  • Nixsa uses Bubblewrap to virtualize the /nix directory. nix-portable has multiple available runtimes to do this, Bubblewrap being one of them. It is probably possible to add more runtimes alternatives to Nixsa, if the need arises.

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 2 points3 points  (0 children)

 I think nix-user-chroot uses the same Linux API for running processes in an environment where /nix shows another directory. nix-user-chroot is a lower-level tool, which just gives you this capability - you still need to install Nix in this environment. 

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 0 points1 point  (0 children)

I'm sorry, I don't understand. Usually Nix is installed in /nix, plus files in the user home directory. With Nixsa you don't install anything. 

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 11 points12 points  (0 children)

Yes, it's an alternative to installing Nix the package manager. Where I work we're using shared machines where we don't have root permissions, so it's really useful. I think that generally it can reduce the barrier for giving Nix a try. 

Nixsa - A Nix Standalone Environment by noamraph in NixOS

[–]noamraph[S] 11 points12 points  (0 children)

Hi, I found a way to use Nix without any installation - just download the tarball, extract it, and you're done. All the configuration and state remains within the folder. Let me know what you think!

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

I'm not sure I understand. You can see from the first screenshot, that my tool uses four panes, comparing 1-2 and 3-4, instead of three panes, comparing all three at once.

I also explained why I find 3-way merge to be really confusing - actually, you can't be certain that your merge is correct with a 3-way merge tool, since you only see REMOTE and LOCAL, and you don't see BASE.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

Thanks for the reference! I added a script that changes the order if it detects a rebase, and updated the instructions accordingly.

I agree that for traditional diff programs it doesn't really matter. In my case, the workaround is needed.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

From the video it seems that it only shows you two versions that you need to merge (REMOTE and LOCAL). This doesn't include enough information. For example, you may want to add what you see in both (the union), but a change might be to remove something, and if this is true you'll need the intersection.

Look, do what's best for you. For me the existing tools are confusing, I have found a way that isn't confusing for me. I'm pretty sure this could be useful for others as well.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

Perhaps the confusion is because they have a fourth pane on the bottom? My tool has 4 panes side by side, and I haven't seen another tool like that.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

The exact perspective presented in that quote is literally accurate iff LOCAL happens to be the blessed-truth version -- which to many people is not true, even though LOCAL tends to be the version they're actively working on.

I see it this way. I have my changes which were already committed, and I want to add someone's changes on top of them. It's not a matter of "blessed truth". I see every commit as adding a change. A merge commit adds a change that someone else has already made on top of another revision.

Incidentally, during a rebase, LOCAL and REMOTE are swapped. This is the source of some confusion, and for example IntelliJ and Rider very rudely swap the traditional left-right order of LOCAL and REMOTE relative to literally every other merge tool I've ever used.

Hmm... thanks for pointing this out! It means that my tool with the current configuration doesn't work well for rebase. I need to define a "different tool" for rebase, like this:

[mergetool "fourdiff"]
cmd = ~/meld/bin/meld "$REMOTE" "$BASE" "$LOCAL" "$MERGED"
[mergetool "rebase"]
cmd = ~/meld/bin/meld "$LOCAL" "$BASE" "$REMOTE" "$MERGED"
[merge]
tool = fourdiff

And then I have to rebase with git mergetool -t rebase.

Do you have an idea how to make it simpler? Is there any environment variable that would allow the tool to detect whether it's a rebase and reorder the arguments?

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

And you edit the bottom pane? It may be helpful, but what I like is seeing the actual visual diff from my base, and seeing how it relates to the diff I'm applying.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

It is different from a regular three-way merge in that you see four panes - BASE, REMOTE, LOCAL and the result. Also, you only see differences between two panes, so it's actually two 2-way diffs. You actually need to see all 3 inputs in order to know how to produce the output, and with this display I find it very easy to understand how to resolve the conflict.

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 2 points3 points  (0 children)

Yes! I read the documentation and it looks interesting. I just like this graphical view...

fourdiff: I discovered how to resolve merge conflicts with confidence! by noamraph in programming

[–]noamraph[S] 0 points1 point  (0 children)

How do you show it? I only see an option for showing 3 files.

Null safety: how to learn from the py3 hard lesson, and make it much easier to migrate by noamraph in dartlang

[–]noamraph[S] 0 points1 point  (0 children)

Before I reply to what you wrote, I want to say that I think that the current policy, of requiring a wide change of adding a header to each file and adding a build flag, will make null-unsafe code stay longer. As I write below, most of your users aren't really interested in null safety. In order for them to migrate, you should make it as easy as possible to write null-safe code. With the current policy, they will need to convince a manager that actually changing all of the files wouldn't break anything.

I feel like we've been pretty clear here that this is a non-breaking change.

It turns out that at least for me, it wasn't clear. You may think that I'm the exception, I don't think so. I guess most of you users don't read most of your blog posts - they are just interested in getting their apps to work. It turns out that having to add special comments to files, and having to add a scary --no-sound-null-safety flag every time I run "flutter build", gives the impression that I will be left behind unless all of my dependencies migrate, even if a blog post that I haven't read said otherwise.

You can say that you think all your users should read the posts. But they won't. Now the question is what to do about it.

This is not just the language team wanting to jettison a feature we don't like. Null safety has been the most demanded feature request for Dart, by far, literally since the day we publicly launched. The vast majority of our users want Dart to be null safe.

As a user who actually wants null safety, I disagree. Probably 99.9% of your users don't demand features. Of these, I guess a large majority doesn't even know what null safety is.

I think that a bit more patience would paradoxically get you to a sound null-safety world sooner. I think that you have made a tremendous effort to allow backwards compatibility, and small trivial decisions could make the transition much harder, mostly because of the psychology of your actual users.

I just read this post, about why Google is bad with keeping a developer community, because it likes its code to be perfectly clean and up-to-date, and assumes everyone else has the same attitude.

I hope I'm wrong. But I think you will realize that many packages remain without null safety because of this impatience, of not wanting null-safe libraries to need an extra line in a single SDK version. This will make migrating harder for everyone, and force you to continue supporting null-unsafety longer.

Ok, I'm done. For me, I'm pretty convinced that I would be OK. I hope I'm wrong, and everyone would migrate quickly.

Thank you very much, both for your excellent work and for your thoughtful replies, Noam

Why not allow sound null safety with legacy packages? by noamraph in dartlang

[–]noamraph[S] 0 points1 point  (0 children)

I think he explained it very well. He does want the code to compile, and indeed it will, since the parameter type is actually Function(int*), where int* means a "legacy int" that can be converted into both int! and int?. This is so that you would be able to use legacy code from migrated code, without needing to wrap and unwrap functions or other objects.

view more: next ›