<ashkitten>
i will probably just dump all the changes into one commit, but add a mechanism to force myself to commit changes as they happen
<samueldr>
ashkitten: I uh... accidentally started diverging my configs across my computers
<ashkitten>
bad samueldr
<samueldr>
and now I can't remember on which test machine I did fix that one thing, so I fix it again
<ashkitten>
samueldr--
<ashkitten>
<3 samueldr
<{^_^}>
samueldr's karma got increased to 346
<samueldr>
but then when comes the time to re-sync everything it will be hard!
<samueldr>
just yesterday I was fixing up the gobohide patches for 5.10 and 5.11... BUT I ALREADY DID 5.10 AT SOME POINT IN THE PAST
<samueldr>
after I was finished, I think I remembered the device it was on
<samueldr>
so yeah... committing is not enough
<ashkitten>
i only develop my config on my desktop and deploy to my other machines with nixus
<Ke>
I use rsync
<samueldr>
I don't have a central machine I work from really
<samueldr>
I have two main computers I use graphically, about equally, and a workstation machine which I ssh into
<samueldr>
and then I also want to start adding my test phones into my nixos configuration
<samueldr>
HALP
<samueldr>
oh, and tablets too
<samueldr>
there better be no one saying this is a problem of my own doing
<colemickens>
you know what they'd look great organized in
<ashkitten>
if i were in that situation i would pick one machine to do my config development on, and only use that machine via ssh to deploy
<samueldr>
when I started using NixOS I was frequently in a situation where I had only one computer, but not really access to the others
<samueldr>
e.g. at work
<samueldr>
or at friends or families
<ashkitten>
my desktop is always on, and all my machines are on a vpn so i always have connectivity between them
<samueldr>
my upload speed is bad
tomberek has quit [Quit: Connection closed]
<Church->
Yeah I really need to go fix up my nixOS config commit history
<Church->
One day...
<colemickens>
gpg: error from TPM: No pinentry
<colemickens>
lmao, I use gpg dozens of times a day, forward it and ssh all of the time, literally all day every day and yet I still have issues like this when I try to use gpg to do certain things in nixos
<colemickens>
aaaaahhh
<colemickens>
all I want is `keytotpm` to work
<colemickens>
oh wait! this one is on me, the exact right sequence reconfigures gpg client correctly
<colemickens>
"error from TPM: not supported", well it was a cute idea anyway
<drakonis>
so, was there any particular reason why home-manager lives offtree?
<Ke>
last I asked, it was because noone put in the effort
<Ke>
and then you also get the usual "why should it"
<drakonis>
hmm
<drakonis>
i see
<Ke>
for people in the inside seeing the outsider perspective is sometimes hard
<drakonis>
it doesnt get enough changes to justify living outside the tree now
abathur has quit [Read error: Connection reset by peer]
abstrn has joined #nixos-chat
<aaronjanse>
<drakonis "so, was there any particular rea"> I wrote a Discourse thread asking this same question. I can't link to it at the moment because my laptop is being weird
<aaronjanse>
So I'm on mobile
abathur has joined #nixos-chat
tomberek has quit [Quit: Connection closed]
eyJhb has quit [Quit: Clever message]
eyJhb has joined #nixos-chat
eyJhb has joined #nixos-chat
eyJhb has quit [Changing host]
<eyJhb>
,ping
<{^_^}>
pong
<eyJhb>
Yay
abathur has quit [Read error: Connection reset by peer]
<Church->
Ding
abathur has joined #nixos-chat
Qwerky has joined #nixos-chat
<philipp>
Dong
Qwerky has quit [Remote host closed the connection]
<gchristensen>
I need to set up this new computer to use my server as a remote builder already ...
lunc has joined #nixos-chat
<matthewcroughan>
gchristensen: It's funny what things you procrastinate on with Nix.
<matthewcroughan>
I do that a lot. I procrastinate the sharing of ssh keys between machines with Nix.
<matthewcroughan>
In other news.. it's funny what you find out when you use `file` and people haven't stripped their binaries.
<matthewcroughan>
Turns out ParsecGaming compile their 'parsec' binary with an old GCC from Ubuntu in 2016... the year their company was founded :D
<matthewcroughan>
They probably have a little box somewhere in their offices that does the compilation.
<infinisil>
lovesegfault: If you still remember or have some config for it, what did you need to do to get the Tp-Link Archer TX3000E to work?
xvello has joined #nixos-chat
abathur has quit [Quit: abathur]
__monty__ has joined #nixos-chat
xvello has quit [Quit: xvello]
xvello has joined #nixos-chat
Qwerky has joined #nixos-chat
xvello has quit [Client Quit]
xvello has joined #nixos-chat
Qwerky has quit [Remote host closed the connection]
Qwerky has joined #nixos-chat
Qwerky has quit [Remote host closed the connection]
<{^_^}>
#24936 (by b123400, 4 years ago, closed): ghost: init at 0.11.9
<matthewcroughan>
The reason this wasn't merged is because it would add substantial filesize to the nixpkgs git repo.
<matthewcroughan>
megabytes of json
<ashkitten>
this is all reasons that nixpkgs is messy
<ashkitten>
are you satisfied now?
<samueldr>
yeah, it's not node-packages per se, it brought its own node-packages along
<matthewcroughan>
ashkitten: I was never unsatisfied, just asking questions.
<matthewcroughan>
Because I think what we have is actually very good, and despite the mess, it's worth keeping in mind.
<ashkitten>
good or not, it could be better
<ashkitten>
which is what i want
<matthewcroughan>
So instead of mess, I think it's suboptimal. The word mess makes me depressed.
<ashkitten>
that's a fair criticism of my wording
<matthewcroughan>
Mess, (for me), makes me think we're worse than others.
<matthewcroughan>
And we know that isn't true ;D
<ashkitten>
probably worse than guix
<samueldr>
meh, "keep alphabetized" and it's not, for me it's a mess
<eyJhb>
ashkitten: Does guix do it better?
<eyJhb>
Ie. do they have better tooling for such things as node?
<drakonis>
they do.
<ashkitten>
not sure
<drakonis>
hold on
<matthewcroughan>
Guix is part of the same family. When I say "others", I mean things like Fedora/Debian/Arch.
<matthewcroughan>
that said, I'm now interested in how Arch does node packages..
<eyJhb>
drakonis: I am holding
<matthewcroughan>
Do traditional distributions deal with node packages? I can't say I actually remember installing any node packages via those distros.
<drakonis>
apologies, the closest thing to flakes in guix would be its "channels"
<samueldr>
nix-channel, the CLI tool; channels the concept of a URL with the latest tested changes; "ambiant" channels from nix-channel the CLI in NIX_PATH (debatable if different from the next); "channels", but really it's the angled brackets syntax <nixpkgs>
<drakonis>
and various other features like time-machine which allows you to pin or access older revisions of repositories
<matthewcroughan>
λ@nix.how isn't valid either. Not fair.
<samueldr>
when I say ambiant channels, I mean the default NIX_PATH with /nix/var/nix....somehing...
<ashkitten>
drakonis: do you use guixsd?
<drakonis>
i do
<eyJhb>
Am I missing something. Can guix be used in place of ie. Go?
<drakonis>
also they call it guix system now
<drakonis>
yes
<ashkitten>
oh
<drakonis>
their build systems are an implementation of build systems a la carte
<drakonis>
so they can replace existing ones
<matthewcroughan>
drakonis: Can I build embedded images that do one thing, for Pi's and such?
<drakonis>
yes
<matthewcroughan>
That's something I want to do with Nix but really am struggling with.
<drakonis>
they have examples for that
<drakonis>
i apologize for stealing people away :v
<matthewcroughan>
Simply because nothing seems to cross-compile :D
<matthewcroughan>
(for armv7)
<samueldr>
btw, I wasn't saying it as a correction, only a reminder because I've seen some discussions not agree on which definitions they were talking about :)
<drakonis>
i know
<matthewcroughan>
Does docker work in Guix?
<ashkitten>
drakonis: does guix support musl or static compilation?
<drakonis>
i'm aware that we have word overloads
<drakonis>
yes
<drakonis>
that's a thing
<__monty__>
Uhm, Build systems á la carte is an overview so that doesn't make sense to me. You mean they subsume all the features discussed in the paper?
<drakonis>
yes
<matthewcroughan>
if docker works, and I can make an image for a pi that works, I'm sold.
<ashkitten>
can you specify who you're replying to? there's a lot of questions happening :)
<matthewcroughan>
Now, how would I update it over the air using deployment stuffs?
<drakonis>
guix deploy
<matthewcroughan>
scary
<drakonis>
nixops is available on the default package :v
<drakonis>
ashkitten: okay so, you can do musl and static compilation by modifying the build system
<ashkitten>
drakonis: like, with nixos (theoretically) you could just use nixpkgs.pkgs = pkgs.pkgsMusl and it'd work (if cross compilation was actually well supported in nixpkgs)
<drakonis>
with guix it is doable to achieve something similar through package inheritance
<matthewcroughan>
samueldr: it's not particularly supposed to do anything, I just want a cool email prefix that uses some Nix syntax.
<drakonis>
so you'd just switch a definition to another and have everything inherit the new one
<drakonis>
with musl
<drakonis>
its... easy
<drakonis>
it doesnt get in your way for doing these things, compared to doing anything in nixpkgs
<matthewcroughan>
Te funny thing is, path of least resistance will be chosen by people.
<drakonis>
indeed
<matthewcroughan>
So even if Guix is genuinely superior in some regards, I think Nix is going to win, looking at the community.
<drakonis>
well...
<matthewcroughan>
Just my personal bias/opinion on it atm.
<drakonis>
guix seems to be the path of least resistance right now
<drakonis>
except for the size of the repository
<drakonis>
but that can always change in time
<matthewcroughan>
Do they have anything like Flakes?
<drakonis>
yes
<ashkitten>
matthewcroughan: we don't
<ashkitten>
lol
<ashkitten>
and flakes are actively tearing the community apart, too
<ldlework>
I think nixlang is actually a pretty great tool for the job, it's the library I take issue with.
<ldlework>
the "library"
<drakonis>
ldlework: you mean the lack thereof?
<ashkitten>
there's not even an active rfc for flakes
<ashkitten>
and the fact that people are using them as if they're an officially supported part of nix is a problem
<ldlework>
it's kind of there, but the naming is inconsistent and baffling and the documentation is source code
<ldlework>
it feels very PHP circa 2001
<matthewcroughan>
drakonis: well, what's the difference between using the time-machine, and the following: `nix build github:nixos/nixpkgs/commit-hash#package-name` ?
<eyJhb>
ldlework: We need a consistent API in nix...
<ldlework>
yes with a modern beautiful aesthetic too
<ldlework>
there's no reason you need to name your functions after the type theory that underlies them
<ldlework>
or whatever
<ashkitten>
drakonis: is there a search tool like search.nixos.org for guix?
<drakonis>
yes
<drakonis>
also uhhh
<drakonis>
`guix search` is significantly nicer than needing a website for searching packages
<drakonis>
but most certainly there is a page for that
<ashkitten>
early cutoff = content addressed store?
<drakonis>
i guess so?
<drakonis>
seems like it
<drakonis>
shepherd is also going to go down a systemd-ish design with socket activation and timers, given some more time
<matthewcroughan>
drakonis: so instead of systemd, what does guix use?
<drakonis>
shepherd.
<drakonis>
its guile you see
<matthewcroughan>
I thought that was someone's name :D
<ashkitten>
i do think we could revamp nixos to be better if we had a coordinated push
<drakonis>
parametrized packages...
<drakonis>
watch as every gentoo user hops into the guix train
<matthewcroughan>
drakonis: Do you think Guix is currently more popular than NIxOS?
<MichaelRaskin>
ashkitten: I think this wording is a bit of begging the question. The main problem of coordination is that we do not have a single «better»
<drakonis>
that's a very direct question
<drakonis>
we do not have goals
<drakonis>
that's what
* joepie91
thinks it's good to learn from Guix in improving NixOS, but also thinks that "people use a sensible dependency system" is a more important goal than "people use OUR sensible dependency system"
<drakonis>
principles really
<ashkitten>
whatever happened to rewriting nix in rust anyways
<das_j>
oh really? somebody started a rust rewrite? :o
<drakonis>
hnix is still happening, but during the period that flakes were being developed, various rust bits were in tree
<ashkitten>
is hnix set to replace nix?
<drakonis>
i dont think so
<ashkitten>
imo nix really badly needs to be rewritten. it's really hard to work with its codebase
<ehmry>
nix needs to be portable, so I don't see that RIIR can happen
<ashkitten>
i tried to have it flush logs to disk as they were produced, so i could consume them in a nix-top rewrite, but i could not for the life of me figure out how to do that
<ashkitten>
ehmry: idc what it's rewritten in but the current codebase is messy and hard to understand
<ashkitten>
haskell seems fine to me
<MichaelRaskin>
ehmry: I think Nix has pretty bad portability, and Rust improve theirs
<ashkitten>
also true. plus gcc will have a rust frontend within a couple years
<ashkitten>
rust is gonna be everywhere
<drakonis>
wellllll
<drakonis>
that depends on whether it can maintain parity with rust prime
<philipp>
Reminder to get your tetanus shots.
<drakonis>
yes
<ashkitten>
well at the very least rust-gcc has sponsors
<drakonis>
nix has extreme levels of baggage and cruft accumulated
<drakonis>
nixpkgs that is
<ashkitten>
yeah ;-;
<drakonis>
it isnt just a matter of rewriting nix
<ashkitten>
well, all of the nix ecosystem
<drakonis>
its not going to do away with nixpkgs without a heavy cost
<ashkitten>
pretty much i think all of the nix ecosystem including nix, nixos, nixpkgs, and the community as a whole needs a refresh
<__monty__>
<insert xkcd about standards>
<MichaelRaskin>
(me: pretty sure in each case this refresh and cruft removal would break what I consider the actual most valuable feature)
<ashkitten>
which is?
<MichaelRaskin>
Well, there are options what exactly will be broken
<MichaelRaskin>
But some people consider Turing completeness of Nix cruft
<ehmry>
wouldn't it better if we could think of new things to do instead of rewriting old stuff?
<ashkitten>
no
<ehmry>
right, you're a rust person
<ashkitten>
because we can't have nice things on broken foundations
<MichaelRaskin>
It would be for me, because you would not be breaking the useful stuff
<ashkitten>
ehmry: me liking rust has nothing to do with it
<joepie91>
ehmry: that is not a helpful comment.
<MichaelRaskin>
ashkitten: have you just refused to use Nix on either x86_64 or Linux?
<samueldr>
why not both? an exploratory project can be valuable into learning how to improve things
<ashkitten>
MichaelRaskin: lol. i'd love if that were possible
<ashkitten>
power9 netbsd nixos is be a dream
<ashkitten>
is a dream
<ashkitten>
editing on phone is be a bad
<MichaelRaskin>
Not even sure NetBSD counts as non-broken foundation
<matthewcroughan>
NetBSD doesn't work on a 32 bit laptop I have.
<matthewcroughan>
Hp Compaq nc6120, install fails.. lol.
<matthewcroughan>
Where it fails, Nix succeeds actually.
<ashkitten>
matthewcroughan: that sounds like an issue. have you talked to people about it?
<matthewcroughan>
ashkitten: Yeah, I've been through a lot with that thing. And in fact, Guix also fails.
<matthewcroughan>
FreeBSD works, Nix works.
<matthewcroughan>
Alpine works.
<matthewcroughan>
Nix is the best.. because I get access to all those packages. I'm even running tailscale on it.
<ashkitten>
we have a server with a raid controller netbsd's bootloader doesn't like. it's definitely a thing where a fix would be welcomed
<ashkitten>
but even aside from compatibility with older hardware, netbsd is just cooler and better than linux imo
<matthewcroughan>
Why?
<ashkitten>
it doesn't have legacy cruft
<matthewcroughan>
I mean, I know its packages can run with the minix microkernel.
<matthewcroughan>
ashkitten: example of legacy cruft?
<samueldr>
ashkitten: can't run C?
<samueldr>
no bash? ;)
<samueldr>
(sorry I'm not being helpful)
<matthewcroughan>
By that token, you should love RedoxOS
<MichaelRaskin>
Legacy cruft keeping to work is why I like Linux, actually
<ashkitten>
matthewcroughan: legacy cruft like replacing old interfaces with new ones, instead of rewriting the interfaces and adding a compatibility layer
<matthewcroughan>
it gets a mention in the article I linked to :D
<matthewcroughan>
too*
<ashkitten>
samueldr: yeah, seamless hyperlinking across the entire os including source code is awesome
<drakonis>
i remember that the repo linked in the tweag post hasnt seen any more activity since then
<drakonis>
it sucks that it isnt being used for anything in practice
<matthewcroughan>
Indeed.
<matthewcroughan>
Anything can happen. I'd really like to see Nix win, considering I've spent so much time on it.
<samueldr>
ashkitten: *rich* interface, even when textual
<qyliss>
ashkitten: the NetBSD developer sitting next to me says that there's a 64-bit powerpc port, but no drivers for POWER9 hardware
<matthewcroughan>
But in reality, it doesn't matter, all that matters is that something reproducible exists and is used.
<samueldr>
ashkitten: the fact 3D models are shown in-line in the code is really interesting
<matthewcroughan>
I'll use Guix and Scheme instead of the Nix DSL if it wins, begrudgingly. I so far prefer the Nix dsl :D
<matthewcroughan>
Am not precious about the system.
<drakonis>
only time and the decisions made will tell
<matthewcroughan>
Just please.. please. No more bitbake.
<drakonis>
oh, yeah.
<ashkitten>
qyliss: huh. yeah i was pretty sure it works on ppc64. well, we have a blackbird and a netbsd dev, so maybe eventually... :)
<ashkitten>
qyliss: unfortunately the blackbird doesn't work because drew devault left the motherboard unscrewed during shipping. eventually we'll fix it though...
<drakonis>
wait what...
<drakonis>
you buying it off drew devault?
<qyliss>
he was giving one away at one point
<ashkitten>
he gave it to us on the promise that it would be used for development
<ashkitten>
but yeah then he also broke the damn thing
<qyliss>
ashkitten: since you're not in #nixos-exotic, you might be interested to know that I just cross-compiled the first working dynamically linked NetBSD binary from Nix in years
<ashkitten>
ooh!
<drakonis>
woah, nice.
<matthewcroughan>
drakonis: are there any egregious parts of the Nix language that you can explain?
racoon has joined #nixos-chat
<ashkitten>
joined that channel, also
<matthewcroughan>
I wonder if I'm using "babby's first functional language" with Nix, or if it's actually powerful, modern and new.
<matthewcroughan>
Are there any outstanding flaws that you think makes this language look bad?
<qyliss>
probably the former
<drakonis>
its definitely the former
<qyliss>
as functional languages go, Nix is not great
<ashkitten>
it's incredibly clunky
<ashkitten>
and the standard library is all over the place
<matthewcroughan>
Do you think experienced functional programmers would struggle with Nix?
<qyliss>
no
<qyliss>
they'd just find it annoying
<matthewcroughan>
Do you think it's easier to learn something like lisp/scheme than Nix?
<qyliss>
will probably take a while for the working NetBSD cross to be in Nixpkgs btw, because it has to go via staging and depends on a PR Ericson2314 hasn't even posted yet
<drakonis>
lisp/scheme has significantly more tranferable experience
<matthewcroughan>
It's quite interesting actually. There's a guy I live with who has recently been learning LISP out of a book and doing very well with it.
<ashkitten>
fingers crossed to eventually run nixos on the netbsd kernel? :3
<drakonis>
the nix dsl is an arcane piece of code with kind of bad documentation
<qyliss>
ashkitten: that's definitely somebody's plan
<qyliss>
not sure it's mine
<samueldr>
ashkitten: eventually's a long time
<matthewcroughan>
His first programming language is LISP. And I'm wondering whether he'd even be able to intepret Nix. And I wonder how intuitive GUIX would be to him.
<qyliss>
ashkitten: have you seen the GH issue?
<samueldr>
ashkitten: it's the whole time it's done yet!
<samueldr>
100% of it!
<ashkitten>
qyliss: i have not! i've just been yelling about wanting nixos on other kernels in here forever
<{^_^}>
#26850 (by boomshroom, 3 years ago, open): Support non-Linux kernels in NixOS
<ashkitten>
but i'm not actually skilled enough to do anything about it
racoon has left #nixos-chat [#nixos-chat]
<drakonis>
hm
<qyliss>
tl;dr, somebody is porting systemd to NetBSD, and I'm working on NetBSD support for Nix and Nixpkgs
<matthewcroughan>
Why does Nix have the larger community if it's so arcane :P
<drakonis>
and left the channel
<drakonis>
because nixpkgs is huge
<matthewcroughan>
I struggle to understand why Nix is attracting users like it is, yet there are so many complaints about its fundamentals.
<drakonis>
the main drive of nix's growth is due to it
<MichaelRaskin>
Because Guix is a fork of Nix, so late to the game
<drakonis>
because you can find anything
<samueldr>
nah, because no one can be content with what they have :)
<matthewcroughan>
MichaelRaskin: I spat out my tea.
<drakonis>
guix has been around since 2012 i think?
<matthewcroughan>
Had no idea.
<qyliss>
matthewcroughan: what technology are you aware of where very experienced users don't have loads of complaints about the fundamentals?
<matthewcroughan>
qyliss: docker
<drakonis>
its not so much of a fork these days
<qyliss>
you're talking to different docker users than me then
<MichaelRaskin>
They have _one_ complaint for docker?
<samueldr>
generally you don't hear loads of complaints when it's terribly bad :D
<drakonis>
it only uses a heavily modified nix daemon at this point
<drakonis>
it has very little code left and they're close to completely converting it to guile
<MichaelRaskin>
Don't forget that reference point for Nix is, dunno, RPM spec?
<drakonis>
huh.
<MichaelRaskin>
Nix is a pretty annoying and limited programming language. But you can actually discuss the question how bad it is as a _programming language_ at all…
<drakonis>
wow.
<ashkitten>
qyliss: oh, systemd on netbsd? but then i won't be able to get ky0ko to use it :p
<ashkitten>
maybe eventually we can have support for different service managers or whatever
<qyliss>
I don't see that as feasible
<qyliss>
especially not if the only motivation is other kernels, which is a very obscure feature
<qyliss>
if what you want is NixOS on another kernel, I think InitWare is the only path forward.
<qyliss>
at least for now
<matthewcroughan>
The thing about systemd is that we're using it for a reason. It does things that other inits can't actually do.
<__monty__>
From a nix-darwin perspective I have to say it looks a lot simpler to abstract the services.
<matthewcroughan>
If the other inits did those things, then it'd be possible.
<__monty__>
*modules, I guess.
<ashkitten>
matthewcroughan: other init systems can do a lot of things you probably don't know about. i get schooled on this every time i bring it up at home
<matthewcroughan>
It's like right now I'm converting from .rst format to .md format, for some documentation. In doing so, I'm losing .rst features. I happen not to want them. But with systemd -> another init, maybe things don't reload the way they used to.
<MichaelRaskin>
The real value is config generators. If you fix RFC 0078 and write your own bootscripts, do you _really_ need NixOS?
<matthewcroughan>
ashkitten: it doesn't matter if they can do wacky crazy things. If it's not possible to write a service that reacts to another service, laptop hibernation and more, easily, then it just isn't feasible.
<drakonis>
maybe...
<drakonis>
are we inching close to writing a new init?
<qyliss>
what does laptop hibernation have to do with an init/service manager?
<matthewcroughan>
ashkitten: for example, can you propose a way to do services.printing.startWhenNeeded in another init?
<matthewcroughan>
Quite a complex interraction, the incentive for porting it to another init isn't very convincing to me.
<MichaelRaskin>
matthewcroughan: if it is impossible to log vsftpd start-up errors properly just because the logging model is clearly broken beyond repair, it should also be just not feasible
<ashkitten>
dbus activation is separate from systemd. it just so happens that systemd has tight integration with dbus
<MichaelRaskin>
But oh well
<matthewcroughan>
MichaelRaskin: I have next to no opinions on that implementation detail.
<matthewcroughan>
qyliss: I can make a service react to laptop hibernation by following `systemd-suspend.target`
<qyliss>
also there's no reason that init needs to be involved here
<__monty__>
You don't need to support *all* of systemd's features imo. Just having the part of modules that's compatible be usable on other service managers is a win in my book.
<qyliss>
there's no reason intrinsic reason that init needs to also be your service manager
<matthewcroughan>
sure, but the fact that it is, is what allows nixpkgs to be so *integrated*.
<matthewcroughan>
there's no intrinsic reason for anything
<qyliss>
no it isn't
<qyliss>
systemd could do service management outside of init (and already does to a great extent)
<philipp>
Plus the extend of sysemd features actually being used inside of nixos modules varies greatly.
<qyliss>
but yes, it's also true that systemd-suspend.target is not a feature that every NixOS user needs
<qyliss>
systemd is the only game in town for features people need for laptops, but lots of people run NixOS on servers where other service managers get the job done just fine
<matthewcroughan>
Sure.. but why gimp things arbitrarily?
<matthewcroughan>
What is the proposed value of removing systemd?
<qyliss>
who is proposing removing systemd
<MichaelRaskin>
Having tmux work reliably
<matthewcroughan>
What do you mean when you suggest that not everyone needs systemd then?
<matthewcroughan>
Is that not suggesting that there's no need to have systemd around?
<qyliss>
21:27 <ashkitten> maybe eventually we can have support for different service managers or whatever
<qyliss>
that was the comment that started this conversation
<matthewcroughan>
Yeah, I think that's not going to happen for the reasons I've suggested.
<matthewcroughan>
Because there's no actual value in it (in my opinion)
<matthewcroughan>
So that's why I'm asking, what do you think the value is?
<qyliss>
simplicitly, personal preference, support for other kernels, auditability, stability
<matthewcroughan>
It's a lot of work to get a service able to work outside of a systemd context. You'd have to do that for every package in Nixpkgs, so I don't believe it will occur to all of nixpkgs.
<qyliss>
you mean every module in NixOS
<MichaelRaskin>
Having logging not obviously broken. Having tmux work reliably. Not having changing power management defaults on service manager upgrades. Not having random ideas of systemd about VT management
<matthewcroughan>
qyliss: yes, that's what I mean. Though they're synonyms :P
<MichaelRaskin>
Very not synonyms
<matthewcroughan>
Oh, sorry. Yes.
<ashkitten>
support for other kernels is a big thing, because systemd only supports linux
<matthewcroughan>
Options, modules.
<MichaelRaskin>
And not every module, really, half of them can be exported in a reusable state for another service manager right now
<ashkitten>
qyliss said someone is porting systemd to netbsd but that's only one thing and a lot of effort at that
<qyliss>
ashkitten: they're actually porting it to all BSDs
<qyliss>
but NetBSD is their main focus
<matthewcroughan>
Y'all not seen nixng?
<lovesegfault>
Does anyone remember a little while ago when I was packaging a self-extracting binary
<qyliss>
and also possibly illumos
<lovesegfault>
and I had figured out how to do it
<lovesegfault>
and I said so here
<lovesegfault>
because I forgot
<ashkitten>
ooh nixos on illumos?
<lovesegfault>
and now me is dumber than past me and can't figure it out again :P
<qyliss>
ashkitten: that was my original goal
<qyliss>
I'm from illumos
<qyliss>
(my first job was illumos)
<qyliss>
but BSD is easier to get working
<ashkitten>
i didn't know that! that's really cool
<qyliss>
although I don't think I have any use for illumos nowadays, I'm still nostalgic for it
<ashkitten>
hmmmmmmm nixos on haiku
<drakonis>
on haiku eh?
<drakonis>
also uhh
<drakonis>
guix runs on hurd if you're into that
<matthewcroughan>
Oh yeah I saw the guy porting that in #nixos
<matthewcroughan>
he was very dissapointed because Haiku didn't support a certain kind of symlink that is required by Nix :D
<lovesegfault>
aha! I remember!
<lovesegfault>
upx -d
__monty__ has quit [Quit: leaving]
<ashkitten>
nixos on everything
<matthewcroughan>
The question is, can the guix tools run on a device with 512M of Ram.
<matthewcroughan>
I have an armv7l orange pi zero. I really wanna build for it. But Nix just seems impossible. I've been unable to cross-compile a working image.
<matthewcroughan>
u-boot claims it's starting the kernel, but it doesn't get past that.
<ashkitten>
guix probably has better cross compilation
<matthewcroughan>
ashkitten: what do you think the technical reason for that is?
<makefu>
matthewcroughan: are you sure that it "doesn't get pat that"? because often times it simly does not show anything on the serial console and it takes some (considerable amounts of) time
<ashkitten>
matthewcroughan: because their whole package system is better designed and they actually have standards
<matthewcroughan>
makefu: yeah I am.
<makefu>
cross compilation is actuall quite nice. the main issue is mostly about bad support of custom hardware platforms and of all their quirks
<matthewcroughan>
This is the difference. rpizero1 prior to my modifcation, builds armv6 and boots on a Pi. After this commit, I expected it to build for armv7l and boot on an orange pi zero, but it gets stuck at "Starting kernel". Whereas the image from qolii (https://github.com/qolii/nixpkgs/releases/tag/sd-image-ARMv7-68aad73) actually works and boots.
<samueldr>
did you change the kernel?
<samueldr>
the raspberry pi image most likely builds using the vendor kernel for the raspberry pi
<matthewcroughan>
I've tried a range. Including going back to the one that Qolii suggests in the readme for the release.
<samueldr>
including using their kernel configuration
<drakonis>
matthewcroughan: so running guix on a rpi4 is being dealt with
<drakonis>
thanks cole
<makefu>
matthewcroughan: for orangepi zero you may also need to change the serial console to use
<matthewcroughan>
I've checked the extlinux.conf of the working sd-image and the one I produce, they are the same.
<samueldr>
same down to the hashes?
<matthewcroughan>
The lights that usually light up, do not light up, with my image.
<matthewcroughan>
samueldr: I'll check that soon.
<samueldr>
LEDs on most cheap SBCs are software-controlled
<samueldr>
and may or may not represent anything useful depending on the software
<matthewcroughan>
Yeah, and that's why I think it's not working properly. Because my sd-image doesn't do anything with the lights, whereas Qolii's does.
<matthewcroughan>
So if it's just log output, it seems strange that this behavior would have changed from Nixos <20.09 to now.
<samueldr>
they the hashes won't be identical
<samueldr>
then*
<samueldr>
which means you're comparing the least important part of the system
<matthewcroughan>
Well, I've tried Qolli's extlinux on mine, and the result is the same, how about that? :D
<matthewcroughan>
That should indicate that it's not the problem at least.
<samueldr>
"it" what?
<matthewcroughan>
the sd card of the orange pi zero
<matthewcroughan>
Well, you already know, the boot process has changed a lot from 19.03 -> 20.09
<matthewcroughan>
so now the dirs are different, I've no reason other than suspicion to accuse that
<matthewcroughan>
and of course the partition layouts are different as a result of that
<samueldr>
yeah, but obviously here it loads an extlinux.conf file, the initrd and kernel, so the important parts that changed won't matter because if it was that the extlinux.conf file wouldn't be used
<samueldr>
so the partition layout is a non-issue
<matthewcroughan>
Whipping out my serial cable again...
<gchristensen>
hrm. unprincipled DAGs are a bit annoying
<matthewcroughan>
samueldr: what exactly can I do to debug this then? Can I maybe boot the image in qemu and get any further?
<matthewcroughan>
The ethernet lights are stuck on, which proves the kernel hasn't initialized anything.
<samueldr>
hard to say, the main thing you want right now is figure out what's wrong
<samueldr>
I can't guess at it any more than that
<matthewcroughan>
Damn :P
<samueldr>
but U-Boot gives control to the kernel, if the log is still right
<matthewcroughan>
Yeah, and then the kernel doesn't give me even 1 byte back haha
<elvishjerricco>
samueldr: Yea I'm actually seeing what happens when I build it now :P
<elvishjerricco>
But I'm not trying a special nixpkgs version
<elvishjerricco>
so it'll probably break
<samueldr>
but I've only went as far as build the sd image and iso image
<matthewcroughan>
samueldr: I'm trying with that branch in my nixpkgs :D
<samueldr>
and on armv7l, only booted the iso image on tow-boot
<samueldr>
so maybe the sd image's boot flow won't work
<elvishjerricco>
Doesn't the iso image still have the user management script I mentioned though? That should fail to build...
<matthewcroughan>
samueldr: It used to work in 19.03, and I've observed that since then, it hasn't worked.
<samueldr>
elvishjerricco: true that I didn't test its installation
<matthewcroughan>
And I went as far as tracing back how the cd-dvd/sd-image.nix worked, to see these changes. It just seems suspicious :D
<samueldr>
since it would have required building all of armv7l things
<samueldr>
elvishjerricco: but recently there was a huge breaking change in cross-compilation with a correctness fix that, probably, fixed what you had in mind
<elvishjerricco>
Hm. Ok then
<matthewcroughan>
samueldr: how recent? Weeks or months?
<samueldr>
months
<matthewcroughan>
I've probably benefited from this change then.
<samueldr>
but matthewcroughan, totally not your issue
<samueldr>
since your kernel doesn't boot
<elvishjerricco>
But I'm assuming not in 20.09? :P
<samueldr>
you really have to figure out why the kernel doesn't boot before trying to blame loads of unrelated changes
<samueldr>
elvishjerricco: nope, but IIRC 20.09 still cross-compiled fine as-is with cross-system
<samueldr>
I might be wrong
<matthewcroughan>
samueldr: well, keep in mind that the only thing I can get to build armv7l is github:colemickens/nixpkgs/crosspkgs, so maybe something's just not cross-compiling correctly there.
<matthewcroughan>
I'm now recompiling the whole thing with your wip/armv7lfixes.
<elvishjerricco>
Well, we'll see if this just works then...
<matthewcroughan>
samueldr: I actually couldn't get 20.09 to cross-compile using crossSystem, I'll try again, my issues are as recent as 15 days ago.
<samueldr>
AFAIK no "cross-compiling changes" should affect a built kernel
<samueldr>
it either builds, or won't
<samueldr>
now if it runs or not, that's totally another issue
<samueldr>
and this has veered way too on-topic for #nixos-chat for a while
<matthewcroughan>
Yeah that's what I'm thinking.
<matthewcroughan>
there's no #nixos-armv7l is there? ;D
<elvishjerricco>
to #nixos-aarch64! Close enough :P
<gchristensen>
aarch64 should be really renamed to arm :P
<samueldr>
renaming a channel's not a thing though :(
<gchristensen>
yeah
<MichaelRaskin>
Well, one could put a forward on it, no?
<samueldr>
won't move existing people
<samueldr>
well, joined, and existing
<matthewcroughan>
Freenode won't exist soon anyway, there'll be no problem creating new rooms.
<samueldr>
and really until we have actual non-aarch64 support it's a trap!
<elvishjerricco>
freenode won't exist?
<samueldr>
matthewcroughan: oh, got some actual news on that or just some unfounded FUD?
<matthewcroughan>
Well, no. It was mostly a joke.
<samueldr>
elvishjerricco: read the backlog from IIRC yesterday, and maybe this morning too, there's been some development about freenode
<matthewcroughan>
Some guest earlier posted some large gist about how the guy who owns the freenode domains is going to screw up the dns records.
<samueldr>
joking like that with what amount to FUD is not really great in an already concerning situation
<matthewcroughan>
Hey, I like to laugh at everything.
<matthewcroughan>
Don't rain on my parade :P
<gchristensen>
yeah, please remain calm and chill about it
<joepie91>
matthewcroughan: guest was me
<joepie91>
identify failed
<matthewcroughan>
ah ok
<matthewcroughan>
Well, either way, hopefully the infrastructure remains.
<matthewcroughan>
Would be nice to know what can be done to help that happen.
<gchristensen>
from a few days ago: ... my inclination is to stay calm through initial tumultuousness, and unless service really falls apart right away, try to ride it out and take careful steps, useful to note that the fuchs post starts with a header saying it is a draft, and fuchs hasn't resigned ... ideally this channel would stay relaxed about the whole thing until we get past the shitstorm and in to
<gchristensen>
results
<samueldr>
good summary
<samueldr>
and since this is a sensitive topic, anything that amounts to FUD shouldn't be tolerated
<gchristensen>
+2
<matthewcroughan>
Why is it sensitive? It's just IRC. And it's actually more stable than Discord.
<matthewcroughan>
Users could tolerate switching domains! :D
<drakonis>
my only position regarding this, is to have an migration path if it gets worse
<gchristensen>
let's wait and see what happens over the next couple days
<matthewcroughan>
Don't you think giving people the power to threaten you with DNS is worse? Isn't this an ongoing threat?
<drakonis>
otherwise, business as usual
* samueldr
can't deal with how y'all have the same nick colour right now
<gchristensen>
I don't think it is likely anything significant will happen over the next few days, I'm not at all worried about it
<samueldr>
sounds like you're fishing for FUD or reactions on a developing story that is external from us...
<gchristensen>
we're well connected to the freenode team :)
<gchristensen>
on that note, I talk to staffers on a daily basis to hear the latest, the issue isn't being ignored
<jess>
\o
<jess>
i can answer questions if you've any that are burning
<cole-h>
jess: how cool are sand cats
<jess>
my advice in general is to sit tight and wait for stuff to unfold more. any serious/risky changes will get communicated as fast as possible
<samueldr>
jess: what did you eat last meal?
<samueldr>
(I'm actually peeved that cole-h stole my thunder with an unrelated question)
<cole-h>
>:)
<cole-h>
I learned from the best
<cole-h>
but also, you're too slow
<gchristensen>
haha
<elvishjerricco>
15min loadavg 29. I love threadripper.
<elvishjerricco>
But the kernel still takes so long to build...
<samueldr>
elvishjerricco: I/O bound probably
<elvishjerricco>
CPU's been pegged all the way this whole time pretty much
<elvishjerricco>
I just realized, if I can get tow-boot working, then I can't put an arm boot loader on my nvme drive and boot this same nvme drive on either my threadripper or my cm4... That's pretty neat
<elvishjerricco>
can*, not can't
<samueldr>
>> then I can put an arm boot loader on my nvme drive
<samueldr>
I guess you mean an actual bootloader, e.g. GRUB?
<elvishjerricco>
yea
<samueldr>
yes!
<samueldr>
well... mixing arches like that is bound to be hard
<samueldr>
but yes in theory!
<samueldr>
clever did that once
<elvishjerricco>
isn't it just a matter of putting /boot/efi/boot/bootaa64.efi or whatever in place, and having a grub menuentry that boots an aarch64 generation of nixos?
<samueldr>
basically
<samueldr>
"just" that
<elvishjerricco>
fair enough
<samueldr>
writing the commit message before testing the change is hubris
<samueldr>
(and committing the change)
<ashkitten>
huh that's a use case i hadn't thought of for nix
<ashkitten>
mixing arches
<elvishjerricco>
Yea people talk about having a usb drive with multiple distros. How about a usb drive with multiple architectures :P
<samueldr>
as long as you don't have anything installed for your user, should work fine enough
<samueldr>
I wonder with --optimise'd store how much bigger you get
<ashkitten>
i guess you could totally have the same system config for multiple arches and share the root partition