slack1256 has quit [Remote host closed the connection]
slack1256 has joined #nixos-chat
slack1256 has quit [Remote host closed the connection]
lovesegfault has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
drakonis has quit [Read error: Connection reset by peer]
das_j has quit [Remote host closed the connection]
ajs124 has quit [Remote host closed the connection]
das_j has joined #nixos-chat
ajs124 has joined #nixos-chat
lovesegfault has quit [Ping timeout: 265 seconds]
lovesegfault has joined #nixos-chat
* colemickens
is on his last straw with firefox
lovesegfault has quit [Quit: WeeChat 2.7]
<DigitalKiwi>
what did firefox do
<dtz>
!! what is this all about >:|
* dtz
visits in his firefox and sees notice about my browser not being supported ? It suggests I upgrade to ... among other things, firefox. Is there a real problem or is youtube being silly?
<dtz>
oh, well disabling an addon did the trick, oops, assumed I was seeing what was being pointed out or something O:)
<colemickens>
I was being whiny. Trying to be constructive instead of whiny. Which is resulting in me booting Packet to build chromium... :/
<DigitalKiwi>
that took a turn for the worst
<colemickens>
I shouldn't be so whiny, it looks like some nice things are coming, maybe, for Linux Firefox (+Wayland?) users
<DigitalKiwi>
but as long as we're whinging
<DigitalKiwi>
i can't get my raspberry pi to work after a rebuild ;_;
<pie_[bnc]>
colemickens: oh. i dont know what the implications of this are.
<colemickens>
it's at least part of the way towards hardware accelerated video, afaict
endformationage has quit [Ping timeout: 240 seconds]
<pie_[bnc]>
aha
<thefloweringash>
colemickens: what's firefox doing to you? is chromium not cached?
<colemickens>
I build chromium with wayland enabled. and firefox is just unbearably slow sometimes
<colemickens>
on Linux, that is. (or NixOS at least), even when using Nightly builds
<thefloweringash>
oh is the chromium with wayland buildable? I haven't kept up with that, last I heard it was an out of tree patch
<colemickens>
yeah, it's in-tree, buildable, and usable.
<colemickens>
I'm working on getting a package-set with it built and keeping it built a couple times a month, based on @volth's chromium-git derivation that they've been trying to submit to nixpkgs for a long time.
<colemickens>
There was a java issue that apparently was resolved or is no longer an issue, which is partially contributing to my attempt to build again.
<colemickens>
If all goes well though, I'll have a package set to accompany my wayland overlay so people can use chromium on Sway without bluriness.
<pie_[bnc]>
i want to make a bit of a library for sharing notes with my classmates and stuff, do you guys have any recommendations?
<pie_[bnc]>
(well, files)
<eyJhb>
pie_[bnc]: md + gitlab/github/bitbucket?
<eyJhb>
Then it is easy to browse etc.
<pie_[bnc]>
id need some kind of web frontend because they arent programmers
<pie_[bnc]>
eyJhb: mostly scans of notes and stuff like that
<__monty__>
There's no way to force people to make expressions extendable the way you want even without let expressions.
<__monty__>
Imagine people just substituting the entire expressions everywhere rather than using the local binding.
<__monty__>
I'm sure someone like infinisil has ideas involving the module system or something to improve the situation : )
andi- has joined #nixos-chat
<pie_[bnc]>
__monty__: i dont follow
<__monty__>
What I'm trying to say is I understand the frustration with let. I've run into it too. But the problem is a design decision, not let being part of the language.
<pie_[bnc]>
im not expecting mutability, id be fine with a modified copy
<__monty__>
I'm not saying anything about mutability.
<pie_[bnc]>
ok
<pie_[bnc]>
im not sure what design decision youre implying
<__monty__>
The decision of putting something in a let rather than as an argument or something. Which makes it impossible to override.
<pie_[bnc]>
ok sure
<pie_[bnc]>
i want transparent lets, dont ask me how that can be done reasonably :P
<__monty__>
But that doesn't fix the problem. People might decide to inline a definition "because no reasonable person would want the option of overriding this."
<pie_[bnc]>
it would still be a large granularity improvement :P
<pie_[bnc]>
(and we do have replacement functions, though maybe not a great idea)
<__monty__>
I'm not so sure. You'd probably end up having local bindings shadow top-level stuff. Let's not introduce JS-level WATs.
<pie_[bnc]>
1) im not sure what you mean 2) im not sure how youd end up with that
<__monty__>
Maybe I'm misunderstanding what you mean by transparent lets?
<__monty__>
I assume you mean you want access to the local bindings?
<__monty__>
How would you do that without their names?
<pie_[bnc]>
lets say for the sake of arument that you *can* somehow refer to the let that you want; overriddenObject = exitingGeneratorForObject oldlet.parameter1 oldlet.parameter2
<__monty__>
And if you can simply use their names, how will you deal with shadowing.
<pie_[bnc]>
hm i thought of using rec but not like that i think
<pie_[bnc]>
i should try that
<__monty__>
I'm not sure it'd work well, btw. Just what came to mind.
<pie_[bnc]>
but thats not the nixpkgs we have :P *gets pichfork* lets abolish let
<__monty__>
Not having let would just end with all the local bindings inlined. So they're *harder* to override, not easier.
<pie_[bnc]>
rec isnt let :p
<pie_[bnc]>
im only half serious
<pie_[bnc]>
(and distracted)
<__monty__>
What we need is ML Functors. That module system is gorgeous.
<pie_[bnc]>
hm.
<pie_[bnc]>
im not really interested in ml but people have said good things about that so i kind of want to try
<pie_[bnc]>
too much bucket list :(
<pie_[bnc]>
and people do a lot of neat stuff with ml
<pie_[bnc]>
like theres that one verified toolchain
<pie_[bnc]>
cakeml
<__monty__>
Hmm, Agda has a very similar module system so if you're interested in dependent types at all as well that'd be a way to do two interesting things at once.
<pie_[bnc]>
yeah agdas on the list
<pie_[bnc]>
and of course a more reasonable issue with copy pasting stuff is you dont get the upstream updates
<pie_[bnc]>
though i guess i could IFD patches to the module or something
<__monty__>
The solution to that is getting things upstreamed I guess.
<pie_[bnc]>
yeah
<lassulus>
is it possible to run nixos-install inside a nixos test?
<gchristensen>
look for the install tests :)
<gchristensen>
I once took a nixos test and creating a nixos-test-to-docbook converter for various (tested) installation scenarios
<lassulus>
cool
<lassulus>
ah it even does reboot, perfect
<pie_[bnc]>
i really need to look at tests but i never have time / always forget
<pie_[bnc]>
>.>
<pie_[bnc]>
on an unrelated note, is there any lightweight sandboxing for systemd services or is that basically containers
<pie_[bnc]>
because im starting to wonder if im going at this wrong
<pie_[bnc]>
i have a container and now im going to bind mount some data into it to make iterating on the application config easy without clearing data
<pie_[bnc]>
and that also means migration and backups and whatever else should be easier too
<ajs124>
there's the systemd containment stuff. what exactly are you looking for?
<pie_[bnc]>
i was just wondering if im going overkill with containers
<ajs124>
systemd also supports a bunch of sandboxing for services, like PrivateMounts, PrivateUsers, etc.
<pie_[bnc]>
i make a container for everything
<pie_[bnc]>
i have a murmurd container, two containers for two different vpns
<pie_[bnc]>
making one for prototyping some nextcloud stuff i might want to use later right now
<pie_[bnc]>
this is all with nixos stuff of course
<__monty__>
Maybe an overlayfs can help? I think you can change the lower dir from outside the container.
<ajs124>
imho you get an equivalent level of sandboxing when properly setting systemd options that you get with containers. There's more reasons for containers than sandboxing, though.
<pie_[bnc]>
sounds easier to just go with the containers
<pie_[bnc]>
__monty__: i dont follow why an overlayfs would be better/necessary
<__monty__>
Well bind mounts are bidirectional so to speak. You talked about sandboxing. An overlayfs would prevent the container from writing to certain bits while still being able to read from them.
<pie_[bnc]>
ah
<pie_[bnc]>
i think a bind is fine for my case, it would just be a directory dedicated to this
<pie_[bnc]>
its just for the application data
* pie_[bnc]
runs off to do some errands
* pie_[bnc]
got his smolhaj cleaned finally
* pie_[bnc]
can now pair program again
<Taneb>
:D
<Taneb>
I've never tried pairing with my Blahaj
<FireFly>
bluetooth enabled blåhaj..
<pie_[bnc]>
haha
<pie_[bnc]>
FireFly: its bla for blatooth
<FireFly>
blåtandad blåhaj, why not
<pie_[bnc]>
he smelled bad because he partied with me at ccc
* FireFly
looks around
<FireFly>
there's a blåhaj and several småhajar here
<FireFly>
this place is good
<pie_[bnc]>
i was thinking of asking my friend id i could have his blahaj but i couldnt bring myself to do it
<pie_[bnc]>
menage a trois with sharks as ergonomic programming arm supports
<FireFly>
I tried to fit an IKEA visit into my trip from Stockholm to Brussels, but didn't manage to.. (specifically to one of the IKEAs on the way that had smol ones left :p)
<FireFly>
ahwell
KeiraT has quit [Remote host closed the connection]
KeiraT has joined #nixos-chat
<pie_[bnc]>
smolhaj mafia
<pie_[bnc]>
gotta find someone that will get it for you :p
cransom has joined #nixos-chat
endformationage has joined #nixos-chat
<pie_[bnc]>
re, the nextcloud stuff from earlier;
<pie_[bnc]>
<pie_[bnc]> so. dumb question. can I back up my databases by just snapshotting them / can i "migrate" stuff by just copying them
<pie_[bnc]>
<pie_[bnc]> though right now what i really want to do is separate my data from my containers via bind mounts
<pie_[bnc]>
can i just copy a postgres database?
<pie_[bnc]>
by which i actually mean switch out the container on top of it
<clever>
pie_[bnc]: pg_dump is your answer
<pie_[bnc]>
clever: it would be nice if i didnt need to care about running htat
<pie_[bnc]>
just kill the container and be done with it
<gchristensen>
you need the entire PG data directory and the tablespace data and ideally stop the server first, or use a truly atomic snapshotting filesystem
<pie_[bnc]>
yeah
<infinisil>
Aw yeah, I think I'm done with studying, just had the last exam
<qyliss>
ever, or...?
<infinisil>
Yup! Well at least I don't habe plans to continue anytime soon :)
<infinisil>
have*
<infinisil>
So sick of studying
<worldofpeace_>
infinisil: I recommend any form of activity that's not mental
<worldofpeace_>
unless the mental drained the physical
wildtrees has joined #nixos-chat
<infinisil>
worldofpeace_: Probably a good idea yeah :)
<philipp[m]>
Is anybody here using some packages in emacs for better buffer/window management that they can reccomend?
* infinisil
wishes emacs windows and X windows would be unified
<philipp[m]>
I mean, there is exwm...
<infinisil>
Good point.. Though I thought of the other direction :)
<drakonis>
exwm but for wayland?
<pie_[bnc]>
if you have root in a container with a rw bind mount to the outside world, can you create a suid executable on the outside
<pie_[bnc]>
(i dont see why you couldnt, and it looks like you can)
<__monty__>
I suspect yes because of how reliable containers' mitigations against gaining root access have been...
<__monty__>
Thought nspawn in particular was not vulnerable to the latest privilege escalation exploit I heard about.
<pie_[bnc]>
its so easy for this stuff to interact badly
<pie_[bnc]>
root is rootand by easy i mean i can imagine it being easy for it to interact badly
<pie_[bnc]>
so...wat do
<pie_[bnc]>
not that im really worried about this
<__monty__>
I don't think sudo inside a container is equivalent to sudo outside a container, barring exploits.
<pie_[bnc]>
i could make a separate data partition on the outside that blocks exec and suid
<pie_[bnc]>
__monty__: right, but if you can make a suid executable inside the container on the outer filesystem, and have a user on the outer system, you can privesc the outer user
<pie_[bnc]>
s/right/sure/
<__monty__>
Maybe try it?
<pie_[bnc]>
uh
<pie_[bnc]>
idk what program to use
* pie_[bnc]
googles for suid privesc code
<pie_[bnc]>
__monty__: i mean,why wouldnt it work? i can create the suid binary, and its a normal filesystem on both sides
<__monty__>
I'm not too clear on what suid means.
<__monty__>
Don't you need privileges to run them?
<clever>
if a binary has the setuid bit set on it, then running the binary, causes the UID to get changed to the owner of the binary
<clever>
for example, the sudo binary is setuid, and owned by root, so running sudo, magically makes the process root
<clever>
its then up to the code in sudo, to decide if you should be able to use that new power or not
<__monty__>
But is the root inside the container the same as root outside?
<clever>
thats what uid mapping and the uid namespace handles
<pie_[bnc]>
so, works in my testing.
<clever>
it should map root in the container, to another uid on the outside
<clever>
so your not actually root
<pie_[bnc]>
though i vaguely remember people saying something about you shouldnt expect root in container to be safe?
<pie_[bnc]>
ah. <clever> it should map root in the container, to another uid on the outside
<pie_[bnc]>
well, nixos-container does not do this
<clever>
one min
<clever>
pie_[bnc]: find the host pid of something in the container (ps aux outside the container), then cat /proc/PID/uid_map, what does it say?
<clever>
then `man user_namespaces` and look for uid_map
<philipp[m]>
I think ace-window does just enough for me and C-<Tab> is a nice binding that wasn't used before.
<pie_[bnc]>
clever: $ cat /proc/9700/uid_map
<pie_[bnc]>
0 0 4294967295
<clever>
i get the same with a non-sandboxed pid
<pie_[bnc]>
i dont know how bind mounts work internally
<clever>
pie_[bnc]: that maps 4 billion (the entire 32bit range) UID's from 0 in the namespace to 0 in the host
worldofpeace_ has quit [Quit: worldofpeace_]
<pie_[bnc]>
im assuming i cant just binary bit twiddle data on a bind mount into giving me binaries with specific uids, because its not a block device
<clever>
i think i'm missing something with uid_map though
<clever>
even docker claims the same
<pie_[bnc]>
clever: it doesnt sound like a property that should be per process, otoh idk how the kernel works, it couldbe
<clever>
pie_[bnc]: oh, maybe i need to target the root process of the namespace...
<pie_[bnc]>
like, my knee-jerk noob architecture is to have some sort of parent process dealing with this, but if the propagation is sound i guess any process dealing with the maps is fine
<pie_[bnc]>
(means you dont have to traverse the entire proess tree all the time?)
<pie_[bnc]>
clever: maybe oure not crazy and it needs to be explicitly enabled in docker too
<pie_[bnc]>
i watched the I AM THE MAN WHO ARRANGES THE BLOCKS song again today and ive had "long live stalin he loves you, sing this song or you know what he'll do" going in my head all day
psyanticy has quit [Quit: Connection closed for inactivity]
kraem has joined #nixos-chat
<sphalerite>
windows's backup options are confusing…
<sphalerite>
well, I've now got 3 different types of backup going from my partner's laptop to my backup server
<sphalerite>
let's hope at least one of them is useful
kraem has quit [Quit: outta here]
kraem has joined #nixos-chat
<samueldr>
let's hope you never need any of them
<sphalerite>
zfs has a great deal of useful and nice functionality, but I think my favourite is still `zfs inherit`
<sphalerite>
CLEAN UP ALL THE PROPERTIES!
<infinisil>
sphalerite: Never needed zfs inherit, why's that useful?
<__monty__>
infinisil: Careful. When people say things like that you're usually about to find out about some obscure sort of hammer that makes everything look like an obscure nail ; >
<sphalerite>
infinisil: to remove manually-set properties and "clean up" the tree
<sphalerite>
infinisil: it's _mostly_ an aesthetic thing, but can be really practical when dealing with mountpoints for instance
<sphalerite>
it does depend a bit on what you're storing, how granular and how nested your datasets are, …
<infinisil>
I set mountpoints with, well, `zfs set mountpoint=`
<sphalerite>
yes, but if you reorganise your datasets and one of them is now a child of the other and you want its mountpoint to reflect that, you may want to use `zfs inherit mountpoint tank/parent/child` rather than set
<sphalerite>
that way, if you rename parent later on, the child's mountpoint gets adjusted accordingly
<sphalerite>
zfs inherit isn't so much an amazing feature as it feels really good to use :p
<infinisil>
Hm I see
<joepie91>
currently auditing a Google-originating library, and I'm reminded of why I hate Google stuff
<joepie91>
they have their own everything for everything, none of it integrates with standard ecosystem tooling, and most of it is worse than said ecosystem tooling...
<DigitalKiwi>
shhh, they're listening
<__monty__>
sphalerite: Hmm, the graffiti removal's nice.
<__monty__>
nn, peeps
__monty__ has quit [Quit: leaving]
<gchristensen>
it would be cool if nix-shell set the terminal's title to the name of th edrv
<samueldr>
let me get philosophical, what _is_ a terminal title? :)
<gchristensen>
the thing that `swaymsg -t get_tree` puts in to the "name" field
<drakonis>
not every terminal emulator respects that mind you
<gchristensen>
sure
<drakonis>
konsole sets it to the name of the binary
<drakonis>
gnome always sets it to terminal
<drakonis>
or whatever profile name i want
<gchristensen>
pretty sure it is settable in some fairly standard way
<gchristensen>
for example, ssh does
<DigitalKiwi>
use a better terminal
<gchristensen>
meh they can keep using one which doesn't respect it, but it would be nice if nix-shell set it for those that did