<sphalerite>
niksnut: could I have the restart-jobs permission for my github-based login too? It's a lot easier for me to use than the google one, and it's also not tied to my work account :)
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
jonringer has joined #nixos-dev
mkaito has joined #nixos-dev
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
dstzd has joined #nixos-dev
dstzd has quit [Client Quit]
Synthetica has joined #nixos-dev
<gchristensen>
I'm thinking hydra's machine status page should forget about machines after they're missing for some period of time
<domenkozar[m]>
but think about all the children
<gchristensen>
yeah
<gchristensen>
I'm just looking at a hydra page which has scaled up to a few hundred builders, scaled down to 1 builder, and also recycles its builder on a daily basis and it is just a sea of IP addresses, all disabled
<domenkozar[m]>
I don't understand the value of crossed out entries in hydra
<domenkozar[m]>
why not just remove them?
<gchristensen>
I think it is useful to call out the fact that a builder is disabled if you still expect it to be enabled
<gchristensen>
like they can be disabled if they're broken, not just absent
<gchristensen>
and for metrics tracking you want to keep removed builders around for "a while" so metrics can be exported
<gchristensen>
so I see reasons why it is this way
<domenkozar[m]>
ah it also supports disabling?
<domenkozar[m]>
didn't know that
<domenkozar[m]>
seems like there needs to be a status label then
<gchristensen>
yeah, if a machine fails to build a thing (for abnormal reasons) it disables the machine for a while
<domenkozar[m]>
hercules ci shows that + how long it has been so
<domenkozar[m]>
(if it was up to me, I'd switch NixOS projects to hercules ci and thus get Robert to help out on such issues, removing a lot of work from volunteers)
<domenkozar[m]>
worst case it can always be migrated to somewhere else, but this would solve a lot of problems
<gchristensen>
I can understand that perspective, though I'm not personally keen on staking such a fundamental piece of our infrastructure on a proprietary tool
<domenkozar[m]>
what does that mean exactly?
<gchristensen>
I mean that being able to evaluate and build all of nixpkgs and nixos is a keystone to "is nixos a thing?" and having the tools to do that be foss, I feel, is important for a foss project
<domenkozar[m]>
we already use github
<domenkozar[m]>
and I don't understand that requirement either
<domenkozar[m]>
why is it important?
<domenkozar[m]>
I mean technically agent is foss and that's where all the magic happens
<gchristensen>
it is just a feeling, I guess
<domenkozar[m]>
once we drop the ideology and talk about real issues, we can solve problems much faster :)
<supersandro2000>
thats always a great idea to create something really great for humanity
<supersandro2000>
actually using github actions should be fine because you can always dump the docker images used, copy the scripts and bins out of them and run it with something else
<domenkozar[m]>
well any Nix CI should be the same really
<domenkozar[m]>
it's no different than git + github
<domenkozar[m]>
call me pragmatist, but I think everyone wins here really: hercules gets a big user to really polish it out and some appraisal, Nix finally gets a better CI developed for free
dstzd has joined #nixos-dev
<domenkozar[m]>
and nixos foundation could sign a contract to assure some risk
<domenkozar[m]>
e.g. if hercules ceases to exist, the foundation gets rights to run it
<domenkozar[m]>
to reassure from risk*
dstzd has quit [Client Quit]
<domenkozar[m]>
roberth: ^^
<gchristensen>
I also would assume that the typical user envelope of hurcules is quite different from the user envelope hydra.nixos.org would require, and putting that on a small company's shoulders seems a bit unfair
<domenkozar[m]>
well that's up to Robert to decide if he takes the burden
<qyliss>
Nixpkgs derivatives, other Nix projects, etc. do not win, because they can't use the same CI system Nixpkgs uses without paying for it or being at the mercy of the free tier
<gchristensen>
I don't think it is all on Robert to decide, but a consideration for the foundation to make as well in terms of deciding to do it
<gchristensen>
it is no fun to be far outside the envelope, even if the provider has made a commitment
<domenkozar[m]>
qyliss: it's free for open source?
<qyliss>
domenkozar[m]: currently
<domenkozar[m]>
well that could be part of the contract if that's a risk we're worried about
<qyliss>
projects that don't use GitHub also do not win
<domenkozar[m]>
they can still use Hydra or whatever they do
<qyliss>
right, but Hydra would lose out on development
<adisbladis>
I think this opens up a huge can of worms
<adisbladis>
Namely, are we a FOSS project or not
<adisbladis>
If we are we should have a FOSS mindset, everything the foundation uses officially should be FOSS
<domenkozar[m]>
so we're open sourcing github?
<domenkozar[m]>
and making our own CDN?
<qyliss>
using github is a problem, not a justification
<domenkozar[m]>
and S3 as well?
<domenkozar[m]>
and we're doing bare metal now?
<gchristensen>
there is a big difference
<domenkozar[m]>
sorry but that's just insane :)
<qyliss>
it's "insane" because it's a strawman
<adisbladis>
domenkozar[m]: That argument is pure trolling.
<domenkozar[m]>
how is that strawman?
<gchristensen>
there are like, layers of "fundamental to the goal"
<ajs124>
hydra isn't really being developed much right now anyways. I still agree with qyliss though.
<qyliss>
I think it would be very unhealthy for the "blessed" CI system to be a single provider we have no control over
<domenkozar[m]>
adisbladis: why?
<domenkozar[m]>
" everything the foundation uses officially should be FOSS" -> I think that's pure trolling since it can't ever be true :)
<adisbladis>
domenkozar[m]: Sure, using Github is not ideal. It doesn't mean we should start relying on _more_ nonfree things.
<domenkozar[m]>
nor it makes sense as a goal
<adisbladis>
Well, your take on FOSS is clearly not aligned with my value set
<adisbladis>
I think it makes sense to aspire to make everything FOSS, even though it may not always be realistic
<edef>
CDNs are fairly fungible
* gchristensen
disengages until the conversation gets to a place of gradations of criticality and opensourceyness
<edef>
and are largely capital plays, the technology is generally Varnish or nginx
<qyliss>
edef: S3 even more so
<edef>
S3 is peak fungible, yes
<qyliss>
there's no vendor lockin with a CDN
<edef>
i'm happy to argue that we shouldn't be using GitHub, and i am hardly alone in that
<domenkozar[m]>
see I want to talk about real issues, my goal is to make Nix a better project for everyone and I think having a requirement for everything to be FOSS is not helpful in any way, clearly because github has enabled us to grow this far (I don't think without issues, but I don't think anything ever is)
<domenkozar[m]>
edef: can you please not hijack the discussion?
<edef>
you brought it into the conversation here
<domenkozar[m]>
ok fair, but let's not argue about that
<halfbit>
want to see nix take off? create a sane yocto replacement
<qyliss>
you are dismissing issues as not "real" because you don't think they're important
<qyliss>
when other people clearly do
<domenkozar[m]>
qyliss: can you be specific?
<qyliss>
this whole conversation is about how you would like to see Nixpkgs use a proprietary CI system, people are concerned with the proprietary aspect of that, and you don't care because you want to talk about "real" issues
<domenkozar[m]>
qyliss: I have asked for concrete concerns around the proprietary property of it and adressed them
<qyliss>
the proprietariness *is* an important reason in itself
<qyliss>
for philosophical or ethical reasons
<qyliss>
it might not be for you
<qyliss>
but it is for me, it apparently is for adisbladis, and so on
<halfbit>
its too bad the nix foundation itself can't provide those services for a fee to help fund further development, foss or not
<domenkozar[m]>
> philosophical or ethical reasons -> that's still to vague to discuss at any merit
<halfbit>
I'd be happy to pay a moderate fee for hosted hydra
<{^_^}>
undefined variable 'philosophical' at (string):462:1
<qyliss>
you don't have to agree, but you do have to respect that other people have the same facts as you and have come to a different philosophical or ethical conclusion
<halfbit>
or another ci
<supersandro2000>
the biggest problem with github is that they can delete issues/PRs/users at there discretion
<edef>
more practically, if there are any issues with the system, we cannot debug it meaningfully
<ekleog>
Not going to enter this discussion, but I just want to say that proprietariness is not per se a problem for me, but I can only agree that something being too proprietary can be for other people. (That being said, it's definitely interesting to see how proprietariness is not a binary too)
<supersandro2000>
everything else could be fixed in an evening to a week
<domenkozar[m]>
qyliss: I do respect that.
<gchristensen>
I don't feel like that has been respected in this conversation
<domenkozar[m]>
gchristensen: how is that so? :|
<edef>
we're reliant on external prioritisation of issues and cannot rely on the community to scratch their itches with their own urgency
<gchristensen>
in response to concerns around propriety the concern jumped to using S3 even, and that felt like ridiculing the concern to me
<qyliss>
domenkozar[m]: I don't think it's worth discussing, because there's 0 chance anybody's mind will change
<ekleog>
For instance, an agreement like “Hercules promises to either keep service free for NixOS forever under penalty of having to giving a MIT license to the NixOS Foundation” would maybe make Hercules OSS-enough for people to accept it
<regnat>
On a practical plane, maybe it's less the case for hercules, but hydra is very strongly tied to Nix, meaning that most big changes to Nix require changing hydra. And having it replaced by a proprietary thing would make these changes to Nix notably more painful
<edef>
yeah
<edef>
nix and hydra are not meaningfully *distinct*
<qyliss>
yeah, vendor lockin to the blessed CI service is *huge*
<edef>
in that changes in Nix frequently require corresponding changes in Hydra
<edef>
synchronised corresponding changes
<domenkozar[m]>
gchristensen: I don't understand how that's disrespectful, that was an example how unreal the argument is that everything should be FOSS
<regnat>
Like I'm very happy that I was able to patch hydra to get it to work with the CA-derivations branch of Nix
<puck>
domenkozar[m]: there's a difference between services that are easily replacable and ones that are more deeply integrated
<domenkozar[m]>
I have disputed an argument, not attacked anyone, so I'm really confused how that's disrespectful
<qyliss>
domenkozar[m]: that was not an argument anybody made
<edef>
domenkozar[m]: "F/OSS, or is a service with a fairly universal interface"
<domenkozar[m]>
qyliss: adisbladis made that argument
<edef>
eg, "IaaS VM", "S3", and "HTTP(S)" are fairly universal interfaces
<qyliss>
no he didn't
<qyliss>
no he didn'
<qyliss>
in fact adisbladis said "I think it makes sense to aspire to make everything FOSS, even though it may not always be realistic"
<edef>
and we don't actually derive any added value from using our own implementation of it — it's very far from our core business
<domenkozar[m]>
quoting: If we are we should have a FOSS mindset, everything the foundation uses officially should be FOSS
<edef>
should ≠ must
<qyliss>
paying somebody to provide a service over a standard interface is not using non-FOSS
<qyliss>
even the FSF doesn't think that
<edef>
if the foundation pays an accountant, we don't really care what software they use to get the work done
<edef>
is it crucial to the foundation that the work get done? yep. is it part of our core competencies, as distro developers? not really
<edef>
distro/package manager developers*, i suppose
<domenkozar[m]>
qyliss: that's my point - Nix is the standard interface here and we can swap the provider at any time.
<edef>
i'm unconvinced
<domenkozar[m]>
not without work and effort
<qyliss>
have you SEEN how much hydra-specific code is in Nixpkgs
<qyliss>
(that's a rhetorical question)
<edef>
there's a lot of historical data stored in that system, status hooks, etc
<edef>
and the things that would go wrong with it are most likely Nix bugs that we would not get to debug in situ
<edef>
Hydra development is largely driven by nixos.org needs, and i don't think we'd end up with a single maintained open CI system for Nix if we stop relying on it
<domenkozar[m]>
changing the status quo will always involve work, that doesn't mean it's the best choice
<domenkozar[m]>
> I don't think it's worth discussing, because there's 0 chance anybody's mind will change
<{^_^}>
error: syntax error, unexpected ',', expecting ')', at (string):462:36
<domenkozar[m]>
I think that kills the discussion for me, so I'll stop threading water :)
<edef>
everything negative one can say about Hydra as it exists today (and i've got plenty!) would apply doubly so to unmaintained Hydra
<gchristensen>
it'd be long unusable if nixos.org didn't use it
<edef>
i'd rather the foundation pay for the engineering hours to produce a better open replacement than to go "actually, there's no maintained open CI system"
<edef>
whether Hercules cares to bid for that contract is their business
<edef>
for Nix/NixOS to be a solid proposition for anyone who isn't already nuts about it involves having solid distributed builds
<Profpatsch>
If I was Robert, it get a few dozen well paying customers and then switch to a 10 hour workweek, not make myself more work lel
<Profpatsch>
s/it/I’d
dstzd has joined #nixos-dev
<domenkozar[m]>
adisbladis: do you think I've been disrespectful?
<adisbladis>
Yes, you're being very dismissive of other peoples view points and experiences.
<domenkozar[m]>
ok
<domenkozar[m]>
adisbladis: in that spirit, is the following sentence disrespectful: I don't think it's worth discussing, because there's 0 chance anybody's mind will change
saschagrunert has quit [Remote host closed the connection]
rajivr has quit [Quit: Connection closed for inactivity]
<tazjin>
<edef> we [...] cannot rely on the community to scratch their itches with their own urgency
<tazjin>
^ I think this is the crux of why proprietary stuff can't really be used for a project like this
kalbasit has quit [Ping timeout: 256 seconds]
kalbasit has joined #nixos-dev
<domenkozar[m]>
tazjin: wouldn't a paid team be better at urgency than volunteers? that's my experience at least
<tazjin>
if we're paying someone, we might as well pay someone to work on an open-source thing - in that case both are available
<domenkozar[m]>
hercules has a freemium model like github
asbachb has joined #nixos-dev
<domenkozar[m]>
tazjin: if you read the discussion above, OSS projects are free
<edef>
no, that strictly contradicts one of my suggestions
<tazjin>
which means its staff would have no incentive to prioritise things this project needs
<edef>
literally the last thing i said
<domenkozar[m]>
oh we're talking about different things then, urgency of development issues or operational ones?
<tazjin>
these aren't neatly separated
<edef>
the operation of nixpkgs is development
<edef>
"service is down" and "service cannot adapt to our needs" both block development
<edef>
it's just a matter of which fraction of development is blocked behind it
<edef>
"service is down, blocks everything" is the far less harmful case, because at least its urgency is obvious to all
<edef>
"service cannot adapt to our needs, blocks refactor / technology progression" is far more costly, because it's a structural issue, you're fighting Conway's law for technical debt you can just as easily accumulate even more interest on
<domenkozar[m]>
which translates from technical to social, do you trust people behind hercules then to really help out
<domenkozar[m]>
I understand that's hard
<domenkozar[m]>
the reason I created cachix for example is to help out OSS not lose time anymore
<edef>
right, and cachix sits in the sweet spot where it's a service that implements a fairly standard interface
<edef>
i don't use cachix but i'm glad it exists
AlwaysLivid has quit [Ping timeout: 240 seconds]
<edef>
cachix isn't really trying to take over cache.nixos.org, though
<edef>
they operate at different scale, have different cost and UX requirements, they're pretty different beasts
<edef>
but they both fit an open, well-understood interface
<domenkozar[m]>
heh ok :) well my point is that I understand that it's hard to trust people rather code, but that it yields a lot of benefits
<domenkozar[m]>
like for example you trust that someone comes and takes the trash out
<edef>
i think that pushing roberth to put nixos.org priorities ahead of those of his other customers is not super chill
<domenkozar[m]>
you can do it yourself and really know it was recycled, but it's not feasible
<domenkozar[m]>
note that my comment was a mere observation of the fact that hydra is far behind what hercules can do, it wasn't even a proposal to move over, not am I connected to hercules in anyway and robert has never suggested this
<domenkozar[m]>
it was merely my opinion and observation :)
<edef>
i think that we could definitely use improvement, but trusting one individual vs a whole community of contributors is a different game
<edef>
eg if there were a greenfield cloud-native Hydra replacement, Mutable would probably run it and send patches
<puck>
yeah
<domenkozar[m]>
what does greenfield mean in that context?
<edef>
as opposed to a Hydra fork or something
<edef>
eg, Hercules when it was looking like it would be community F/OSS with perhaps SaaS options rather than purely proprietary SaaS
<halfbit>
cargo init --bin hexapod, greenfielded
<domenkozar[m]>
edef: you can't build a HashiCorp model on top of Nix
<domenkozar[m]>
we're too small community
<edef>
maybe
<domenkozar[m]>
I have hoped for that and really wanted to
<edef>
i'd like to be making bets on growth
<domenkozar[m]>
but we need to grow 10x before that hapens
<domenkozar[m]>
that's why I'm trying to speed things up so that we can eventually have an OSS core
<domenkozar[m]>
gitlab wouldn't exist without github, that's a bit hard to grasp
<puck>
yes, but (public) git hosting existed before github
<halfbit>
Pushing into yocto use cases could get you 10x growth
<domenkozar[m]>
yet github hosted everything :)
<halfbit>
Nix tooling is easily 10x better than yocto's ridiculously slow tooling
<domenkozar[m]>
halfbit: I agree, I hope someone did that
<puck>
halfbit: i have some feelings on this, just wait :p
<domenkozar[m]>
halfbit: if you know someone that would do that I'm happy to help with what I can
<halfbit>
Me, I'm already in a spot to potentially help make it happen. I'm pushing for funding, but it takes time. The solarwinds debacle helps a lot though, along with stuff like trustix. The real win would be getting a hardware vendor like xilinx, nxp, altera, or stm to support it.
<halfbit>
Forget desktop linux, forget cloud because docker has won the fight. Embedded linux is a garbage fire of slow, complicated tooling
<halfbit>
My humble opinion on the matter.
<halfbit>
Bare minimum is support some SBC's like pi's, pine's, and hardkernel boards though, some progress there is promising I think
<halfbit>
like its a pretty stellar story if you can nix build an image onto flash of some kind on your threadripper and pop it in a arm sbc
<halfbit>
with all the caching and distributed building going on
<halfbit>
sane caching, distributed builds help that story. hydra is ok, but it'd be nicer if I could say, point something like cachix/github actions/hercules at my .nix file that builds an image, and pay $ to have it build faster. That'd be amazing.
<domenkozar[m]>
yeah I've spent some time on researching IOT and if noone else does it I'll do it in a few years
<halfbit>
IoT a lot of times is about a customized kernel
<halfbit>
and supporting the arch
<halfbit>
arm64/riscv/armv7/ppc/etc
<halfbit>
linux on cortex-m is... insanity, forget it.
<halfbit>
ucLinux is not useful imo
<domenkozar[m]>
which is all there, it just needs someone to be paid so it's actively maintained
<halfbit>
right, needs the org/llc, and someone to go pitch it to the right people really
<domenkozar[m]>
exactly, it's not a technical issue :)
<halfbit>
or just get nix into the linux foundatino
<halfbit>
that solves half the problem :-)
<halfbit>
be a platinum member for the mere cost of $1m/yr
<domenkozar[m]>
Nix is in a lot of ways ready for many problems, but we need people that step up that game :)
theophane[m] has joined #nixos-dev
<halfbit>
maybe presenting nix at various IoT conferences to get the conversations/connections would be a start
<domenkozar[m]>
don't think so, someone just needs to get hands dirty
<samueldr>
there's already users on the odroid-n2 I believe
<halfbit>
right, I have armbian on my 3 arm sbc's
<halfbit>
it works quite well mostly
<halfbit>
getting it on something like the xilinx zybo-z7 board would be... even crazier
<samueldr>
armv7l, no binary cache, which makes the experience much less fun
<domenkozar[m]>
which reminds me, someone asked me to get cachix working on armv7l
<domenkozar[m]>
maybe it compiles now
<qyliss>
I've talked to a lot of people interested in armv7l recently
<samueldr>
we could get the armv7l cache up and running with some work still
<samueldr>
I don't know for sure what the current hangup is
<qyliss>
sounds like that would be a great step towards the embedded usecase
<samueldr>
but we have a working strategy for native builds
<domenkozar[m]>
are there good servers for armv7?
<samueldr>
no
<samueldr>
but many aarch64 systems can run 32 bit in emulation
<domenkozar[m]>
right :)
<samueldr>
well, bad word, virtualization
<samueldr>
so we actually run the armv7l machine virtualized, not unlike the macOS builders
<samueldr>
(but forget about armv6l builds, it's likely not going to work well the same way due to the virtualized ISA not being limited to armv6 instructions)
<kalbasit>
how to convert sha256-8r3twBW0N0IkmVAYPd4qpLOrr2xD/4I4QfzSR33901U= to the older format?
AlwaysLivid has joined #nixos-dev
<qyliss>
kalbasit: nix-hash should be able to do that I think
<kalbasit>
qyliss: thanks that worked
<qyliss>
yw :)
grfn has joined #nixos-dev
regnat[m] has left #nixos-dev ["User left"]
cole-h has joined #nixos-dev
<halfbit>
you can use the aws graviton machines to run armv7
<samueldr>
no
<samueldr>
they don't support 32 bit
<halfbit>
seriously?
<samueldr>
yes
<halfbit>
garbage
<samueldr>
many of the server-class AArch64 CPUs are strictly 64 bit AArch64
<halfbit>
booo
<halfbit>
armv7 isn't going away any time soon
<samueldr>
I believe there are benefits [to the system makers] about removing the 32 bit legacy
<samueldr>
but yeah
<samueldr>
extremely annoying to find the proper information on new designs, whether it supports 32 bit or not
<samueldr>
we have to assume, until reported that they do, that they do not
<halfbit>
that is really annoying, I didn't know that
<halfbit>
the allwinner odroid-n2 supports both, bad assumption on my part thinking all parts that support aarch64/armv8 would support armv7
mikroskeem has quit [Quit: WeeChat 3.0]
<samueldr>
btw, armv8 != aarch64
<halfbit>
I'm aware, but most are
<samueldr>
there are 32 bit armv8 designs
<halfbit>
how many in the wild are there really though
<samueldr>
find what uses Cortex-A32 I guess :)
<halfbit>
cortex a32... wonder how many are actually in the wild?
<halfbit>
yeah, just was looking at that
<halfbit>
watch, there's no actual silicon out there
<samueldr>
it's possible
<halfbit>
honestly I'm much more familiar with cortex-m series than the A series, only really started learning A series stuff with the zybo-z7 board I picked up over the holidays