<drakonis_>
now, regarding nix adoption, the outlook seems bright
<drakonis_>
now that it is available on its full form under windows
<drakonis_>
getting it into the windows store will be good
<pie_>
x'D
<Arahael>
pie_: Wasn't there issues regarding sqlite?
<pie_>
huh maybe
<Arahael>
It would otherwise have been an ideal "nix on windows" target, imho.
<drakonis_>
there's some whispering regarding the market looking at NixOS now
<drakonis_>
arahael: its a linux vm now, so it is an ideal target now
<pie_>
whispering?
<drakonis_>
hearsay
* pie_
crashes
<drakonis_>
nix and things alike are the new main distros for deployments
aanderse has joined #nixos-chat
<drakonis_>
this is the hearsay
<drakonis_>
how's commercial support for it?
<drakonis_>
if there's any
<Arahael>
There still seems to be a lot of competing solutions there, imho - appimage, snap, flatpak...
<drakonis_>
s/nix/nixos
<drakonis_>
nix does compete with these package managers
<Arahael>
Personally, I feel that nix and flatpak compliment each other nicely.
<drakonis_>
nixos competes with what though?
<Arahael>
nixos itself competes with docker, maybe.
<Arahael>
PErsonally I like it for the build tooling, so for me, the best thing about nixos is nix.
<Arahael>
(Even though I'm still very new to it)
<Arahael>
I love being able to have a controlled build for a given project.
<Arahael>
(This is why people have been moving to docker: Can bring up an image, do the build, and that's the controlled environment - nix competes with that, imho)
<drakonis_>
if nix winds up in a major conference
<drakonis_>
maybe it can acquire more momentum
<drakonis_>
doesnt have a lot of conference presence outside of nixcon and smaller ones
<drakonis_>
does fosdem as a major one?
<drakonis_>
count as a major con other than being a foss mecca?
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-chat
drakonis has quit [Ping timeout: 264 seconds]
jackdk has quit [Quit: Ping timeout (120 seconds)]
jackdk has joined #nixos-chat
jackdk has quit [Client Quit]
jackdk has joined #nixos-chat
jackdk has quit [Client Quit]
MichaelRaskin has quit [Quit: MichaelRaskin]
jasongrossman has joined #nixos-chat
drakonis_ has quit [Ping timeout: 246 seconds]
drakonis_ has joined #nixos-chat
drakonis_ has quit [Ping timeout: 244 seconds]
drakonis_ has joined #nixos-chat
endformationage has quit [Ping timeout: 248 seconds]
Myhlamaeus has quit [Ping timeout: 258 seconds]
jasongrossman has quit [Ping timeout: 248 seconds]
drakonis_ has quit [Ping timeout: 248 seconds]
drakonis_ has joined #nixos-chat
jasongrossman has joined #nixos-chat
hedning_ has joined #nixos-chat
{^_^} has quit [Remote host closed the connection]
{^_^} has joined #nixos-chat
pie_ has quit [Ping timeout: 248 seconds]
jasongrossman has quit [Ping timeout: 248 seconds]
jasongrossman has joined #nixos-chat
wirew0rm has quit [Ping timeout: 258 seconds]
wirew0rm has joined #nixos-chat
drakonis_ has quit [Remote host closed the connection]
drakonis_ has joined #nixos-chat
pie_ has joined #nixos-chat
pie___ has joined #nixos-chat
pie_ has quit [Ping timeout: 248 seconds]
<tilpner>
During a force push to a GitHub wiki it tells you that the repo moved to the main repo, implying you should force-push the wiki to the code repo
<tilpner>
There's no way that could go wrong, right?
<monsieurp>
tilpner: keep a local copy of the repo in case the SHTF :)
<tilpner>
Oh, I don't intend to
<tilpner>
But I can imagine how that server-side notice might mislead someone
<tilpner>
"But git told me to do that..."
<tilpner>
And they wouldn't even be wrong
<qyliss^work>
lol
drakonis has joined #nixos-chat
drakonis_ has quit [Ping timeout: 246 seconds]
jasongrossman has quit [Ping timeout: 252 seconds]
<{^_^}>
nix#1835 (by chris-martin, 1 year ago, closed): builtins.hashFile
<ekleog>
here, removing builtins.hashFile will be a backwards-incompatible change
<pie___>
ofc there are a lot of issues so im not saying that meant its fine
<pie___>
ekleog, that makes sense i guess
<ekleog>
now I agree that this particular example would likely have passed without issue
<ekleog>
but maybe I'm missing something too
<pie___>
in terms of design by comittee, haskell seems to have done ok for itself
<ekleog>
I would like to argue that the nix language is currently not the best proof of great design :p
<pie___>
but i dont know much about that, probably had a lot of its own pain points
<Taneb>
Haskell was designed by a small committee of people who knew what they were talking about
<pie___>
ekleog, yeah we touched on that discussion a while ago
<pie___>
Taneb, makes sense
<ekleog>
language design is a hard job
<Taneb>
Most of them were researchers in programming language design
<Taneb>
And they had anti-bikeshed mechanisms
<pie___>
id be curious about that latter point
<simpson>
But they still ended up getting : and :: backwards~ Designing a language is hard, and adding more people doesn't really help.
<pie___>
dunno what one can do about the former other than offload to language design experts or become one :P
<gchristensen>
and there is some history of changes to the Nix language which would have seriously benefited from some RFC
<Taneb>
Each session they appointed a "tsar" whose job it was to stop discussion when it was clear it wasn't being productive due to bikeshedding
<simpson>
OTOH bringing in a couple folks from the laity, explaining the concepts, and then getting their non-binding opinions, has worked *very* well for some stuff I've done.
<pie___>
(sidenote: my experience with the FP community has been extremely positive and im like ????)
<Taneb>
simpson: I think : and :: were the right way round *at the time*, especially as type inference was a major selling point. The idea was, you'd never have to write a type signature, and lists are so useful!
<pie___>
Taneb, that sounds like it makes sense, especially if you have someone thats a decent moderator
<Taneb>
And then the culture gradually changed
<simpson>
Taneb: Oh, sure. I think that, to today's POV, it's hard not to see Haskell as a very rebellious misfit ML, and stuff like :: is part of what makes it seem so intentionally gawky.
<simpson>
More pointedly, if there were going to be a dialect of ML suitable for writing neutral portable algorithms in a foundational way, then Haskell is probably not it. It's nice that we have Haskell as a dialect for academic papers, though.
<pie___>
i forgot what eelco's irc nick is, but shouldnt he be in nix-lang? :P
<simpson>
"When the virtual machine has finished processing all the lines in the article file, the assumptions and theorems are the result of reading the article (the stack and dictionary are discarded). Successfully reading an article proves that the theorems Δ derive from the assumptions Γ in higher order logic, which we write as the theory Γ ⊳ Δ."
<pie___>
huh.
<pie___>
bukeshedding -> haskell -> proof system ffi xD
<pie___>
anyway back to work o/
drakonis has quit [Ping timeout: 264 seconds]
<Synthetica>
Open source etiquette question: is it commonly accepted to ask for a new release when there is a feature in master (but in no release) that you'd like to use?
<qyliss>
That's fine, unless there's clearly other things blocking a release that are in the process of being solved.
<gchristensen>
or a clearly defined release schedule
<Synthetica>
Thanks :)
<etu>
Synthetica: Just be polite and not demanding :)
<joepie91>
Synthetica: I usually post something along the lines of "Hi, are there any plans on when this will land in a release? I'm stuck on <X> so it'd be useful to have this available."
<joepie91>
so far I've always gotten positive responses to that
<joepie91>
and it doesn't imply that the maintainer is slacking, while still signalling that a release would be appreciated and why
<joepie91>
(also means that if there /is/ a blocker for release that you hadn't found out about yet, you'll probably be told about it)
<pie___>
qyliss, i guess this could be a "fixed" input, dunno how to do that thgouh
<qyliss>
I don't either
drakonis has quit [Ping timeout: 248 seconds]
<pie___>
i guess id use it as a buildinput to building the proper derivation with the generated lock file from this bootstrap phase
<pie___>
which i think does make some sense
<manveru>
pie___: why not vgo?
<manveru>
and your name keeps getting longer i think
<pie___>
manveru, dunno, i got recommended this and the readme says use the other ones if they use some other go things that i dont think were used for this repo
<adisbladis>
infinisil: Good reminder.. I should add a mention of `buildGoModule` to the vgo2nix readme
<adisbladis>
pie___: Anyway, I'd say go2nix is harder to use than creating a go.mod/go.sum and running vgo2nix. You could just `go mod init && vgo2nix`
__monty__ has joined #nixos-chat
pie___ has joined #nixos-chat
waleee has quit [Quit: WeeChat 2.4]
<eyJhb>
Do needs to get their shit together....
<eyJhb>
Digitalocean**
<__monty__>
Unstable servers or politics?
<eyJhb>
Unstable servers, the API is currently hitting the bricks
<cransom>
the imac i had, which was a 4 core.. i7 4970k? i think, it encoded h265 like it was a slide show. the cpu that i have currently does it realtime and faster and i think the 4970k was higher in clock speed
<simpson>
We aren't in the timeline where one can buy a GPCPU card full of hundreds of lightweight x86-like cores.
* gchristensen
eyes his stack of k80s
<infinisil>
cransom: Whoa, encoding h265 in realtime..
<cransom>
oh, i forgot my acronyms. it's hevc rather.
<samueldr>
well, there is that one gpu thing that never lifted off from intel which was a bajillion of atom like cores
<__monty__>
There's no difference between x265 and hevc, is there?
<gchristensen>
anyway, it is boring looking at replacing my home system where I run r13y and other experiments and seeing that the same money from 2011 getting the same thing, ~$90 for 16gb ram, ~$170 for a 3.4ghz-6core cpu, etc. the only difference being that I spent $70 on a 30GB SSD at the time and now that would be much larger.
<sphalerite>
samueldr: that sounds like Larrabee, which simpson linked
<samueldr>
oh, it is
<sphalerite>
gchristensen: it should still be much faster :)
<samueldr>
I was searching online for what I seem to recall being able to ssh in and using top
<cransom>
__monty__: i can't remember. isn't one a container and the other a codec? maybe not.
<sphalerite>
"High Efficiency Video Coding (HEVC), also known as H.265 and MPEG-H Part 2, is a video compression standard, designed as a successor to the widely used AVC (H.264 or MPEG-4 Part 10)."
<__monty__>
And x265 is an open source implementation, no?
<__monty__>
Thought it was Cod*ec* rather than Coding though.
<sphalerite>
I'd consider a codec a (full) implementation of a coding
<sphalerite>
like LAME is an encoder for the MP3 coding?
<sphalerite>
That's my gut-feel interpretation of the terminology
<sphalerite>
(since "codec" is COder and DECoder)
* simpson
wonders when "serde" will stop being Rust-specific and start having the same usage as "codec"
<sphalerite>
my guess is never, because it doesn't have a convenient and pleasant english pronunciation :p
<sphalerite>
s/convenient/obvious/
<gchristensen>
how do you say it? :)
<gchristensen>
I say it as in "absurd"
<sphalerite>
I've never got into a situation where I've had to say it :D
<simpson>
"sehr-dee", from "serialize/deserialize". Same idea as "codec".
<gchristensen>
I'm going to stick to absurd
<__monty__>
Definitely gonna steal that idea if I ever have to write a serialization library, abserde.
<gchristensen>
lol
<samueldr>
simpson: I've seen serde being used in (IIRC) PCIe or something hardwarey
<gchristensen>
nice
<infinisil>
"decco" would also be a fitting name
<__monty__>
Oh, that's another possibility "ArtDecco".
<infinisil>
Because all other channels are busy right now, I'll say it here
<infinisil>
Idea: Have multiple levels of staging
<infinisil>
Like, staging-1 staging-2 and staging-3
<infinisil>
The lower the level, the lower the rebuild count, the faster it gets merged back into master
<infinisil>
The higher the level, the higher the rebuild count, the less updates go to it
<infinisil>
Actually, it might make sense that all of them get merged into master in about the same intervals
<infinisil>
How about that!
drakonis has quit [Ping timeout: 248 seconds]
<sphalerite>
that does not sound fun
<infinisil>
sphalerite: Why not?
<sphalerite>
idk, we already have master for low rebuild counts?
<sphalerite>
and that would mean having to decide which staging branch to start from and which to target in a PR, and would be a pain
<sphalerite>
we already have staging and staging-next, the purpose of which is still unclear to me (do we have docs for that?)
boredom101 has joined #nixos-chat
<samueldr>
staging-next is the iteration that "next is going to master"
boredom101 has quit [Quit: Page closed]
<infinisil>
sphalerite: Currently we (or I at least) often have problems deciding whether a pr should go to staging or not
<infinisil>
When it has 500+ rebuild counts, mabye 1000-2000
<infinisil>
It's not an stdenv change which would be ~20000 rebuilds, but it's still a big number
<infinisil>
Having multiple levels of staging for this would make a lot of sense, and would also delay staging less in general
<qyliss>
Having four different possible targets though would make it even more difficult to decide where to put it
<infinisil>
qyliss: Ah I forgot to mention
<infinisil>
ofborg could automatically decide on the correct branch
<qyliss>
after making the PR?
<infinisil>
Heh yeah I guess that's a bit of a nuisance
<qyliss>
that's just going to increase the number of bogus review requests I get from rebases
<infinisil>
Maybe it could be part of nix-review
<qyliss>
(which is severely disruptive even at current levels)
<infinisil>
If the interval of staging being merged into master is decreased, maybe not as much anymore!
<infinisil>
I'm not a staging expert right now, but I think staging is a bit of a problem right now because it's so hard and slow to get back into master
<infinisil>
(that last sentence could have been interpreted to mean something a lot different wow)
<qyliss>
I guess we should really ask the people who actually do the staging -> master merges
<infinisil>
Yeah probably
<infinisil>
But I like this idea
<infinisil>
If the UX problems around it could be solved, it might just work pretty well
<qyliss>
If the current flow is causing significant pain to the staging mergers, we should change it
<qyliss>
If not, then we shouldn't
<qyliss>
I pretty much treat staging as a black box that I put things and then /at some point/ they'll be available in master
<qyliss>
So I don't think I'm qualified to have an opinion
<infinisil>
Yeah same..
<infinisil>
Maybe we could automate it
<infinisil>
Does hydra have an api?
<infinisil>
Would be pretty neat
drakonis has joined #nixos-chat
drakonis has quit [Ping timeout: 252 seconds]
pie__ has quit [Read error: Connection reset by peer]