<sphalerite>
(tbf that was 1.x -> 2.0 which was a big release anyway)
<sphalerite>
well! TIL
<srhb>
No it wasn't :) 1.11.16 should evaluate nixos-18.03
<sphalerite>
oh ok, never mind me then :p
<srhb>
Let me see if I can find it...
<sphalerite>
but as far as backwards compatibility goes… nix 2.1.2 can evaluate stuff from nixos-13.10
<srhb>
Wow :)
<srhb>
.10 what is this heresy
<sphalerite>
:')
<sphalerite>
wheee got my map of upper bavaria downloaded in osmand
<sphalerite>
now all I need to do is board the plane!
<srhb>
osmand?
<srhb>
Big step. :) Munich was it?
<sphalerite>
yep
<srhb>
I have some family there. I don't think they sound so weird. Maybe I have a good ear for Bavarian :P
<sphalerite>
osmand is an android app for various map-related stuff that uses offline maps with data sourced from openstreetmap
<srhb>
Ah :)
<sphalerite>
(OpenStreetMapANDroid)
<srhb>
I see.
<sphalerite>
it's great
<sphalerite>
(because I don't have google stuff on my phone)
<srhb>
It's so hard to avoid these days... :(
<jasongrossman>
I agree, it is great.
<srhb>
Like, the only way I appear to be able to use my banking app is to have an unrooted, completely googleified phone.
<jasongrossman>
Both because it helps you avoid Google and also because it keeps the maps locally.
<sphalerite>
ugh
<srhb>
Because "trust" is apparently "google"
<sphalerite>
jasongrossman: yes! And offline navigation!
<jasongrossman>
Exactly.
jasongrossman has quit [Quit: ERC (IRC client for Emacs 26.1)]
<sphalerite>
and gpx track recording, because I can't just go walking or cycling without recording it! (not that I ever use the recordings afterwards but it's the thought that counts right?)
<joepie91>
sphalerite: srhb: FYI: if you install osmand from f-droid instead of google play, you get the full version without map download restrictions
<Myrl-saki>
manveru: It should be easy now, I believe? Considering that we have librsvg, and god knows what links with that.
<Myrl-saki>
Emacs depends on librsvg.
<manveru>
possibly... i haven't done rust beyond hello world, just thought someone who's actually knowledgeable might respond
<Myrl-saki>
librsvg seems to be built with mkDerivation instead of buildRustPackage though.
jasongrossman has quit [Ping timeout: 240 seconds]
<Myrl-saki>
So I checked how librsvg's build works.
<Myrl-saki>
I don't understand it.
harrow` has joined #nixos-chat
tilpner_ has joined #nixos-chat
edef_ has joined #nixos-chat
edef has quit [Killed (verne.freenode.net (Nickname regained by services))]
edef_ is now known as edef
ivan_ has joined #nixos-chat
harrow has quit [Ping timeout: 240 seconds]
clever has quit [Ping timeout: 240 seconds]
dmc has quit [Ping timeout: 240 seconds]
ivan has quit [Ping timeout: 240 seconds]
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
ivan_ is now known as ivan
dmc has joined #nixos-chat
nly has quit [Ping timeout: 272 seconds]
jasongrossman has joined #nixos-chat
jasongrossman has quit [Ping timeout: 252 seconds]
jasongrossman has joined #nixos-chat
<sphalerit>
joepie91: there are map download restrictions on the play version? :p
<sphalerit>
As I said I have no google on my phone so I wouldn't know, I use fdroid for all my apps :)
<joepie91>
sphalerit: yeah; on google play there's a free version with like a 10 map download restriction, and a paid version without it
<joepie91>
but this limit doesn't exist on f-droid
<joepie91>
presumably that's their funding model, similar to how some apps only charge iOS users
<sphalerit>
There's also the osmand live thing isn't there?
<jasongrossman>
Using F-Droid should be compulsory for NixOS users. I know! Let's make NixOS only available as an F-Droid app.
<joepie91>
sphalerit: yeah, don't know the specifics of that
<joepie91>
jasongrossman: let's... not
<joepie91>
:p
<sphalerit>
But yeah I use the f-droid version and donate to the project, so it's like I bought it except no google involved :S
<sphalerit>
:D *
<joepie91>
hehe
<jasongrossman>
sphalerit++
<{^_^}>
sphalerit's karma got increased to 1
<jasongrossman>
(For donating.)
<sphalerit>
jasongrossman: let's modify fdroid to be based on nix!
<jasongrossman>
sphalerit: Yes.
<sphalerit>
Oooooh my first karma on this nick :p
<sphalerit>
I'm considering buying the librem 5 just because I have this pipe dream of having my phone running nixos
<jasongrossman>
Yeah. The phone ecosystem is almost completely fucked.
<simpson>
Happens.
<adisbladis>
sphalerit: It's not so much a pipe dream with the librem 5 :)
* adisbladis
should take up his work to package plasma mobile again
<adisbladis>
sphalerit: There is not too much missing to get it up and running on nixos
<sphalerit>
adisbladis: yeah, exciting stuff
<sphalerit>
I think I'm already at the point where I'm using my arm Chromebook more than my big laptop
<sphalerit>
Nixos on arm is definitely workable
<sphalerit>
Just not sure about how well I could use it without a proper keyboard, and if I lug a Bluetooth keyboard around I might as well take my Chromebook
sir_guy_carleton has joined #nixos-chat
<sphalerit>
So many things I might buy once I start getting money xP
__monty__ has joined #nixos-chat
sir_guy_carleton has quit [Disconnected by services]
<gchristensen>
does this script count as a quine? "#!cat\n"
<simpson>
Monte's modules are immutable objects. The workspace "inside" of the module is actually a script that is run on the module's imports to produce exports. Since modules are immutable, we can statically link modules together without running them.
<jD91mZM2>
gchristensen: YEE
<jD91mZM2>
simpson: still confused
<jD91mZM2>
Is monte compiled?
<simpson>
Monte doesn't really care whether it's compiled. We can either emit each module into its own .mast file, kind of like Java and .class files, but also it's possible to link multiple modules together into a single .mast.
<jD91mZM2>
Ah, so `this.module()` can access sort of everything, assuming modules are inlined?
<jD91mZM2>
Or can't you call functions on it?
<simpson>
You can call stuff from it, particularly m`this.module()(null)` to get a map of exported values from the module.
<jD91mZM2>
oooo
<simpson>
m`def main(...) as DeepFrozen { def m := this.module()(null)["main"] }` as a basic recursive example.
<jD91mZM2>
amazing
<elvishjerricco>
what's everyone's favorite grub splash image for their NixOS machines?
<samueldr>
I initially made mine the wallpaper of the user
<samueldr>
but uh, I kinda dropped the ball and hardcoded the wallpaper of the one machine I was using at the time :)
<samueldr>
the idea being that it is also the background image used for lightdm
<samueldr>
so it'd leave only the boot log part where either plymouth or other solution could be used
<joepie91>
tl;dr vector fonts that contain metadata specifying scalable transformations
<joepie91>
so 'weight' can be expressed as a property of the font that dynamically modifies the glyps based on what is specified, with only a single set of glyps
<joepie91>
but so can many other things
<samueldr>
joepie91: yep, though practicality says: won't be usable for a while :/
<samueldr>
joepie91: lucky, but when the end-users are using it, it's a pain, just as much as users using older macOS or iOS releases with safari
<samueldr>
well, I'd rank those macOS iOS version worse since you can't actively test them right
<samueldr>
(and yes, they should upgrade, but try to explain that)
<joepie91>
samueldr: oh, I know; but my POV is that anything not standards-adherent is not my responsibility, which is something that's fairly well-accepted in software development in general but somehow gets an exception for browsers
<samueldr>
(no your iPad that works right for pretty much everything you do with it is actually EOL and should be thrown away)
<samueldr>
but there is no "standard" anymore :/ it actually *is* compliant, to that moment in time :(
<samueldr>
which is what makes it worse
<joepie91>
samueldr: there absolutely are standards; IE flagrantly violated them *all the time*, which is why I don't support it :)
<joepie91>
like, we're not just talking about outdatedness here
<joepie91>
but about outright out-of-spec behaviour, unnecessarily delayed spec implementations, etc.
<samueldr>
though, the end-user doesn't care about implementation, which is a truth I hate :(
<joepie91>
samueldr: that's a really common narrative but actually totally unlike my experience
<samueldr>
what the end-user sees is a product that doesn't work and they can't be asked to understand why :(
<joepie91>
I've dealt with non-technical users running outdated / out-of-spec browsers before
<joepie91>
if you give them instructions on how to easily upgrade/replace their browser, with an average-person-understandable explanation of why... the upgrade rates are pretty crazy
<joepie91>
one particular case was back when Chrome was still very new, and IE dominated the market
<samueldr>
I guess you've been lucky, or I've been unlucky
<joepie91>
I sent out a newsletter to all users explaining the problem with how costly it was to support browsers, how it meant I couldn't spend as much time on new features
<joepie91>
indicating that I would stop supporting IE versions such-and-such
<joepie91>
upgrade rate was somewhere in the 70%, about half to the latest IE, the other half to Chrome or Firefox
<joepie91>
(based on active users)
<joepie91>
these were mostly non-technical users
<joepie91>
but it *really* matters how you present it
<joepie91>
anything that looks like technical gobbledygook gets right ignored; you shouldn't spend more than one sentence on something generic like "IE has a lot of bugs", and spend most of the time explaining 1) why they benefit from you stopping to support it, and 2) what button to click to fix it
<samueldr>
non-technical but using a computer daily with their work, or non-technical and avoiding computers daily?
<joepie91>
samueldr: the best answer I can give to that is "users of an early social network"
<samueldr>
our user base are the kind that tries to fill in a form in a screenshot in a PDF document
<samueldr>
the kind that actively tries to avoir using computers :(
<samueldr>
avoid*
<joepie91>
I suspect that the 'magical fix button' narrative would work even there :P
<samueldr>
"magical fix button"?
<joepie91>
samueldr: no complicated explanations, just "your browser is broken, click here to fix it" but less malware-looking
<joepie91>
unambiguous instructions
<samueldr>
it's already implying they understand "browser" :/
<joepie91>
not really; the "click here to fix" is separate understandable
<joepie91>
if it said "click here to fix your browser", that'd be a problem
<joepie91>
separately*
<joepie91>
basically, make the part with the technical word ignorable :P
jD91mZM2 has quit [Ping timeout: 268 seconds]
<elvishjerricco>
Whoo! Encrypted /boot! Grub decrypts it, and `boot.loader.grub.extraInitrd` provides a keyfile for the kernel to decrypt it too. I had to wipe my laptop and start over to switch from ZFS encryption to LUKS, but it seems like it should be pretty easy to port any LUKS-based system to this without starting over.
<joepie91>
hmmmmm.
<joepie91>
unmounting /boot
<joepie91>
safe to do on a running system?
<elvishjerricco>
joepie91: ......maybe? I can't think of a reason it wouldn't be, but it sounds dangerous :P
<joepie91>
yeah, hence the question :P
<joepie91>
I made the mistake of a 100MB boot partition
<gchristensen>
sure, definitely safe
<joepie91>
I would like to undo that mistake because realistically I have no reason for a separate boot partition
<samueldr>
the first one with the loop puts the output at the bottom so the caret is at the bottom instead of the top
<samueldr>
(which is the look I wanted)
<elvishjerricco>
samueldr: Oh boy :P
<elvishjerricco>
There's not a way to just tell the kernel "Don't make a console"?
<samueldr>
did I say workaround?
<elvishjerricco>
hah
<emily>
can you just replace stage1 with your own
<samueldr>
maybe if you use console=tty2?
<emily>
I don't much like NixOS's stage1 at all...
<elvishjerricco>
emily: Why not?
<samueldr>
yeah, replacing the whole stage1 is possible too, but that's something else entirely :)
<emily>
elvishjerricco: it's a pile of shell scripts with half of a toposort implementation instead of a real dependency management system
<elvishjerricco>
lol
<emily>
like,
<elvishjerricco>
fair enough
<samueldr>
you're not wrong
<emily>
a simple straight-ahead shell structure would be okay if it didn't try to also support a bunch of fancy things
<elvishjerricco>
It does things that I need though so I'll stick with it :P
<emily>
just rebuilding it on top of the nixos systemd services infrastructure would make it much faster and much more flexible
<samueldr>
I love how it is relatively straight-forward to make a custom stage-1 though
<emily>
and probably less code
<emily>
but the initramfses would get bigger, I guess
<emily>
this would also integrate with Plymouth &co. better
<samueldr>
hm, that would be a dealbreaker since you end up having multiple initramfses
<emily>
hm?
<joepie91>
one initramfs for every system generation
<gchristensen>
samueldr: oh speaking of which, how is the looming october-1 looking? :D
<samueldr>
if the initramfses double in size, you can have fewer of them
<elvishjerricco>
joepie91: Shouldn't be one per generation
<samueldr>
gchristensen: I was looking into that
<joepie91>
(incidentally this is why I was nuking my /boot)
<elvishjerricco>
Should only be one per each time the initrd ever changes
<elvishjerricco>
which isn't most generations
<samueldr>
depends how often you create generations
<joepie91>
that doesn't match my experience
<elvishjerricco>
I have like 100 generations right now but only 7 initrds in my /boot
<samueldr>
and what change occurs between those
<gchristensen>
samueldr: I was thinking about doing some last minute touch-ups on the fdisk stuf
<samueldr>
gchristensen: have you seen there is one (new) PR about that
<gchristensen>
I have not
<gchristensen>
is it good / correct?
<samueldr>
yeah!
<samueldr>
but gchristensen, what if instead of fdisk parted commands would be used? just like in our tests?
<samueldr>
instead of fdisk, parted commands* (missing comma)
* samueldr
hates the silly fdisk one-letter commands things
<gchristensen>
whatever it takes
<elvishjerricco>
Though now that I've switched to grub, I see that grub just reads kernels an initrds out of the /nix/store directly, rather than putting things in /boot. That's quite nice.
<elvishjerricco>
Or maybe that's only because it knows /boot is on the same file system or something... I dunno
<emily>
hm, why do you need /boot at all then?
<emily>
couldn't /boot just be a /nix/store path
<emily>
I guess grub needs to know which one to look at
<joepie91>
[01:49] <elvishjerricco> Or maybe that's only because it knows /boot is on the same file system or something... I dunno
<joepie91>
correct
<gchristensen>
since it is a port of entry, it pretty much needs to be mutable I think
<joepie91>
copyKernels defaults to true if /boot is on a different partition
<joepie91>
otherwise it defaults to false
<elvishjerricco>
joepie91: Ah. Well when I used systemd-boot and had /boot on a different partition, I only had 7 initrds in /boot
<elvishjerricco>
despite like 100 generations
<elvishjerricco>
the path to the kernel and initrd corresponds to the nix store path, so as long as that hasn't changed, there won't be duplication
jasongrossman has quit [Ping timeout: 240 seconds]
<joepie91>
elvishjerricco: ah, it seems to be the bzImages that constantly change
<joepie91>
wait no
<joepie91>
okay, so they indeed don't change every generation
<joepie91>
but quite often...
<joepie91>
initrd a bit less often
<joepie91>
init and systemConfig change all the time :p