<gchristensen>
(also, packet doesn't give me anything and I don't work there. they do contribute quite generously to nixos, though)
<drakonis>
this is p. weird.
<drakonis>
oh, do they?
<gchristensen>
oh. hi, sonic, I guess
<gchristensen>
they do, packet has donated many servers
<drakonis>
that product placement though
<gchristensen>
hrm?
<drakonis>
look at the shoes
<gchristensen>
omg
<gchristensen>
c'mon
<drakonis>
why put nikes maaaaaan
<gchristensen>
clearly sonic should be wearing Adidas
<drakonis>
blehhhh
<drakonis>
why not some shoes that roughly resemble what he wears on the games
<gchristensen>
(that was a joke)
<jasongrossman>
I've known a few hedgehogs, and none of them wore shoes.
<jackdk>
after actually doing something right with Sonic Mania (well, nearly: there was the whole denuvo thing) the had to go and do something insane
<infinisil>
It's not that important but
<infinisil>
The code quality in nixpkgs is really bad in general!
<infinisil>
In my opinion at least. I guess it's not surprising considering the size of it, the fact that there's no good nix linters/formatters or type checking, or code warnings from nix in general
<ottidmes>
infinisil: any parts of nixpkgs in particular? I guess it would have to be the modules, since most of those kind of issues would show themselves during a package build
<infinisil>
ottidmes: I really just mean the code quality, things like
<infinisil>
Wrong formatting, little documentation (on the code itself), too many parens, super deep nesting, too big files
<infinisil>
I have many other gripes with nixos modules though :P
<infinisil>
Inconsistent formatting too
<ottidmes>
well most those things are really subjective, so without any style guide enforcement and so many people, its a given you will see many different styles and preferences pop up
<ottidmes>
inconsistent formatting and naming also stems from that, if multiple people edit the same file, you get a mixture. Personally I try to match with the style of the file I am editing, but not everybody does
<infinisil>
Also, some parts of nixpkgs are really complex, and nobody can touch them without a fear of breaking something. Like the module system, certain nixos modules, the lots of override ways, the pkgs fixed point thing
<infinisil>
ottidmes: Yeah, I guess I'd really like a good formatter and linter everybody needs to run along with a bunch of coding guidelines
<ottidmes>
thats not to say I would love to see some enforced style guide for nixpkgs, maybe with some formatting tool
<ottidmes>
:)
<gchristensen>
this is something I'd like to see, but not likely something we could do in one big go
<infinisil>
Imagine if we had a code formatter, and we actually could have it run on *all* of nixpkgs!
<infinisil>
That would be dope!
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
<ottidmes>
but it would be a nice start if this could slowly be introduced, so that eventually all new code adhers to it, then when the tooling matures to handle all of nixpkgs, it could probably be applied in phases to the whole of nixpkgs
<gchristensen>
yeah, that'd be a great way to do it -- ensure new lines adhere
<gchristensen>
having a formatter has been a long term wish of mine
<ottidmes>
I was wondering about that the other day, is there not some existing library/software/whatever that we could leverage to define formatting rules easily. Something like rnix could probably be used to generate a format that such a tool would need to work on
<ottidmes>
I know of one, but its commercial I believe
<gchristensen>
after that 80% of the work is done, the other 80% is getting it accepted
<infinisil>
The accepted part will be the hardest..
<gchristensen>
not if everyone just agrees with me
<ottidmes>
yep, since its such a bike shed subject, everybody will have an opinion
<jackdk>
I hate the style of many formatters, but I hate not having a formatter more
<gchristensen>
exactly
<infinisil>
My prediction: Somebody makes a great formatter, it works perfectly, opens a PR to start enforcing it, some people don't like it, stalls for 2 years, now the formatter is bitrotten because nobody has been using it
<gchristensen>
that is a risk
<ottidmes>
Graham as Benovalent Nix formatter dictator for Life!
<gchristensen>
opening a PR introducing it is the last step of a political process, which if skipped causes it to fail
<infinisil>
We could probably avoid a lot of bikeshedding if the formatter was integrated into Nix itself, becoming part of nix's codebase
<gchristensen>
no, that just moves the bikeshedding :P
<infinisil>
But that would mean writing C++, and nobody likes that!
<ottidmes>
aye
<jackdk>
ottidmes I wouldn't trust any human with that power. ofborg for BDFL!
<gchristensen>
+1
<gchristensen>
ofborg is less lazy :P
yl has joined #nixos-chat
<ottidmes>
would be nice if the formatter would allow you to define the formatter rules via Nix code, that would make it easier to contribute to than if it were completely written in C++/Rust/Haskell
<jackdk>
doesn't everyone in the nix community know haskell though? ;-)
* gchristensen
doesn't
<infinisil>
What's this principle called where you expose very little functionality initially, because you can always add more, but you can never take away without annoying people
<infinisil>
I feel like this should have a name
<ottidmes>
infinisil: first thing that comes to mind is backwards compatibility, but you probably want something more specific
<jackdk>
the classic story of this type is the one about `make(1)`
<infinisil>
ottidmes: i got told about SOLID in another channel, whose O stands for 05:00 infinisil: Arahael: Ah, I guess it might be a bit of https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle , which sounds like that might be it
<infinisil>
(Ah i pasted too much, only wanted the link)
<jackdk>
where Feldman wrote "\n\t" into make's lexer, and by the time he realised it was a terrible idea had "too many" (like 12) users to go and fix it
<ottidmes>
infinisil: maybe ask about it in #proglangdesign
<sphalerite>
infinisil: there's also "minimum viable product"
pie___ has joined #nixos-chat
pie__ has quit [Ping timeout: 245 seconds]
* Arahael
peers at infinisil.
<infinisil>
Arahael: hehe hello there
yl has quit [Ping timeout: 252 seconds]
endformationage has quit [Quit: WeeChat 2.3]
<sphalerite>
"I work from home and at odd hours, so Acronis would sometimes start a scheduled full backup while I was still on the computer. Vista is supposed to support backing up files even if they are in use, but I still don't feel confortable working while a backup is in progress."
<sphalerite>
Anyway, reason I ended up reading this is that I have some hard drives I want to read the SMART data for and I don't know if an eSATA adapter will allow me to do so. Anybody know things about this?
jackdk has quit [Ping timeout: 240 seconds]
ottidmes has quit [Ping timeout: 245 seconds]
jasongrossman has joined #nixos-chat
__monty__ has joined #nixos-chat
johanot has joined #nixos-chat
jtojnar has joined #nixos-chat
jtojnar has quit [Remote host closed the connection]
drakonis has quit [Quit: WeeChat 2.3]
<disasm>
sphalerite: I think it will. old ata drives had smart data too
jasongrossman has quit [Ping timeout: 255 seconds]
jasongrossman has joined #nixos-chat
ivan has quit [Quit: lp0 on fire]
ivan has joined #nixos-chat
jasongrossman has quit [Ping timeout: 246 seconds]
<gchristensen>
infinisil: the parable of sex?
jasongrossman has joined #nixos-chat
<infinisil>
Haha whaa
drakonis1 has quit [Ping timeout: 245 seconds]
<gchristensen>
make a mistake and you're supporting the feature forever
drakonis1 has joined #nixos-chat
<joepie91>
lol
ottidmes has joined #nixos-chat
Synthetica has joined #nixos-chat
jasongrossman has quit [Ping timeout: 255 seconds]
endformationage has joined #nixos-chat
jtojnar has joined #nixos-chat
jasongrossman has joined #nixos-chat
jasongrossman has quit [Remote host closed the connection]
kini has quit [Quit: No Ping reply in 210 seconds.]
jasongrossman has joined #nixos-chat
kini has joined #nixos-chat
jtojnar has quit [Read error: Connection reset by peer]
<gchristensen>
do I owe anybody an IRC cloak?
ottidmes has quit [Quit: WeeChat 2.2]
<andi->
which ones do you offer? :D
<gchristensen>
right now just NixOS/user/andi-
<andi->
i'd take that
<gchristensen>
ok
<gchristensen>
there was brief chat about NixOS/developer/... and other stuff, but "where's the line?" is pretty tough to draw
<andi->
yeah, that is always a difficult line to draw and might cause unwanted/unneeded discussions/hate/…
<gchristensen>
exactly
<gchristensen>
and pretty easy to accidentally become a nixos dev just by being a user
<andi->
aren't we all uses anyway? :D
<andi->
*users
<gchristensen>
:)
<andi->
If there is someone working/contributing to NixOS without actually ever using it I'd like to know :D
<srhb>
andi-: If you consider package maintainers, I think there's actually, and surprisingly, at least a few :)
<andi->
I am more surprised by the amount of "central" packages that lack maintainers... most recently I cam across cryptsetup that only got bumps due to ryantm's automation..
<gchristensen>
that is definitely a thing
<andi->
not just that there is no maintainer in the meta attrset but that nobody ever looked at it in a long time :/
<gchristensen>
historically (as you know) maintainership didn't really mean very much commitment or involvement
<andi->
yeah
<gchristensen>
hopefully we can lightly bend that towards more commitment and involvement on packages, and then work on getting core packages more maintained as a result
<srhb>
I think an orphan package roundup might be interesting though. I'd certainly be willing to take over a few.
<srhb>
I'm sure other people feel the same way, that they'd be at least happy to look over a package once ryantm's bot pings them :-P
<andi->
srhb: couchdb1 is looking for some love (or removal)
<gchristensen>
we need tooling to support people in that effort -- debian (as you know) has quite a lot of tooling in that area
<srhb>
Indeed.
<srhb>
andi-: Thanks :)
<andi->
I would like to see more courage regarding marking things for removal in ~months time on unstable...
<gchristensen>
we can definitely do that
<andi->
due to our ability to keep old things working with a special version of a dependency etcpp more often then we should there is some software nobody cares about (at least it looks that way)
<gchristensen>
we can do that with and without policy
<gchristensen>
policy makes it easier and harder :P
<andi->
I'd just start with some packges that haven't been touched in ~years.. should be an easy discussion on those. Ofc some packages might just work fine even after 10y.
<gchristensen>
+1
<gchristensen>
nixpkgs isn't a dumping ground, every package brings value and cost
<andi->
I must figure out how I can query hydra for packages that have been failing for a very long time.
<srhb>
andi-: Previous succesful is probably the way to go
<srhb>
It'll probably only work for trunk though
<andi->
srhb: for all the packages :D
<srhb>
oh, ow..
<srhb>
That's easier with db access tbh
<srhb>
The scheme is really simple, so writing up a small script that could run occasionally would probably(?) be accepted.
<andi->
I have been trying to revive the openssl1.1 migration and looking at the packages that fail there currently makes me wanna remove most of them..
<srhb>
andi-: openssl1.1 roundup issue in the style of ZHF? :-)
<gchristensen>
andi-: I can send you a DB dump if you'd like
<srhb>
I like those kinds of issues, they really invite people to work together.
<andi->
srhb: soon, I am still basically re-fixing / updating all the changes that were alreayd done.. Will have to write a new/updated patch for qt5.9 tonight.
<srhb>
andi-: Cool :)
<andi->
gchristensen: sure, but probably not now.. Trying to reduce the parallel projects
<gchristensen>
andi-: yepppppppp I hear that
<andi->
and if you do it: please remove the user infos ;-)
<gchristensen>
already done
<gchristensen>
(I already have the dump)
<aanderse>
on topic of maintainers... is it assumed that a module maintainer is the package maintainer?
<srhb>
aanderse: Nope.
<aanderse>
i've seen cases where the package and module are written by different people...
<aanderse>
yeah....
<aanderse>
is there a thought to add a maintainer to a module?
<srhb>
aanderse: We already have the ability
<andi->
some alreayd do that
<srhb>
It's just not well-known
<aanderse>
:-O oops
<andi->
On the topic of modules: Would really like to have tests for ecah of the modules/higher level combinations... It is also a ZHF-checklist style thing that I have though about.
<aanderse>
yeah, almost every module should have a test
<srhb>
andi-: I agree, at least because it eases checking feature parity when making changes.
<gchristensen>
I have two computers running qemu the exact same way, on very similar hardware, on the exact same nixos revision... and yet one qemu vm receives terrible audio, and the other qemu vm receives great audio
<gchristensen>
computers are a horrible mystery
<andi->
gchristensen: did you try killing the difference in the hardware? :D
<gchristensen>
hehe, not sure that is really possible
<infinisil>
__monty__: It's not as simple as AIMD, but not too complicated either
<__monty__>
Sounds like ML for congestion control.
<__monty__>
Can't watch the video, I'm on 1Mbps internet :'(
evhan has joined #nixos-chat
<manveru>
are all those slides in Comic Sans?
<infinisil>
__monty__: The gist of it is: Compare two sending rates by trying them out. Feed the results into a utility function so you can compare which one did better. Then move towards that rate
<__monty__>
How fast do you move towards the end you choose?
<__monty__>
Also, at what level does PCC have to be implemented? Please tell me it's not application level.
<manveru>
"PCC’s control action is its choice of sending rate. PCC divides time into continuous time periods, called monitor intervals (MIs), whose length is normally one to two RTTs."
<manveru>
seems like it's pretty configurable though, depending on what you want
<infinisil>
__monty__: If current rate is at r, they test r(1-e) and r(1+e), and choose the better of those rates (if conclusive), e starts out with e_min, which they chose to be 0.01, e gets increased by e_min every time a new rate is chosen, maxed at e_max which they chose as 0.05
<infinisil>
There's also some way to decrease e probably
<__monty__>
So it's several levels of linear?
<infinisil>
And it seems even a bit more complicated than that
<infinisil>
__monty__: Not sure, maybe?
<__monty__>
How hard has this been put to the test? Tbh it doesn't sound very convincing. Does it really improve throughput? For the network or the sender?
<infinisil>
Intuitively the reason this is better than TCP is because this algorithm doesn't just say "A packet dropped, I must be at fault, sorry!" (which TCP does), but instead tries out two different rates, which allows it to infer some things about what causes dropped packets
<infinisil>
__monty__: It certainly improves fairness and decreases bandwidth variance by a lot. Figure 11 in the paper shows that nicely
<__monty__>
I just wonder whether the average of low and high rates is really close to the middle. If the middle rate would work then the lower rate works, but the higher rate might not. So the expected rate is somewhere between the lower and the middle rate.
<__monty__>
I don't trust figures in papers. They're always too rosy.
<infinisil>
Haha
<__monty__>
What would be interesting is having all the student's implementations in a massive simulated network and then analyze.
<infinisil>
Well you'll have to read the paper to know more about it, I only know the couple things he explained in todays lecture
<infinisil>
__monty__: We do have a leaderbord on this project we need to do
<infinisil>
Not a huge testnet though
<infinisil>
The professor also said there's a bunch more papers on better congestion algorithms btw