<vika_nezrimaya>
Community builder is said not to be trusted, because one can inject stuff into /nix/store, blablabla
<etu>
eyJhb: Nah, I'm going trelleborg sassnitz
<vika_nezrimaya>
and I'm just a local Nix girl who won't even think about doing something evil like poisoning a binary cache or a server
<eyJhb>
etu: I love the encouraging words from David :p
<adisbladis>
You'd never!
<eyJhb>
vika_nezrimaya: well, I would say that as well :D
<etu>
eyJhb: :D
<eyJhb>
"ME? Botting! NO I would NEVER do that" :D
<adisbladis>
:D
<vika_nezrimaya>
Well, if you trust me, you won't even need community builder when I put my Project Glovebox (i'm officially calling my new binary cache project that, starting now - guess why!) in action :D
<eyJhb>
Because it will be on the road and constantly moving so it won't even be attacked!
<eyJhb>
s/even/ever/
<eyJhb>
etu: is there any rule in Sweden regarding keeping kangaroos as pets?
<etu>
Uhm, I don't know :D
<eyJhb>
Well... I must research then. Guessing it isn't a usual thought :p
__monty__ has joined #nixos-chat
<eyJhb>
joepie91: can you recommend any CSS lib for creating somewhat dynamic sites with menus etc. that does not require JS?
<eyJhb>
Trying to build my initial site with as little/no JS at all (if possible)
pie_ has quit [Ping timeout: 252 seconds]
<eyJhb>
`that you are building a website for a target group that has JavaScript disabled in higher numbers` the cons of making website for tech people and security folks
<vika_nezrimaya>
I have JS enabled, but I'm not a security person
<eyJhb>
Me too, but many have it disabled if they can
<eyJhb>
Also, disabled images loading etc..
<joepie91>
I have JS enabled, but very much appreciate a JS-less site
<joepie91>
eyJhb: are we talking dropdown menus?
<eyJhb>
Yeah, that too. I haven't quite figured our how the site should look yet etc. (as I am NOT good at designing things), but just if there was a go-to lib for it, like UIKit, BootStrap etc.
<joepie91>
eyJhb: drop-down menus are particularly erratic to handle in CSS without breaking accessibility or general usability
<joepie91>
eyJhb: I'd recommend designing your site to be usable without the dropdown menus (eg. having the dropdown items listed on the page that the button itself points at), and then just using JS for the dropdowns
<joepie91>
such that the user gets more convenient menus if they have JS, but can still navigate the site without
<joepie91>
(there are various hacks to make dropdown menus work in CSS, but they're a decent amount of work to fully understand, and by their nature you can't easily turn them into libraries, not in the least because CSS basically doesn't have a module system)
<eyJhb>
joepie91: yeah, that is basically my plan currently as well... Making it work with base functionality without JS, and then adding extra enhancements with JS
<samueldr>
... I'm falling in the habit of telling myself "don't look at github notifications, you're slacking, work instead"
<samueldr>
which is not partially untrue :/
<srhb>
samueldr: In the vein of the "standards" xkcd, I wish every site and thing out there had a similar API for fetching notifications so I could run it through my own whatever with scheduling etc.
<samueldr>
oh, that would be great
<gchristensen>
some sort of activity publication
<samueldr>
even some really simple syndication
<Gilfoyle->
gchristensen: Gee if only we had a spec for that...
<pie_>
joepie91: i really need to make my nix search engine...running across solutions to things clever told me about because google indexes the logs...
<samueldr>
this is from before I knew about nix lol
<gchristensen>
:o
<Taneb>
I'm curious to read it
<samueldr>
it's way too wippy, but the gist of it was: stop relying on opaque build artifacts and make the build of your whole thing observable
<samueldr>
at that point I had a completely workable toolchain thing that was used to build the dependencies, and project, for a cross-platform game engine
<samueldr>
definitely not as good as nix, but it went from rm -rf to full builds reliably
<pie_>
man sorting tabs is tiring
<samueldr>
now imagine if you had them expanded to spaces, there would be 2 to 8 times as many
<pie_>
i mostly disabled evaluation to avoid that
<pie_>
tabs are evaluated lazily you know, so its like schroedingers tab
<pie_>
it may or may not explode if you observe it
drakonis has quit [Quit: WeeChat 2.5]
drakonis has joined #nixos-chat
vyorkin has joined #nixos-chat
<__monty__>
Medium's gotten a paywall? o.O As if I needed another reason *not* to read medium.
vyorkin has quit [Remote host closed the connection]
<samueldr>
your links list at the top could be wrapped in a <nav>
<samueldr>
though, did you see that word?
<samueldr>
the third one
<samueldr>
your links _list_
<eyJhb>
I would say, in my defence, I normally don't use w3schools
<samueldr>
I generally *also* wrap them in ul, so `nav > ul > li > a`
<eyJhb>
Yeah, but doing that samueldr you would get a vertical menu, and if you think no CSS/JS
<eyJhb>
Or am I wrong?
<samueldr>
your alternative is (possibly) smushed links
<samueldr>
the list will be a better experience without CSS
<samueldr>
at least each element will be separated visually
<eyJhb>
My main challenge is currently, that everything will basically be a long list without CSS as far as I can see
<eyJhb>
Like.. Element 1, element 2, element 3, etc. all the way down
<samueldr>
that's the way it is
<eyJhb>
Yeah, I guess I would have to accept that...
<eyJhb>
But
<samueldr>
ime, it at least makes the CSS-less version of the site more usable to have navigation shown as list
<eyJhb>
.. Damn it.. But `nav > ul > li > a` is you recommandation?
<samueldr>
that's what I usually do
<eyJhb>
But would you recommend the same for category selection too?
<eyJhb>
MInus the nav
<samueldr>
depends, if it's _content_, multiple separate entries of content, no
<samueldr>
there's no hard rules
* samueldr
is currently working on his website
<eyJhb>
No no, of course not :) But I still like hearing what you think, and if it makes sense for me too, I might as well use it
<samueldr>
it's been left untouched since 2015, and it's a pain to update the toolchain because of how the static generator I used has decided to evolve :/
<eyJhb>
Well... It is basically filtration, so default is show "everything", and then it is show category X or Y or Z
<eyJhb>
samueldr++ for dark mode
<{^_^}>
samueldr's karma got increased to 106
<samueldr>
btw, I prefer using <button /> for all buttons (<button type="submit" />)
<samueldr>
eyJhb: I did that before it was cool
<samueldr>
and it's probably going away in the next iteration
<eyJhb>
samueldr: why button? - NOOO
<samueldr>
because it's a button?
<eyJhb>
I actually want this now, so bad. But, only CSS version
<samueldr>
well, it would be <button type="submit">Go do the thing</button>
<eyJhb>
... Defeated by such simple logic
<samueldr>
you can also add more elements than simple text
<samueldr>
if needed
<samueldr>
and it's easier to target via CSS
<samueldr>
button { /* rules */ }
<samueldr>
rather than input[type=submit], input[type=button] { /* rules */ }
<samueldr>
also almost allows you to do input { /* rules for text inputs */ }
<samueldr>
though it may (will) break radios and checkboxes
<joepie91>
also <button> allows you to include more than just plain text and <input type="button"> does not
<samueldr>
[17:01:31] <samueldr> you can also add more elements than simple text
<samueldr>
:D
<joepie91>
oh
<samueldr>
though your phrasing was better
<joepie91>
missed that
* joepie91
is only half paying attention, is busy moving code into standalone packages
<eyJhb>
samueldr: I feel like <nav> is missing text to specify it is a menu
<samueldr>
won't the code be all lonely that way?
<joepie91>
lol
<joepie91>
samueldr: isolated and dedicated to a purpose, just how I like it
<eyJhb>
I remember a group at uni that was at the exam. The lecture asked them "what does this code do?" and they ensured him it was VERY important. It ended up never being called or used.
<joepie91>
lol
* joepie91
is allergic to dead code
* eyJhb
knows how to kill joepie91 now
<Remosi>
joepie91, you can get anti-histermines for that now.
<joepie91>
:c
<eyJhb>
Damn. I am even missing a <html> tag.
<infinisil>
I wonder how much of nixpkgs is dead code..
<eyJhb>
I should.. Look more closely at what I am doing
<infinisil>
Where dead code = code that isn't used by anybody
<eyJhb>
Hmm.. Don't know if I should use the same style for categories now.. Properly shouldn't, as it really isn't navigation like that
<infinisil>
I can imagine nixpkgs having lots of this
<samueldr>
eyJhb: <html> is optional under circumstances
<asymmetric>
samueldr: yeah, it seems the version of the module in master doesn't allow for the whole traffic to be routed through the vpn
<samueldr>
sphalerite: ^
<asymmetric>
i'll look into the PRs, i hadn't seen the one by gchristensen
<alex_giusi_tiri>
what would your experience be of zeromq on nixos? i've noticed that it can't pass its self tests... my project is using zyre, but zpinger doesn't work...
<__monty__>
Man, people who complain about nix being slow have never tried using homebrew...
<eyJhb>
... Just realised that I cannot use sha1 as basic hash for cache (don't care about evil), as I might get files that actually uses hash collision....
<__monty__>
eyJhb: You mean as part of an assignment or something?
<__monty__>
How about X-> sha(X),md5(X), still cheap but a collision only occurs when both functions are compromised.
<__monty__>
I'm not sure that's more performant than just sha256 though.
<emily>
please use SHA-2 or blake2. there is no reason to use anything else
<emily>
if you really care about performance, blake2 is faster than MD5 while being cryptographically secure.
<Remosi>
what emily++ said
<{^_^}>
emily's karma got increased to 2
<joepie91>
emily++
<{^_^}>
emily's karma got increased to 3
<__monty__>
Sha256 is often implemented in hardware though. Is blake2 really faster on not-the-latest hardware?
<emily>
I'm not sure, but it's definitely going to be faster than SHA-256 when neither are implemented in hardware, which is the more relevant case
<emily>
see: AES vs curve25519 on contemporary TLS
<__monty__>
Is it?
<emily>
I'm pretty sure?
<emily>
it's faster than MD5.
<__monty__>
Don't all intel cpus have hardwar sha256?
<emily>
SHA-2 is slower than MD5.
<emily>
oh, you're questioning the relevant case.
<emily>
blake2 runs at 3 cycles per byte on modern intel CPUs
<emily>
looks like fancy SHA-2 is within a reasonable factor of that
<emily>
either way they're both probably not your bottleneck.
<__monty__>
That's the rub though. I suspect eyJhb is running this on either uni hardware, or personal hardware. Either way, not super recent hardware.
<emily>
I think it's unlikely that this graph looks substantially different on older x86, tbh
<emily>
and blake2's lead over SHA-2 is very substantial
<infinisil>
Btw, if security isn't important, there's a range of non-cryptographic hash functions much faster
<Remosi>
presumably at that speed you're probably going to run out of memory bandwidth first?
<emily>
this shows the exciting thing thing where SHA-512 is actually faster :)
<__monty__>
One issue I take with your "sha2/blake2 nothing else" canned answer is it stands in the way of learning through experimentation and making mistakes.
<emily>
you probably want to use SHA-512/256 rather than SHA-256 in practice if you care about performance
<emily>
__monty__: that's fair, but well, one issue I take with recommending sha1(x)||md5(x) is that it's all three of slow, insecure, and difficult to understand/implement
<emily>
I think if you want to understand how a hash function works learning about one good one is better than learning about two broken ones
<__monty__>
It's also super easy to implement, understand and then improve upon though.
<joepie91>
unless you're actually actively learning about cryptographic implementations, all of that is pretty much irrelevant though, and all you're doing is setting yourself up for failure :)
<joepie91>
"learning through experimentation and making mistakes" is not something you can afford where security is concerned
<joepie91>
at least not in production code
<__monty__>
But security isn't involved here.
<joepie91>
(where "production" == anything you make available for other people to use, directly or indirectly)
<__monty__>
I like infinisil's suggestion too. So many hash functions to learn about.
<pie_>
what do you learn from using a bad hash function
<__monty__>
Could imagine there's far better hashes for cache coherency than cryptographic ones.
<pie_>
for some value of bad
<pie_>
its not like it actually breaks
<__monty__>
pie_: The learning is from realizing that concatenating sha1 and md5 is a dumb thing to do.
<emily>
is your argument that it's good to recommend bad things because then you spontaneously learn it's dumb ;w;
<pie_>
besides the fact tha tmd5 looks sketchy to begin with, id deliberately have to find a paper or something explaining why that is bad
<emily>
it's also strictly harder to implement than one hash function, I find all your arguments really confusing.
<pie_>
im not intending to argue anytihng right now other than i dont see how to get from "its broken" to "learning from it being broken"
<__monty__>
And potentially learning that you can't simply rehash everything if you want to change hashes. So you end up with hash pyramids, like facebook.
<emily>
that was in reply to __monty__ not pie_
<infinisil>
__monty__: Seems like XXHash is one of the fastest, being limited by mostly IO
<infinisil>
Followed by Murmur hash and Fnv1a
<pie_>
emily: yes my reply being orthogonal was not clear
<emily>
using hashtable functions as a hash for something like the nix store would be a bad idea, btw
<emily>
like they're designed at best for ddos-resistance at relatively low key sizes, not long-term content-addressed-storage
<__monty__>
See? I haven't heard of *any* of those. Imo the non-crypto hash path is the more interesting one here.
<emily>
because non-crypto hash functions are generally an antipattern :)
<infinisil>
emily: Only for crypto-related things
<emily>
eh, I disagree. they're useful for some cases where performance is paramount but I'm unconvinced by e.g. siphash and the like as general-purpose hashtable functions etc.
<__monty__>
I was assuming eyJhb was talking about an ephemeral cache.
<emily>
since they tend to have both bad performance properties *and* not be cryptographically secure
vyorkin has quit [Ping timeout: 272 seconds]
<emily>
even using a non-cryptographic RNG often turns into a vulnerability you have to change
<emily>
*nethack* had this problem :p
<infinisil>
emily: What hash would you use for checksumming some data after transmission over a potentially unreliable network?
<infinisil>
Because that's an application where you don't have to care about security at all
<emily>
sha2 or blake2.
<emily>
like rsync.
<emily>
of course you have to care about security @.@
<emily>
you're trying to ensure data integrity over an unreliable (~ untrusted) network
<emily>
(ok, rsync actually uses fancy rolling window hash functions, but my point is: it uses a cryptographically secure hash)
<__monty__>
pie_: If you didn't know what I meant, facebook's user passwords are hashed in several layers because they didn't or didn't properly salt and then used an insecure hash, etc. And it's harder to remember all the old password hashing schemes, in case users don't log in for a long time, since you can't just recalculate with a new hash function because you don't know their password. So they just apply
<__monty__>
the new hash to all of the stored hashes. Now every time someone logs in they have to do sha256(md5(md5(password)+salt) (made up but it's something like this).
<infinisil>
emily: Well I didn't say untrusted
<emily>
for one, how do you check whether you downloaded the right sha-1 collision?
<emily>
those files actually exist in the wild and you have to deal with them
<__monty__>
It uses a crypto hash? I'd expect better options to exist, with error recovery.
<infinisil>
Maybe my example wasn't great though
<emily>
IMO you thinking that it's a good idea to use a non-cryptographic hash for a general-purpose file transmission over a network is exactly the instance of this kind of bad thinking/architectural pattern... same reason we have a bunch of insecure HTTP being globally passively monitored
<emily>
my point is basically that it's really hard to come up with airtight examples where you know for sure there is never any security-relevant context
<emily>
and the cost of using cryptographic hash functions is extremely low these days
<emily>
so unless you're a standard library maintainer tweaking your hashtable or whatever, it's rare that there's any reason to consider a different one
<infinisil>
I'm just trying to say, non-cryptographic hashes also have their uses
<__monty__>
emily: There's things that crypto hashes just can't do though. Thinking of blockhash-like things.
<__monty__>
And designing a small cache to speed up a webpage sounds a lot like designing a hastable tbh.
<joepie91>
infinisil: they do, just not anywhere near as many as people think :D
<infinisil>
Yeah probably, I can't think of anything other than a hash table at the moment
<infinisil>
Ohh, a bloom filter is a good application right?
<infinisil>
Yeah
<infinisil>
emily: ^
<infinisil>
Just talked about bloom filters in #nixos a couple days ago for potentially making nix faster :)
<__monty__>
Surely there's plenty of applications where collisions don't matter?
<__monty__>
I'll find out how naive a view that is tomorrow.
<__monty__>
nn, peoples
__monty__ has quit [Quit: leaving]
<joepie91>
infinisil: only some bloom filters!
<joepie91>
infinisil: for example, you probably wouldn't want to use a non-cryptographic hash for safe browsing
<joepie91>
(which uses a bloom filter)
<joepie91>
as that would allow an adversary to intentionally create a collision with a target site
<joepie91>
and get that site erroneously blocked
<infinisil>
I mean, bloom filters will have false positives, so collisions should ultimately just make that probability of false positives higher, right?
<joepie91>
infinisil: the problem isn't collisions, the problem is *craftable* collisions
<joepie91>
bloom filters will inherently have a risk of collisions, that's by design, and that isn't an issue so long as the collisions are effectively random and low in number
<joepie91>
it becomes a problem when you can intentionally collide with any entry, with 100% certainty, for applications such as safe browsing
<joepie91>
because now I can effectively take down your site by setting up a shitty phishing site at a hostname that I know is going to collide with your site
<joepie91>
and waiting for google to block it
<joepie91>
the phishing site doesn't even have to log anything, it just needs to exist and get Google to block it
<infinisil>
joepie91: Huh, there isn't a mechanism to handle false positives?
<infinisil>
I'd imagine it would first check the bloom filter to see if it's certainly not a bad site, and do a secondary check if the first didn't succeed
<joepie91>
infinisil: I don't know if this may have been changed, but at least originally it was /just/ a bloom filter
<joepie91>
(and this has actually caused one real-world collision I believe)
<joepie91>
(or at least one, anyway)
<infinisil>
I think that's what bloom filters are supposed to be used for, give a fast early-exit with high probabilyt
<joepie91>
point being, if you use a non-cryptographic hash for that and rely on the answer, you have a problem :)