<ekleog>
andi-: fwiw, in the context of JS engines, IIRC usually speculative is meant as an optimization: optimizing by assuming that the type of a variable is known and adding type checks to verify it… theoretically sound, in practice it's the most sensitive part of JS engines
<ekleog>
no actual tie with speculative execution attacks
matthewbauer has joined #nixos-chat
Sonarpulse has joined #nixos-chat
<gchristensen>
_sigh_ when nixos' guarantees are so nice it makes it hard to decide to go against them
lassulus_ has joined #nixos-chat
lassulus has quit [Ping timeout: 260 seconds]
lassulus_ is now known as lassulus
sphalerite has quit [*.net *.split]
colemickens has quit [*.net *.split]
joepie91 has quit [*.net *.split]
pasukon has quit [*.net *.split]
mkaito has quit [*.net *.split]
jackdk has quit [*.net *.split]
adisbladis has quit [*.net *.split]
julm has quit [*.net *.split]
srk has quit [*.net *.split]
ekleog has quit [*.net *.split]
Myrl-saki has quit [*.net *.split]
aszlig has quit [*.net *.split]
jcrben has quit [*.net *.split]
mudri has quit [*.net *.split]
emily has quit [*.net *.split]
Sonarpulse has quit [*.net *.split]
nckx has quit [*.net *.split]
lopsided98 has quit [*.net *.split]
infinisil has quit [*.net *.split]
steveeJ has quit [*.net *.split]
NinjaTrappeur has quit [*.net *.split]
vdemeester has quit [*.net *.split]
benkolera has quit [*.net *.split]
nh2 has quit [*.net *.split]
mog has quit [*.net *.split]
ctp has quit [*.net *.split]
gchristensen has quit [*.net *.split]
philipp[m] has quit [*.net *.split]
pie_ has quit [*.net *.split]
Jackneill has quit [*.net *.split]
clever has quit [*.net *.split]
tilpner has quit [*.net *.split]
harrow` has quit [*.net *.split]
rain2 has quit [*.net *.split]
simpson has quit [*.net *.split]
wirew0rm has quit [*.net *.split]
manveru has quit [*.net *.split]
zimbatm has quit [*.net *.split]
elvishjerricco has quit [*.net *.split]
qyliss^work has quit [*.net *.split]
tazjin has quit [*.net *.split]
andi- has quit [*.net *.split]
lassulus has quit [*.net *.split]
hl has quit [*.net *.split]
dmc has quit [*.net *.split]
matthewbauer has quit [*.net *.split]
Peetz0r has quit [*.net *.split]
srhb has quit [*.net *.split]
ericnoan has quit [*.net *.split]
Ralith has quit [*.net *.split]
sphalerit has quit [*.net *.split]
kalbasit[m] has quit [*.net *.split]
yurb has quit [*.net *.split]
maurer has quit [*.net *.split]
Synthetica has quit [*.net *.split]
kahiru has quit [*.net *.split]
samueldr has quit [*.net *.split]
ma27 has quit [*.net *.split]
disasm has quit [*.net *.split]
nbp has quit [*.net *.split]
snajpa has quit [*.net *.split]
obadz has quit [*.net *.split]
kini has quit [*.net *.split]
ivan has quit [*.net *.split]
Ericson2314 has quit [*.net *.split]
edef has quit [*.net *.split]
snajpa has joined #nixos-chat
sphalerite has joined #nixos-chat
colemickens has joined #nixos-chat
joepie91 has joined #nixos-chat
pasukon has joined #nixos-chat
mkaito has joined #nixos-chat
kini has joined #nixos-chat
ivan has joined #nixos-chat
obadz has joined #nixos-chat
dmc has joined #nixos-chat
mog has joined #nixos-chat
gchristensen has joined #nixos-chat
ctp has joined #nixos-chat
philipp[m] has joined #nixos-chat
matthewbauer has joined #nixos-chat
Peetz0r has joined #nixos-chat
srhb has joined #nixos-chat
ericnoan has joined #nixos-chat
tilpner has joined #nixos-chat
pie_ has joined #nixos-chat
Jackneill has joined #nixos-chat
clever has joined #nixos-chat
harrow` has joined #nixos-chat
Ericson2314 has joined #nixos-chat
edef has joined #nixos-chat
zimbatm has joined #nixos-chat
qyliss^work has joined #nixos-chat
wirew0rm has joined #nixos-chat
simpson has joined #nixos-chat
rain2 has joined #nixos-chat
manveru has joined #nixos-chat
tazjin has joined #nixos-chat
elvishjerricco has joined #nixos-chat
andi- has joined #nixos-chat
Myrl-saki has joined #nixos-chat
julm has joined #nixos-chat
srk has joined #nixos-chat
aszlig has joined #nixos-chat
adisbladis has joined #nixos-chat
jcrben has joined #nixos-chat
jackdk has joined #nixos-chat
ekleog has joined #nixos-chat
emily has joined #nixos-chat
mudri has joined #nixos-chat
samueldr has joined #nixos-chat
kahiru has joined #nixos-chat
Synthetica has joined #nixos-chat
Ralith has joined #nixos-chat
kalbasit[m] has joined #nixos-chat
sphalerit has joined #nixos-chat
yurb has joined #nixos-chat
maurer has joined #nixos-chat
lassulus has joined #nixos-chat
hl has joined #nixos-chat
ma27 has joined #nixos-chat
disasm has joined #nixos-chat
nbp has joined #nixos-chat
ma27 has quit [Read error: Connection reset by peer]
<samueldr>
hmmm, it might be ONLY ME in the whole world
<samueldr>
but if your target disk mode ipod plugged via firewire doesn't show as a disk, sudo modprobe firewire-sbp2
<samueldr>
hi me from the future, reading this log!
Sonarpulse has joined #nixos-chat
lopsided98 has joined #nixos-chat
pie_ has quit [Ping timeout: 260 seconds]
<gchristensen>
nice
<samueldr>
last time I used it on that same computer with nixos (different kernel that's for sure) I didn't need to :/
<emily>
gosh, firewire in 2018
<samueldr>
I have simple, but specific needs
<gchristensen>
firey wires apparently
<samueldr>
music player with storage, with good software
benkolera has joined #nixos-chat
<samueldr>
4th gen ipod, with a click wheel, with the hard drive replaced with flash storage for moar space
matthewbauer has quit [Ping timeout: 264 seconds]
<gchristensen>
nice
<gchristensen>
there is a way to query if a path is live right?
<ekleog>
nix-store --gc --print-dead ?
<ekleog>
(beware, --print-live appears to actually trigger a gc collection here)
<clever>
gchristensen: nix-store --query --roots is what i use
colemickens has quit [Write error: Connection reset by peer]
colemickens has joined #nixos-chat
lopsided98 has quit [Remote host closed the connection]
mkaito has joined #nixos-chat
joepie91 has quit [Ping timeout: 252 seconds]
lopsided98 has joined #nixos-chat
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-chat
jasongrossman has joined #nixos-chat
pie_ has joined #nixos-chat
<andi->
ekleog: i know that. I was just trying to make a funny side note :)
<ekleog>
oh ^^
<andi->
ekleog: on a more serious note I wonder how "secure" speculative execution in software is. If they have similar major issues like the CPUs. E.g. taking a shortcut when verifying preconditions :S
<ekleog>
yeah, that's the source of the CVEs people find in JS engines usually: a type that was supposed to be checked but actually wasn't
<ekleog>
and so you get type confusion and the js engine calls a method on your “object” that's actually an optimized-int that points to where you want in memory and the js engine happily jumps to there
<ekleog>
well, at least the good thing is that when preconditions are checked they're at least checked before the code that's executed, not after (or at least I haven't seen a case of checks after the code, maybe that exists)
jasongrossman has quit [Remote host closed the connection]
<andi->
ekleog: I was thinking (without domain knowledge on JITs) that you would write the code so that you can execute it towards some "dummy" (null, CoW, ...) context if you did speculative execution and the entire execution would take the same paths as "normal" execution just in an isolated context... I guess it isn't that easy in reality? :)
<ekleog>
hmm indeed, as sometimes you're calling function pointers that are stored in the received data :)
<andi->
that sounds like a terrible design to me :D
<ekleog>
the way it more or less works is, basically, the non-optimized code runs, observes the types that are passed as arguments, and then once a function has been called enough times with the same types it's going to be optimized
<andi->
thats just the JIT part, I've done that briefly >10y ago during my studies.. wasn't great but I think I got the concept right. I am more concerned about the speculative thingy
<ekleog>
for optimization, the JIT will basically add a check that the type is actually what's expected, if it matches it'll run the optimized version, and if it's not it'll run the non-optimized version
<ekleog>
and the optimized version then makes assumption that the type is actually the same type as before
<ekleog>
this works… except when the check is forgotten on $RANDOM opcode
<ekleog>
and then you're in for a world of trouble :D
<infinisil>
Heh, just realized I had a smiley in my Haskell code:
<infinisil>
" modify (new { path = importDestination } :)"
<srhb>
infinisil: Too bad a concat section isn't a sad smiley. :P
jasongrossman has joined #nixos-chat
__monty__ has joined #nixos-chat
{^_^} has joined #nixos-chat
<etu>
{^_^}++
<{^_^}>
{^_^}'s karma got increased to 138
ma27 has joined #nixos-chat
Synthetica has quit [Quit: Connection closed for inactivity]
<elvishjerricco>
Maybe it saved the acceptance in there?
<etu>
Doesn't seem like it
<etu>
Mostly projectile, company and backup-files in there
<etu>
elvishjerricco: Just to be sure I flipped those vars to new directories and started emacs, opened nixpkgs with dir-locals in it and nothing weird
<elvishjerricco>
etu: Huh. That really doesn't make any sense to me.
<etu>
To me it seems like my emacs ignores that file, no idea why if yours doesn't :D
ekleog has quit [Remote host closed the connection]
ekleog has joined #nixos-chat
Peetz0r has quit [Ping timeout: 264 seconds]
Peetz0r has joined #nixos-chat
jtojnar has joined #nixos-chat
<elvishjerricco>
So here's an idea: A nix-build-like tool that uses local working dirs and a separate output store. This would let you build arbitrary derivations incrementally, even across derivations. It would be impure, so much more likely to fail, but that's something users would just have to accept.
<elvishjerricco>
To clarify, things would be incremental because you'd leave the dirty working tree and dirty output store.
<gchristensen>
have you seen the recursive nix patch?
<elvishjerricco>
gchristensen: Nope
<elvishjerricco>
But if it's anything like what I think it is, I think that's a very different problem / solution
<gchristensen>
oh?
<gchristensen>
it allows incremental builds and isn't impure
<elvishjerricco>
gchristensen: "Allows" is a strong word. You have to create a compiler wrapper. And I think cc-wrapper has show just how complex a project that can be. I'm not generally a fan of the idea. Plus, the overhead of merely invoking Nix is often as large as the full running time of compiling a file with the original compiler.
<elvishjerricco>
I see recursive nix as more useful for replacing IFD things like callCabal2nix
<gchristensen>
also true
<gchristensen>
btw, what is the story of your nickname?
<elvishjerricco>
Heh
<elvishjerricco>
I was 10 years old (23 now), and needed an XBox live username. I typed in "Jerry" in my infinite creativity, and XBox actually suggested this username
<gchristensen>
haha, cool
<elvishjerricco>
So I used it online for a couple things, originally to remain anonymous, and then found that I made some important things under this name, so it stuck :P
<gchristensen>
:)
<gchristensen>
I've used nicknames based on my real name for a very long time.
<elvishjerricco>
I know the guy who managed to claim his name, Luigy, on pretty much everything. I'd consider that fairly lucky :P
<gchristensen>
wow
<gchristensen>
yes, I have tiers of preferred nicknames :(
<elvishjerricco>
It's usually not hard to claim "elvishjerricco" :P
* emily
thinks her possession of this nick says more about freenode's gender ratio than anything else :p
<gchristensen>
:D
<gchristensen>
unfortunately
<simpson>
emily: There's lots of ladies (including like three other Emilies) who would rather be androgynous or male online. Culture~
<infinisil>
After weeks of thought about my nickname I eventually chose this one
<infinisil>
Only to realize later that it's kinda annoying to pronounce it, but it was too late
<infinisil>
I never have to fight for this nick at least :)
pie_ has quit [Ping timeout: 268 seconds]
<gchristensen>
is there a reason to not use zfs as the root fs, then a zvol with luks and ext4 on top?
<emily>
infinisil: hm, how is it hard to pronounce?
<infinisil>
The many i's and the 'sil' and the end feels weird
<infinisil>
My native tongue is (swiss-)german, which probably adds to it
<samueldr>
I had notes I wanted to try on Mojave once it was released to maybe streamline the initial setup to "only partition + terminal command"
<samueldr>
(from the failed experiment to automate it all)
<gchristensen>
eh, I see the advantage of that but for something I'd do presumably once a year or so I don't care :P
<gchristensen>
it isn't like it will produce a binary-reproducible result anyway
<samueldr>
though from all the news that apple is gowing against the grain for provisionning, I'm sure that if it's not all broken for Mojave, it won't be long it will :/
<gchristensen>
also that
<gchristensen>
ah, passing bs=4096 significantly increased the speed of the `dd`
<andi->
the `bs` argument of `dd` is always a great mistery abot selecting the "correct" value.. some say 1k, 4k, 1M, 5M, …. I guess you should use whatever block alignment your media has but who knows that at all times?
<samueldr>
though that's not `dd`'s `bs`, but `qemu-img dd`'s :)
<LnL>
either way you definitively want to pass it _something_
<LnL>
otherwise it's crazy slow
<samueldr>
from `man dd` it defaults to 512
<samueldr>
but that's *our* dd at its current version
<samueldr>
I wouldn't be surprised others don't
<LnL>
oh, didn
<LnL>
't even notice that
<samueldr>
`bs` is at the receiving end of a lot of cargo-culting; and partly deserved :/
<clever>
i strongly suspect the disk controller is lying, but i have yet to find any device that claims something other then 512
* samueldr
wonders if hardware lies somehow
<clever>
samueldr: early on, it was very common for OS's to malfunction when the sector size wasnt 512, so the drives just lied
<samueldr>
I have *one* device showing 4096
<clever>
and related, is partition alignment
<clever>
Device Start End Sectors Size Type
<clever>
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
<ivan>
doesn't linux do writes in 4KB-sized chunks
<clever>
the above partition, starts exactly at the 1mb border (1024*1024 bytes)
<clever>
so as long as the block size is a power of 2 and less then 1mb, the partition is aligned
<gchristensen>
is `blockdev --getsz /dev/sda` what I want to pass to bs?
<ivan>
you might get even faster dd with bs > 4096, try something around 64KB-256KB
* andi-
ponders about nixos/nixos-homepage.. many open improvements without a clear NO or YES. andi- feels like it is a waste to highlight eelco about them..
<clever>
but, if i had started the partition at 2049, and the drive was using 1mb blocks
<clever>
and if my FS was also using 1mb blocks
<gchristensen>
andi-: links?
<clever>
every single read would involve 2 disk blocks
<clever>
and every write would involve reading 2 blocks, modifying in-ram, then writing 2 blocks back out
<gchristensen>
blockdev tells me 977105060
<LnL>
gchristensen: well, it's best to set the ashift of the zpool with depending on that
<{^_^}>
nixos-homepage#241 (by andir, 3 weeks ago, open): Make it more obvious that nixos options in the search results are clickable
<samueldr>
searching for that number gives me a bunch of results about "LBA"
<samueldr>
which I'm not sure what it is
<samueldr>
andi-: :/ I need to figure out a good time management process
<clever>
samueldr: the manpage claims that --getsz returns the oh wait no
<samueldr>
I have this chrome window with 3 nixos-homepage PRs to review
<clever>
--getsz
<clever>
Get size in 512-byte sectors.
<LnL>
gchristensen: :p
<clever>
--getsz is the number of 512 byte sectors, for the whole disk
<andi->
samueldr: I am just fearing the amount of changes will start to queue up and like the nixpkgs issues never decrease again :)
<clever>
which translates the above into 465gig, which is the size of my disk
<samueldr>
(probably an unrelated nice binary number then)
<samueldr>
andi-: you're probably right
<gchristensen>
andi-: not sure we want to merge #209 without clearly deciding we want, strategically, to commit to a massively changed structure of the website
<clever>
--getbsz
<clever>
Print blocksize in bytes.
<{^_^}>
https://github.com/NixOS/nixpkgs/issues/209 (by cillianderoiste, 5 years ago, closed): `PYTHONPATH=/nix/store/...python-nose/.../site-packages python` import nose fails
<clever>
gchristensen: when i use the right flag, i get a 4kb block size
<samueldr>
gchristensen: I decidedly agree, which is why I would have liked feedback (and I did link it previously at different locations)
<gchristensen>
bs=977105060 makes the import take 5min :)
<samueldr>
gchristensen: that homepage change is *huge*
<gchristensen>
yeah, adding 15kloc is a thing
<samueldr>
(ideally, the same base foundations would be re-used for the options)
<gchristensen>
ok so all I'm really learning is the bigger the number the better dd does :P
<andi->
I am also not a fan of such "bloat" but the question is if it makes things better / easier in the long run... It certainly adds the burden of maintining a more complex thing that now depends on a react version that must be updated/maintained :/
<andi->
gchristensen: try -1
jtojnar has quit [Ping timeout: 252 seconds]
<gchristensen>
blockdev --getbsz /dev/sda says 2048, and that makes it much slower
<andi->
it probably is pre-fetching things without having another (sys) call inbetween?
<gchristensen>
andi-: is that real?
<andi->
gchristensen: no idea
<samueldr>
andi-: I wholeheartedly agree; I would even go as far as re-doing it. Since the time I wrote it I learned a bunch more :/
<samueldr>
andi-: but I have to say that the current implementation *also* needs to be maintained
<andi->
samueldr: but that can be done by mostly everyone that ever did any JS/jquery ;)
<gchristensen>
I've also rewritten the options (and intended on doing the package) page in Elm, but mostly as an exercise in learning.
<samueldr>
andi-: and being a spliced chunk of JS in an HTML document in a perl-based template is... not the best :/
<samueldr>
gchristensen: yeah, it it hadn't been for the issues with Elm when I did start the rewrite in Elm I would have merged them together as a proposal :/
<andi->
standard engineering approach: Everything that we have right now isn't great. Lets redo it! :)
<samueldr>
(too many packages, the development version overflows)
<gchristensen>
yeah
<gchristensen>
imo we should stick with what we have, which is simple-even-if-not-wonderful until perhaps a bigger redoing of the site
<samueldr>
except we already *need* something more
<samueldr>
e.g.: channels selection, unfree
<gchristensen>
well, that semes like something bigger :)
<gchristensen>
I dunno
<andi->
I would go as far as not showing unfree but that is me not willing to spent a second with unfree stuff (usually)
<samueldr>
andi-: that's the bad kind of self-selection; completely hiding away the free stuff instead of defaulting to hiding and allowing to show with clear markings imho
* andi-
would even propose moving unfree to NUR but that is probably unpopular..
<gchristensen>
oh dear
<andi->
(I don't see that happening or pushing / asking for it ;)
<andi->
samueldr: besides that complicated topic I agreee.. we should show channels
<gchristensen>
passing a bs of 2048 is hilariously slow
<gchristensen>
it was probably not a good idea for hardware to lie about it
<gchristensen>
is there a way for me to know what is the right # without knowing what actual flash I have in my device?
Synthetica has joined #nixos-chat
<LnL>
not sure, but I think ssds lie about it pretty often
<gchristensen>
so I hear from some friends that it doens't matter for bs as long as I have enough RAM
<jasongrossman>
FWIW, I've experimented with block sizes on an SSD in ZFS, and it doesn't make any noticeable difference whether I give ZFS the right block size or half (I think) the right block size.
<gchristensen>
yeah, I think I'll just set bs=500000000 and call it done.
<gchristensen>
5m +/- a bit is great.
sir_guy_carleton has joined #nixos-chat
<emily>
you know you can say bs=5M right?
<emily>
slightly less portable, I think BSDs might only accept 5m or something
<gchristensen>
that is 500M :)
<emily>
er, right
<emily>
see, this is why the suffices are nice >.>
<emily>
huh, wasn't expecting it to already be in nixpkgs
<gchristensen>
aye, I'm forced to use `qemu-img dd`
<emily>
ahh
<emily>
because qcow2?
<gchristensen>
yeah
pie_ has joined #nixos-chat
NinjaTrappeur has joined #nixos-chat
<gchristensen>
pro tip: macos doesn't like its underlying FS to be rolled back
<samueldr>
the block device while running?
<samueldr>
that must be amusing
<gchristensen>
yeah, right
<andi->
sounds very picky... who wouldn't like that?
<gchristensen>
inorite?
<gchristensen>
ok but the cool thing is I have a scripted startup from pristine, rolled-back zfs snap to a macos machine ready for hydra
<samueldr>
<3
<samueldr>
I hope this makes it much more trivial to admin hydra macos hardware
<gchristensen>
me too :')
<gchristensen>
nex step is incorporating my hacky scripts in to nixos service. all the commands are ready, just need to be ... systemd'd
__monty__ has quit [Quit: leaving]
wirew0rm has quit [Ping timeout: 252 seconds]
wirew0rm has joined #nixos-chat
jackdk has joined #nixos-chat
<elvishjerricco>
gchristensen: Any idea why macos wouldn't like the FS to be rolled back? I would have that it'd have no way of knowing
<gchristensen>
well its hard disk's sectors no longer has the contents that was just there
<elvishjerricco>
gchristensen: You didn't do this while the system was running, did you?
<gchristensen>
I did
<elvishjerricco>
Oh. Lol that makes more sense
<elvishjerricco>
Oh I missed the "while running" part above
<gchristensen>
:) I just forgot to kill the machinebefore rolling back
<elvishjerricco>
I wonder how close to seamless you could make this for a personal system. Obviously it'd be a terrible idea, but if it just booted up into NixOS, and started a VM that took over the graphics / keyboard / mouse, it feel as if there's no NixOS part
<elvishjerricco>
I guess stuff like trackpad gestures wouldn't work, and the graphics would probably be really bad.
<gchristensen>
yup!
<samueldr>
elvishjerricco: IGVT should give you intel gpu acce;
<samueldr>
(if I remembered the name right)
<samueldr>
if the trackpad is usb-based, it might even be possible to send it over to the macOS machine!
<samueldr>
(it's still probably a bad idea)
<elvishjerricco>
I know it's at least possible to give a Windows Virtualbox guest direct access to an unused GPU. I wonder if you could just tell NixOS to not use the GPU and patch it through to the VM
<elvishjerricco>
Yea pci passthrough
<samueldr>
it generally needs chipset and motherboard cooperation, curious if any laptops have that
<joepie91>
it's fairly common for banks in NL to send the username and password for your ebanking account as separate snail mail letters, to make it more difficult to intercept them
<joepie91>
one bank in NL, in their haste to digitize all of their snail mail, has now updated their process to send two plaintext e-mails
<joepie91>
one containing the username, the other the password...
<joepie91>
...
<gchristensen>
...
<joepie91>
something something this is why reevaluating threat models matters :P
<joepie91>
(it's ING, by the way)
<gchristensen>
hilarious
<Synthetica>
Anyone know how long firefox takes to compile on a semi-modern i5?
<jasongrossman>
"one bank in NL" - ING advertises worldwide for online customers, so that makes it even more suprising that they'd do something so daft by email.