<infinisil>
Especially for this syncthink-relay package, which has settings for the ports already, one can just `networking.firewall.allowedTCPPorts = [ config.services.syncthing.relay.port ];`
<infinisil>
Needs more guidelines for such common options (I started with `package` in #50476)
<infinisil>
elvishjerricco: fish and osh come to my mind
<elvishjerricco>
infinisil: I've heard of fish. Never looked into it though.
<__monty__>
elvishjerricco: Fish is nice but may be too close to *sh for you, at the same time you need to drop some bashisms you might expect to be there. && and here-strings come to mind.
<samueldr>
more than just bashisms, fish isn't even posix sh compliant IIRC
<samueldr>
though last time I tried it felt like "what if sh wasn't held back by backwards-compatibility"
<elvishjerricco>
infinisil: Hah. I've thought about trying to make GHCi into a shell before. Too many barriers.
<infinisil>
Yeah same
<elvishjerricco>
Something haskell-like would be great though
<infinisil>
I sometimes use haskell for the occasional scripting i need to do though
<elvishjerricco>
yea I love haskell for scripting honestly.
<elvishjerricco>
runhaskell makes it pretty trivial
ottidmes has joined #nixos-chat
<ottidmes>
I have been having issues with my desktop, it no longer goes into suspend (or rather it will not wake up from it), and for the last few days it can just shutdown at any moment (nothing relevant in the journal). This happens on both NixOS and Win10, so it should be hardware related. Any guess what it could be? I would expect a more consistent behavior if the CPU was broken, GPU should not cause a complete
<ottidmes>
power down that I am aware of, could a partly broken PSU also cause suspend issues?
drakonis has quit [Ping timeout: 250 seconds]
drakonis1 has quit [Quit: WeeChat 2.2]
drakonis has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 252 seconds]
__monty__ has quit [Quit: leaving]
ottidmes has quit [Ping timeout: 246 seconds]
Ralith has left #nixos-chat ["User left"]
<samueldr>
took 6 hours by-the-clock, but much less, to get stage-1 working on another device
<samueldr>
* if generally close to what's already there (fastboot-based, qualcomm)
<infinisil>
samueldr++
<{^_^}>
samueldr's karma got increased to 39
<samueldr>
<3
<samueldr>
still hugely annoyed by the fact that I don't have a dedicated device for that
<infinisil>
samueldr: What's the thing that prevents you to get further than stage 1?
<samueldr>
time!
<samueldr>
hah, not-being-implemented, so I need to write the damn thing
<infinisil>
Heh yeah, but like, what's the error you get?
<samueldr>
the stage-1 is custom, for maybe no good reason
<samueldr>
though it made it easier at first to figure out things out
<samueldr>
but really, the real reason is that I haven't yet *did the thing*
<infinisil>
I see, hopefully I can also understand what you're doing at some point. Maybe once the Librem 5 finally ships
<samueldr>
hopefully(?) few of the things are really needed there :)
<andi->
I am still unsure..
<samueldr>
about?
<andi->
The required hackish changes
<samueldr>
changes to?
<samueldr>
if it's about the kernel, well, you have to do with whatever the OEM drops :/
<andi->
Stock sources
<samueldr>
sure, mainline would be better
<andi->
With time that will surely happen
<samueldr>
but here I'm starting on the assumption that once things *can* work, cleaning and porting to mainline will be more worthwhile
<samueldr>
so, hack it up as a POC
<samueldr>
get people hyped, people better than I (hopefully)
<samueldr>
even with what I did, I saw a great opportunity to work on a combined msm_8953 tree
<andi->
infinisil: you also ordered one?
<infinisil>
andi-: Yup
<samueldr>
each damn OEM makes their own customized changes... which is ~bad~
<samueldr>
so first step before mainlining would be combining and cleaning the sources on top of whatever LTS release, and *then* port forward
* samueldr
sweats
<andi->
You can do it! :P
<samueldr>
as a full-time job with some support that's for sure, but whew at that point it will be draining
<samueldr>
fun fact: the motorola-addison runs on armv7 stock, and from lineageos
<samueldr>
which is probably why there are funny hacks in the source :/
<samueldr>
AFAICT it's not uncommon still (or for late 2016 era hardware) to have shipped on 32 bit instead of 64
<infinisil>
Man, there's so many areas around Nix/nixpkgs/NixOS that need work, I'm not sure where I should invest my time
<colemickens>
the CLI makes me want to rage quit every other day or so
<samueldr>
oh, and andi-, right now yes the kernel is a spooky fork from a random user, and not from the downstream OEM, but that's an implementation detail right now. The goal is that once I'm about to use the device, I'll fall back to a reputable source
<samueldr>
as the device was NOT aarch64, but had some ROMs made for aarch64 (go figure) I started with a kernel tree which was known to work on aarch64
<samueldr>
at least remove some unknowns
<samueldr>
as the device's stock operating system is not aarch64*
<infinisil>
colemickens: The new Nix 2.0 CLI?
<colemickens>
both of them
<infinisil>
Hmm, yeah, both aren't truly good, but the old one is better imo
<colemickens>
nix build doesn't warn if ./result exists, doesn't overwrite, doesn't output build paths, hides entire classes of failures, fails to live up to a goal of consistency IMO, and docs are woefully incomplete
<andi->
samueldr: good decision, I would probably have lost track of my actual goal while going down the rsbbithole of fixing all the unsubmitted patches :)
<infinisil>
colemickens++
<{^_^}>
colemickens's karma got increased to 4
<samueldr>
lol yeah andi-
* colemickens
is trying really hard to build up some constructive feedback though, and not just complain. I am taking notes....
<infinisil>
colemickens: What's an example of a truly good CLI?
<infinisil>
Maybe we can take inspiration from those
<colemickens>
I think `kubectl`, at least at one point in time, was pretty great at being predictable and consistent.
* infinisil
doesn't know that one
<colemickens>
so far I have a lot of "rough edges" that could be solved with interface changes or just docs. I feel like I'm not quite experienced enough with them or all of the layers of Nix to have great suggestions on what would be a better interface so far.
<colemickens>
for example `nix-build` can do `nix-build /etc/nixpkgs -A chromiumDev` and yet the `nix build` invocation seems much less trivial -- I could only figure out how to do it by manually importing /etc/nixpkgs and referencing it in an expression.
<colemickens>
So for that, I don't know if the "new" CLI UX is intentionally more principled, or if it just doesn't document how to point to a specific nixpkgs.
<colemickens>
Or worse, it has removed support for pointing to nixpkgs in favor of only relying on NIX_PATH? I don't really know. Just one of the things I was a bit frustrated about last night
<infinisil>
colemickens: I think `nix build -f /etc/nixpkgs -A chromiumDev` might work
<jasongrossman>
fish shell is a really good CLI IMO. (It has the big drawback of not being POSIX compliant, so I'm not saying we should USE it, just that it's a good model of design.) https://fishshell.com/docs/current/design.html
<infinisil>
or --attr
<samueldr>
oh, github has added the possibility to transfer an issue
<colemickens>
`nix build -f /etc/nixpkgs chromiumDev` seems to
<colemickens>
no -A or --attr apparently
<infinisil>
Ahh
<colemickens>
samueldr: I've noticed a ton of new features recently. I'm curious if they intentionally had stuff in the bag ready to ship post-acq announcement.
<colemickens>
samueldr: the profile pages include new metadata information that really makes it a lot less tacky, imo
<infinisil>
colemickens: Also, I dislike how the default `nix build` displays so little information. All other CLI's, cargo, stack, whatever, can display progress in a nice way without littering the CLI, and with more than just 1 line.
<colemickens>
100% yes.
<infinisil>
Also, what the hell do all these numbers in nix build's progress mean??
<colemickens>
I saw some justification that its because parallel build log lines interleave. I don't think that's a good reasoning...
<colemickens>
LOL
<colemickens>
I just know i wait for one of them to go to 0. :P
<infinisil>
Yeah
<samueldr>
time to come clean: I haven't used the new CLI, only `nix repl`:/
<infinisil>
samueldr: I'm only very very rarely using the new CLI, nix repl a lot (out of necessity)
<infinisil>
Except once I finished my own nix repl I'll be using that :D