Synthetica has quit [Quit: Connection closed for inactivity]
disasm| has quit [Quit: WeeChat 2.0]
drakonis has joined #nixos-chat
disasm has joined #nixos-chat
Guanin has quit [Remote host closed the connection]
aleph- is now known as Church-
iqubic has quit [Read error: Connection reset by peer]
iqubic has joined #nixos-chat
<colemickens>
When I upgrade my Azure VM to nixos-unstable, shut it down and then boot it a few hours alter it never comes up.
<colemickens>
If I shut it down and reboot it after only a minute or two, it seems to handle itself better. It's probably related to the Agent or something though, ugh.
<colemickens>
actually, maybe not. This time it was just the pip changing. Last time it failed to boot though. Luckily now that I'm in the new one, I cna triage the failed one.
drakonis has quit [Quit: WeeChat 2.4]
iqubic has left #nixos-chat ["ERC (IRC client for Emacs 26.1)"]
Myhlamaeus has quit [Ping timeout: 258 seconds]
Peetz0r has quit [Ping timeout: 252 seconds]
Peetz0r has joined #nixos-chat
endformationage has quit [Ping timeout: 248 seconds]
<adisbladis>
That looks like it might be really nice on mobile
<adisbladis>
I _hate_ all current input methods on touch screens...
<aanderse>
i recall when android first started getting i wondered why no one had ported dasher to android
<__monty__>
Hmm, that would be pretty good use of the copious vertical screenspace in portrait orientation.
<aanderse>
it might be horrible, but it could be awesome. hard to say without trying
<__monty__>
How does it fare with unicode input though? Too many choices to go through, surely?
<adisbladis>
__monty__: I guess you'd have to special case emojis (or make categories that can also be navigated?)
<aanderse>
would probably work really well for japanese input as japanese input has some similar ideas to that
waleee has joined #nixos-chat
Guanin has joined #nixos-chat
endformationage has joined #nixos-chat
Jackneill has quit [Read error: Connection reset by peer]
Jackneill has joined #nixos-chat
<eyJhb>
Anybody have experience with Gitlab and releases/tags? Trying to automate the release page, like e.g. ghr can do for Github
<etu>
I think I've seen that dasher thing before... Like years ago...
<etu>
That as a keyboard for Android would be fun
<Taneb>
I've been trying off-and-on (not very hard) to package dasher in nixpkgs
<samueldr>
used it on maemo and meh; it ended up more inconvenient imo; though I guess that it required less precision to input, but never had to use it in a situation where I needed less precision
<samueldr>
and most amazing good keyboards out there do similar tricks with the key sizes; the most likely next keys have a bigger hit target
<manveru>
Taneb: wasn't it packaged at some point?
<Taneb>
Not to my knowlege?
<manveru>
hmm, i think it was part of gnome
<manveru>
like 10 years ago :)
<manveru>
anw, what's the issue with packaging it?
<Taneb>
The build script does something funky and I never quite have enough energy to figure out what it is
<manveru>
guess i'll give it a try then
<adisbladis>
What on-screen keyboards are you using now?
<adisbladis>
I haven't been happy with mobile input since my last phone with a full keyboard -.-
<adisbladis>
If only the planet computer stuff could run a mainline kernel...
<andi->
wasn't there an blackberry with a physical keyboard and android?
<andi->
by now probably a bit dated but it looked okay.
<samueldr>
blackberry has excellent bootloader security
<samueldr>
sadly
<samueldr>
I'm using swiftkey since it's the only keyboard with predictive text that handles bilingual writing right
<samueldr>
as in, switching from english to french to english in one sentence
<samueldr>
and as for linux (not android) no idea about onscreen keyboards yet
<adisbladis>
samueldr: Same same..
<andi->
ohhh, might have to check that out. I constantly switch between german and english and it is just annoying.
<samueldr>
same same for? :)
<adisbladis>
Swiftkey
<samueldr>
swiftkey is non-free non-oss, and owned by MSFT
<andi->
uargh
<samueldr>
pro-tip: I disable "complete on space"
<andi->
and they use all your typing to train their ML models?
<samueldr>
AFAICT it looks like it can be used without that being activated
<samueldr>
but not entirely positive
<samueldr>
have been using it since... way back when, when it didn't hit me as hard as it does today...
<adisbladis>
On my tablet I'm using the KDE virtual keyboard
<adisbladis>
It's not great...
<andi->
Android has a bazillion permissions but you can't disable network access for applications..
<clever>
andi-: it used to be an option, i dont like how they just assume true now
<andi->
Can't wait for the Pinephone/Librem5..
<andi->
I will have other issues to complain about then :D
<samueldr>
won't we al
* samueldr
really needs to kick himself back on that
<clever>
ubuntu has a thing called snap, that is basically docker with x11 support, and an app store
<infinisil>
Apparently iOS 10 doesn't have these big README letters :)
drakonis has joined #nixos-chat
drakonis_ has joined #nixos-chat
drakonis_ has quit [Client Quit]
<gchristensen>
it will be politically interesting to see what happens w.r.t. the kernel patch which makes ZFS slow vs. distributions reverting that patch
<drakonis>
did debian do that?
<drakonis>
has debian reverted the patch?
<gchristensen>
we have, I'm not sure anyone else has
<srhb>
I think most most other distros that care are still debating the ramifications of the patch.
<gchristensen>
right
<gchristensen>
Debian might not have the kernels yet in stable
<drakonis>
they're not going to have it in stable until 2 years later
<drakonis>
they're shipping 4.19 on stable
<gchristensen>
well the patch was backported to 4.19
<drakonis>
hm, i see.
<drakonis>
but why?
<gchristensen>
hard to know
<drakonis>
sure that they don't want anything to do with oracle and cddl
<drakonis>
but backporting it to older versions seems excessive?
<gchristensen>
it is possible that some emails from zfs users to the mailing list instigated Greg in to backporting it.
<drakonis>
ohboy.
<gchristensen>
I don't actually know fwiw
kraem has joined #nixos-chat
<drakonis>
there was someone being explicitly bad faith
<__monty__>
Why is ZoL so set on being out of tree? Wouldn't that get rid of all the drama?
<kraem>
Hi! Thought I'd try in this chat first: I'm currently on Arch and thought I'd spend my summer off from school (well kinda) learning myself functional programming and nixOS. I love the declarative style of configuration. My question is do you think it's enough backing up my /etc and the regular dotfiles before migrating? Is there any folder that *should* be backed up? Thanks :)
<drakonis>
afaik its because the developers are salty sun greybeards
<drakonis>
the main developers
<gchristensen>
kraem: usually when I back up other systems, I'll get /var, /etc, and /home
<drakonis>
and there's a strong intersection with the bsd people
<kraem>
gchristensen: cool! can't remind myself of touching anything in /var though
<gchristensen>
you probably wouldn't regret losing it much :)
<kraem>
ok thanks - i think my dotfile repo + /etc will work then :)
<__monty__>
kraem: /var is for program data.
<drakonis>
i think gregkh wouldn't readily backport the patch if there wasnt some guy yelling about how the gpl condom works
<drakonis>
on the mailing list
<srhb>
kraem: fwiw I tend to do a full copy then trim it down of useless stuff using ncdu.
<srhb>
kraem: Once it's small enough that I'm good with storing it all indefinitely in /home/sarah/bak/bak/bak/bak/bak/... (see xkcd I-don't-recall) I stop :-P
<drakonis>
srhb, haha i keep doing that whenever i lustrate previous installs
<joepie91[m]>
kraem: there may also be stuff in /srv and a few other folders. the Arch wiki has a page on full-system backups with rsync, which has a pretty good set of excludes
<srhb>
The trick is to ensure that your backup size grows slower than overall harddisk space.
<srhb>
Disturbingly easy.
<andi->
I bet on compression technology to advance fast enough.
<srhb>
andi-: :D
<joepie91[m]>
might want to add /bin and /usr/bin and such to the excludes, but otherwise a good place to start
<joepie91[m]>
and an exclude-based approach means you won't accidentally miss folders you care about
<drakonis>
__monty__, there was some offhand remark regarding some of the ex sun devs not liking that ZoL is the predominant upstream and that they have to contribute code to it
<gchristensen>
recently I was looking through a backup (which was a the result of `dd`) for an old file, found another backup inside which was a `dd` and found it inside the nested one, guh, backup hygiene, amirite?
<srhb>
gchristensen: lol!
<andi->
Ever since I migrated to NixOS I stopped doing full backups of everything and just backup state and nix files.. So much nicer..
<joepie91[m]>
gchristensen: copy of backup old(2) final
<gchristensen>
.iso
<srhb>
andi-: And silly secrets...
<kraem>
haha my filesystem is not that complex yet - haven't been hording that much - pretty much all "data" i want saved is synced with syncthing to a small laptop at home
<srhb>
kraem: Great :) Should be easy.
<gchristensen>
keep that cleanliness up
<andi->
srhb: I have been using an x220 for my primary developemt for a few weeks now. I only ever used my yubikey. No other (plain) secrets on the device.
<srhb>
andi-: Good job. I really need to fix that...
<gchristensen>
wow
<srhb>
andi-: I have too many secrets though...
<kraem>
think i'll just double check all important dots and tar the /etc to my laptop-server :)
<srhb>
I don't think a yubikey could really save me. I need something else..
<andi->
srhb: Well I use my password manager for more secrets.
<gchristensen>
andi-: you don't `scp old:.gnupg ~/.gnupg` ?
<__monty__>
Drakonis: Thanks for the background. Tbh I forgot about BSD and also that ZoL de facto *is* ZFS now.
<andi->
gchristensen: Not this time. It worked really well.. I had to download my own public key tho..
<srhb>
gchristensen: Actually, my private gpg key is the one thing I have under decent control...
<srhb>
But then there's ssh keys, wireguard secrets... I don't even recall anymore.
<gchristensen>
what do you consider secret for wireguard?
<drakonis>
also relevant to the background, illumos has been dead and buried for a while now, despite what their users will tell you
<aanderse>
i gotta setup a monthly reminder to check that my backup systems are working :\
<aanderse>
i recently checked and some of my backups hadn't run in ~6 weeks
<drakonis>
ZoL has been hoarding changes that arent pushed into illumos' tree
<srhb>
gchristensen: Just the private key.
<gchristensen>
nice.
<srhb>
I mean, it's not weapons grade...
<gchristensen>
wireguard isn't military grade??
<srhb>
xD
<andi->
some people would disagree
<srhb>
I mean, if I lost it I would actually consider it relatively easy to undo the damage, compared to say my passphrase to my private ssh key and the key itself..
<drakonis>
also regarding license changes, if it gets relicensed to non cddl, linux pretty much becomes completely unstoppable
* srhb
shudders
<srhb>
I have this one key that does.. Too much.
<drakonis>
because who's gonna care about non linux for storage once zfs is upstreamed
<andi->
srhb: I have (on the other device) like 50 private keys
<srhb>
Drakonis: I keep my fingers crossed for bcachefs..
<drakonis>
ah yes, i'm hoping it comes out
<drakonis>
seems to be nearly ready for prime time
<srhb>
andi-: I have a decent number, but this _one_ key terrifies me :-P
<gchristensen>
rotate it!
<srhb>
Yep.
<gchristensen>
I have a key like that, I know the terror
<srhb>
I'm in the process of the mother of all cleanups, and I've been postponing this one bit :-P
<srhb>
Like, it's been months.
<andi->
just do it ;-)
<andi->
(make backups)
<kraem>
__monty__: talking about ZoL and nixOS - do you reckon I should go for LUKS for encryption or is it easier going with ZFS encryption?
<__monty__>
kraem: I'm really not the right person to ask. Not a huge fan of FDE. I don't run zfs or luks anywhere.
<srhb>
LUKS + ZFS is pretty easy on NixOS with just a few caveats.
<srhb>
That's the route I took fwiw.
<drakonis>
it'd also be pretty nice if zfs wasn't alien to linux
<gchristensen>
same, though ZFS 0.8.0 wasn't stable at the time
<andi->
__monty__: what makes you NOT a fan of FDE?
<kraem>
yeah I'm afraid I'll get in trouble with the ZFS native encryption :S seems too new
<joepie91[m]>
the set of circumstances under which FDE is useful is pretty limited, and it makes things like data recovery potentially much more difficult
<andi->
kraem: have been running it since ~november.. works for me
<__monty__>
andi-: Data loss.
<kraem>
andi-: okok - feel like I need to read up more - are the encryption set up after the system + volumes has been set up?
<andi->
Okay, I am more afraid of other people accessing my data then I am about actually losing one of many encrypted copies..
<srhb>
kraem: iirc the only thing that might trip you up is that auto detection through nixos-generate-config doesn't work completely with LUKS + ZFS
<andi->
kraem: I do not boot off it tho.. I just have the data disks with ZFS
<srhb>
kraem: But it amounts to fixing up the luks stuff manually if I'm not misremembering.
<gchristensen>
joepie91[m]: I find that to be an extraordinary claim, can you help me by providing extraordinary evidence? :P
<joepie91[m]>
gchristensen: which?
<joepie91[m]>
:P
<gchristensen>
"the set of circumstances under which FDE is useful is pretty limited"
<joepie91[m]>
gchristensen: so like, FDE doesn't protect anything on an OS level, because the encryption is transparent. which means it only protects against physical attack vectors, which would be all fine, except when somebody has physical access to the point they can steal a drive, they can probably also steal the entire system and extract the keys from memory while it's running. which means that in practice, FDE is basically
<joepie91[m]>
only useful for a system that is powered off or, at best, that has an automatic unmounting policy when screenlocked for example (but then it's usually not *F*DE anymore)
<joepie91[m]>
this means that it's probably useful for laptops that are powered off, and not much else
<joepie91[m]>
laptops that you are traveling with *
<joepie91[m]>
and maaaaybe for powered-off desktops/laptops in a permanent location, if you are a particularly interesting target
<__monty__>
andi-: I probably wouldn't be as wary if I had a decent backup setup (or any). But I really don't think FDE should be the default for the average consumer. Especially apple's way with the T2 chip.
<joepie91[m]>
there's a few other edge cases where it's useful, but in most cases I've seen, the people who know what FDE is are also the kind of people who have their system running 24/7 and therefore do not really get a benefit from it :)
<gchristensen>
joepie91[m]: I feel having the ability to power off a device and render its data unreadable very important, but that is just a feeling. although, considering "end of life" of the drives and knowing any drive you throw away is unreadable ... also very nice.
<aanderse>
i use a drill to get that feeling when i'm done with a drive
<cransom>
my thought is that if i'm traveling, and i lose my laptop, the main goal is that someone can't open the lid and get at things, and if they want to remove the drive to mount it elsewhere, they won't get anything useful. if the entity that wants my data is opening the case and dumping memory by attaching random pins to the motherboard... can't really protect that one.
<gchristensen>
cransom: that feels right to me
<__monty__>
Only reason I can see to make FDE the default is so interesting targets don't stand out as much : )
<cransom>
random dude picking up a free laptop and do some snooping is far more likely than some kind of state actor wanting my secrets.
<joepie91[m]>
gchristensen: right, unreadability of an EOL drive can be a valid reason
<joepie91[m]>
there's a lower-hassle option for that though, drive destruction services :P
<gchristensen>
FDE is pretty low hassle
<__monty__>
How about a hard to reach server though. Might wanna reboot whenever. It being hard to do uniformly for all my systems is one of the reasons I haven't really considered.
<gchristensen>
I don't use (but maybe should...) FDE for servers in well run datacenters
<samueldr>
hmmm, how should an initrd left unencrypted (to boot and dropbear you) be called; that's not FDE as F is Full, is that MDE? most disk encryption?
<gchristensen>
heh
<samueldr>
(and yeah, you always need a stage at which the cpu can decrypt, most likely the bootloader if you cannot manipulate the firmware)
<joepie91[m]>
cransom: they don't need to attach pins to the motherboard; your laptop almost certainly has DMA-capable ports
<joepie91[m]>
(like, say, a USB port that also happens to suppot thunderbolt)
<samueldr>
good ol' firewire/thunderbolt
<joepie91[m]>
which means that dumping memory is likely actually easier than stealing your HDD :)
<gchristensen>
don't auto-authorize devices, good grief
<cransom>
sure, firewire/et al and you can dump memory contents. it's a specialized attack that if it happens, no amount of encryption is going to help me.
<joepie91[m]>
(and, most importantly, it can be packaged into ready-made dongles)
<samueldr>
cransom: open as needed; my financial documents are in an ecryptfs fuse mountpoint I only open as required
<samueldr>
so, unless I am filing taxes AND getting targetted at the same time, those few documents are probably safe
* cransom
makes note of when to start burgling samueldr.
<joepie91[m]>
cransom: but like I said, you can package this attack into a ready-made dongle. HDD removal is likely *more* specialized than that.
<samueldr>
considering how many mobile devices are beginning to have soldered storage; it's likely t hat HDD removal is not as high priority as compromising other things
<cransom>
url to ready made dongles for dumping memory? i can only reasonably plan to stop info leak via casual theft.
<gchristensen>
cransom: just don't auto-authorize thunderbolt devices and you'll be fine
pie_ has joined #nixos-chat
<pie_>
clever, people should audit nix instead :p
* pie_
vaguely ponders that it would be nice if nix would be less invasive and als if we could finally move the store around
<__monty__>
Less invasive?
<pie_>
maybe that was unwarranted, im just super tired
<pie_>
im running it on debian
drakonis has quit [Ping timeout: 252 seconds]
<cransom>
i'm not sure how it could be any less invasive. you can also use your own store located elsewhere, but you don't get to use the binary cache anymore.
<clever>
cransom: there is also nix-user-chroot and nix-bundle
drakonis has joined #nixos-chat
<pie_>
is there any word on nixcon call for papers or talks or something like that
<infinisil>
Nix is arguably one of the least invasive package managers as it *only* touches /nix
<pie_>
thats not quite true but yeah anything more is bonus points i guess :PP
<samueldr>
pie_: I assume CFP might be close, nixcon preparations started