<adisbladis>
Best airplane view I've head over a desert was the gobi flying over Mongolia
<talyz>
Cool :o
<aanderse>
hey talyz any interest in declarative database configuration PRs from a few months ago we talked about?
<eyJhb>
talyz: where are you presenting? And, I have no clue. It is signal processing, so it isn't my main field
<eyJhb>
Just hope I passed so I can get my bachelors soon
<gchristensen>
very cool, adisbladis :)
<eyJhb>
Cool adisbladis , hope to be flying again soon as well
<eyJhb>
Hoping for Cape Town and Thailand this year
<gchristensen>
I hate it when I realize I left a root terminal open all night, or even worse, in an alternate pane of tmux / screen for an unprivileged user
<__monty__>
Stop suing and start sudoing, or doasing.
<gchristensen>
I do!
<gchristensen>
`sudo -i` ;)
<gchristensen>
maybe I could auto-kill root sessions
<qyliss>
systemd-boot is by far my favourite systemd thing
<gchristensen>
qyliss: tell us more!
<joepie91>
the systemd thing that wasn't :P
<gchristensen>
so I have this server that will boot 3 times and then stop
<ajs124>
what?
<joepie91>
gchristensen: maybe it's booting off one of those floppy disks that you were only allowed to boot N times?
<joepie91>
:P
<gchristensen>
lol
<joepie91>
(yes, that was a real form of DRM back in ye olde days)
<gchristensen>
nah, uefi firmware bugs
<gchristensen>
after a few boots it decides the UEFI shell should be the primary boot option
<ajs124>
Just kexec
<gchristensen>
hehe
<gchristensen>
unfortunately part of the test procedure is «for i in $(seq 1 100); do nixops deploy --force-reboot; done»
<gchristensen>
and this type of server has nearly 100T of disks, I think people would be unhappy to find out it doesn't reboot :P
<DigitalKiwi>
gchristensen: those root sessions are life savers when someone breaks something so bad a new root session can't be started but an existing open one will let you fix it
<gchristensen>
haha I see you've had stressful days too :'D
<__monty__>
Ok, let's agree to keep a secret root session running on a random tty from now on. The canonical random tty being tty4.
<gchristensen>
sgtm
<DigitalKiwi>
__monty__: i see you are one of culture
<__monty__>
Yes, I rate every place I visit a 4, no matter the range of the scale.
<gchristensen>
it fully supports https://www.packet.com/developers/docs/servers/key-features/cpr/ but with the added benefit that "Please note: this feature is not available for on-demand instances. A reserved device is required." is no longer true, on the next NixOS installer, you'll be able to customize storage options for spot and on-demand too.
<talyz>
aanderse: Hi! :) Not really, no. There were a few responses, most were neutral to negative. The aspect some were interested in was users and extensions. There aren't that many comments on the pr at all though, so hard to say..
<talyz>
eyJhb: In Oslo, at the hackerspace Hackeriet :)
<talyz>
eyJhb: Aha, let's hope so, then :)
<gchristensen>
printers :(
<qyliss>
gchristensen: it's just so nice and simple, and does its job well
<qyliss>
I don't use GRUB or systemd-boot now, but systemd-boot would definitely be my preference if I had to choose, and didn't want to do stuff like multi-level menus, or dual boot, etc.
<ajs124>
qyliss: how _do_ you boot? does your firmware just execute your kernel?
<qyliss>
My firmware _is_ a kernel
<gchristensen>
you bringing back lilo?
<qyliss>
I use Heads
<gchristensen>
:D
<qyliss>
Sadly doesn't work too well with NixOS
<qyliss>
It _could_ be fantastic -- better than with any other distro, but needs some work done
<gchristensen>
what sort of work?
<qyliss>
So, Heads tries to parse grub and extlinux config files in Bash
<qyliss>
This doesn't work very well
<gchristensen>
:o
<qyliss>
Especially Grub ones, since Grub is (I think) turing complete
<gchristensen>
abort.gif
<qyliss>
I do a hack where I use the NixOS extlinux boot option, but then symlink that to grub.cfg
<qyliss>
That was the only way I could get it to work because Heads wouldn't look in the right place otherwise
<ajs124>
I had the pleasure of hearing leannart poettering talk about his new boot specificating thing.
<qyliss>
But, if NixOS could just, say, write all the boot options into a directory, that would eliminate the need for parsing on Heads' size
<ajs124>
It seemed relatively sane, compared to grub config. Then again, I already use systemd-boot. Also, I got to ask him some stupid questions, which I always wanted to do :D
<qyliss>
Heads also requires kernels and initrds be signed, which you could do in an activation script
<qyliss>
(Currently I don't actually do that, which means I'm not getting any security benefit of Heads)
<ajs124>
systemd-boot entries are pretty barebones already. parsing them should be trivial.
<qyliss>
So, this could be a lot more robust, but it would need interest on both the Heads and NixOS sides
<qyliss>
ajs124: I'm not convinced that there's any need for a parser at all
<qyliss>
Really you just need a directory for each boot option, with kernel and initrd files inside
<ajs124>
true. I'm wondering why they didn't go that route
<qyliss>
because that's not what grub does, and they want to be compatible with existing distributions
<qyliss>
(Unless you mean why systemd-boot didn't go that route?)
<ajs124>
I meant systemd-boot, yes
<qyliss>
I would also very much like to be able to build Heads with Nix, because right now it builds its own compiler and stuff for reproducible builds, and that's extremely slow.
<qyliss>
People very often think they need config files when they don't
<gchristensen>
ow
<ajs124>
their loader entries only contain title, version, linux, initrd and options
<qyliss>
It inherits that property from coreboot
<qyliss>
And I think pbb is doing some work to build Coreboot with Nix
<ajs124>
yeah, compiling coreboot is always a lot of "fun"
<gchristensen>
my secureboot PR makes each kernel its own signed EFI program iirc, and then systemd-boot is basically just a menu
<qyliss>
ajs124: oh right, yeah, I guess you'd need another file containing kernel command line
<qyliss>
and title
<qyliss>
tbh that does sound easy enough to parse that it might be easier to just get Heads to read that
<qyliss>
I've just been burned by the Grub parser
<emily>
gchristensen: i forget, do the signed systemd-boot bundles contain commandlines?
<gchristensen>
yeah, the efi program has the os-release, cmdline, kernel, and initrd data all embedded (either as paths, or literally embedded -- I don't remember. it definitely uses a lot more disk space than the unsigned version.)
<gchristensen>
that spring might be a bit trickier to remove
<DigitalKiwi>
works pretty well
<DigitalKiwi>
and yeah that one would be annoying
<gchristensen>
I find the springs annoying overall -- during use and during storage, which is why I usually removethem
<DigitalKiwi>
my mini pliars set (there are 6 different kinds) don't have easy to remove springs either
<DigitalKiwi>
the only ones that would be easy to remove I think are my wire strippers...which have a lock and i like the spring lol
<DigitalKiwi>
my arduino is now battery powered!
<__monty__>
I just put mine away open. Not as if closing them saves significant space.
<DigitalKiwi>
i don't have a lot of space where they're stored so every bit counts
<__monty__>
If you store them open you can store them a bit like this <<<<
<eyJhb>
*requires multiple*
* joepie91
leaves them open too
<joepie91>
the strap approach is interesting though
<eyJhb>
Any HTML guys that have a opinion about what HTML tags to use for a list of .... nvm
<eyJhb>
Just a unordered list of errors would do. Unless somebody has a better idea ( joepie91 ?)
<joepie91>
eyJhb: what's the semantic context?
<eyJhb>
I have a simple textarea where the user inputs some yaml. The yaml is then validated (fields etc.), and erros are returned to the user
<joepie91>
eyJhb: then I would suggest a ul/li, potentially nested in the case of structural errors
<eyJhb>
Currently just having a <h2>Errors</h2> with <ul> <li> Error 1 </li> ... </ul>
<joepie91>
eyJhb: UI-wise, I would suggest marking all invalid fields with red styling, if there's more than one field in the form
<joepie91>
I usually go for a bright red border and a very light red background
<DigitalKiwi>
<3 twitter bootstrap
<joepie91>
( very light; saturated enough to distinguish it from other fields at a glance, but definitely also light enough that it doesn't mess with text contrast)
<eyJhb>
I am just going 100% HTML and nothing else
<eyJhb>
That I will leave some someone else if he wants to take on the task :D
<joepie91>
at least give the elements the correct classes then :)
<joepie91>
like a 'failed' class for the invalid form fields
<DigitalKiwi>
my html used to just be white pages and then i started using twitter bootstrap and things looked much better