<sphalerite>
gchristensen: well you don't get an error from that until you use it in a context where the list isn't supposed to contain a function and a value
<makefu>
yeah exactly that, it will just explode at some later phase
<samueldr>
cannot coerce building material to an operating system, at (...)
<gchristensen>
ah right
<makefu>
often times it is something about got function but set was expected
<sphalerite>
gchristensen: you're missing the best bit from the infinite recursion message, "at unknown position"
<gchristensen>
oh man that is true
<gchristensen>
where Nix is just telling you to sod off
<makefu>
comparable to the boot process' "Bailing out, you are on your own. Good Luck."
<sphalerite>
nice
<sphalerite>
what's that from?
<samueldr>
nixos?
<makefu>
every stage2 essentially, not sure what exactly the message creates
<makefu>
maybe just archlinux, not sure
<sphalerite>
ah ok
<sphalerite>
next time I implement something that has to deal with user input, I won't go to any effort to make descriptive error messages, just say "you did something wrong" for all invalid inputs.
<samueldr>
you're too good, you could just return "error"
<gchristensen>
you have stiff competition, though, openssl is pretty good at having useless errors
<andi->
gcc is also a great example... something runs out of disk space.. nonsense error message
<sphalerite>
oh yeah, error messages describing the wrong thing are even better than nondescriptive error messages
<makefu>
"at unknown position"
<andi->
even better would be a random error string for the same error..
<makefu>
this is pretty much the pinnacle of error messages
<sphalerite>
makefu: yes that was the trigger for the discussion of how to make the worst error messages :p
<sphalerite>
andi-: no because at that point it's too obviously satire
<makefu>
yeah, and it seems there are a lot of bad ideas but the reality tops all
<andi->
sphalerite: provide half error messages?
<sphalerite>
Ooooooooh
<sphalerite>
A free-to-play compiler with error messages as a DLC
<sphalerite>
I think it's time for me to go to bed.
<makefu>
good idea
<makefu>
i think we can take every bad idea and just add `at unknown position` just to mock users and developers alike
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 244 seconds]
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 268 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
samrose has quit [Ping timeout: 246 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Read error: Connection reset by peer]
Thra11 has joined #nixos-aarch64
v0|d has quit [Ping timeout: 250 seconds]
zupo_ has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
samueldr has quit [Changing host]
LnL has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
LnL has quit [Changing host]
tilpner has quit [Changing host]
tilpner has joined #nixos-aarch64
gchristensen has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
gchristensen has quit [Changing host]
{^_^} has quit [Changing host]
zupo has quit [Ping timeout: 245 seconds]
Thra11 has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
clever has joined #nixos-aarch64
clever has quit [Changing host]
zupo has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
worldofpeace has quit [Quit: worldofpeace]
orivej has joined #nixos-aarch64
zupo has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
alex_giusi_tiri has joined #nixos-aarch64
<alex_giusi_tiri>
hi :-)
<makefu>
hey!
<alex_giusi_tiri>
I just managed to install nixos on raspberry pi 3b! yay!
<alex_giusi_tiri>
i am just somewhat concerned about the cpu temperature
<samueldr>
is it worse than on other distros? I don't think it would
<alex_giusi_tiri>
i have `stress -c 4` running with `watch -n 1 cat /sys/class/thermal/_thermal_zone0/temp` at 69294
<alex_giusi_tiri>
i tried setting 'arm_freq=600' in config.txt but the difference that i noticed was just how quickly it reached such temperature
<alex_giusi_tiri>
i just saw that it touched 70 and a bit
<alex_giusi_tiri>
i haven't found a way to check the current cpu freq or governor
<samueldr>
I'm not really familiar with other distros on raspberry pi, but nixos has one major difference: it uses the mainline kernel by default instead of relying on the raspberry pi foundation's fork
<alex_giusi_tiri>
as i found that some info online was pointing out; i couldn't find those mentioned system virtual files, as in debian
<alex_giusi_tiri>
that is something that i like
orivej has quit [Ping timeout: 240 seconds]
<makefu>
samueldr: i think i remember seeing a PR which changes the default kernel for raspi, no?
<alex_giusi_tiri>
i guess that explains it
<samueldr>
not the default?
<samueldr>
though, makefu, the linux_rpi package can now be used on aarch64
<makefu>
yeah!
<alex_giusi_tiri>
but shouldn't the config.txt settings take effect?
<samueldr>
I'm not sure :/ I don't have a deep knowledge of the raspberry pi
<alex_giusi_tiri>
i had gentoo installed prior
<samueldr>
I know some settings do work, like avoid_warnings
<alex_giusi_tiri>
and i kind of felt it responded slower on 600mhz than on 1200
<samueldr>
I don't know whether some might be overriden later either by u-boot or linux
<alex_giusi_tiri>
hmm., ok
<samueldr>
though, I don't know if slowing the CPU really helps with temps :/
<alex_giusi_tiri>
on my laptop it does
<samueldr>
it may as well heat up depending why and how it heats up, and you said it took more time
<alex_giusi_tiri>
yeah...
<samueldr>
though your laptop probably has active cooling, and good thermals (e.g. heat pipes)
<samueldr>
are your chips bare or have you added heatsinks?
<alex_giusi_tiri>
with
<samueldr>
hm
<alex_giusi_tiri>
but when running gentoo, it wasn't warm at all
<alex_giusi_tiri>
at 600
<alex_giusi_tiri>
at 1200, yes
<alex_giusi_tiri>
but now, even with 600 it is still warm, when running stress
<alex_giusi_tiri>
...if i recall correctly
<samueldr>
I'd guess gentoo wasn't using u-boot, right?
<alex_giusi_tiri>
no
<samueldr>
maybe there's something to look at there: does u-boot somehow affect this?
<alex_giusi_tiri>
i guess it's possible
<samueldr>
a complete unknown to me :/
<alex_giusi_tiri>
btw, should config.txt be placed in the fat psrtition, or in the rootfs ext4 one? i disabled the fat boot partition, following the instructions
<samueldr>
fat
<samueldr>
u-boot is still there, and the raspberry pi still uses that partition to boot from
<samueldr>
AFAIK, the onboard firmware only deals with FAT
<samueldr>
(but luckily, the partition can be anywhere, not forced to be the first)
<alex_giusi_tiri>
i now have it placed in both, just in case, although it seems it still doesn't seem to work
zupo_ has quit [Ping timeout: 268 seconds]
<alex_giusi_tiri>
ok thanks. i wasn't sure about that. i was only speculating
<samueldr>
no worries, it was a good question
<alex_giusi_tiri>
i was considering the possibility of the ext4 partition might have become the 'primary' and that the fat one was not used anymore
<alex_giusi_tiri>
so then, is the boot flag used by uboot, only?
<samueldr>
exactly
<alex_giusi_tiri>
oh
<samueldr>
u-boot uses it to know on which partition to look for its distro agnostic configs
<samueldr>
while I don't know specifics about the usage of the raspberry pi, I think I have the whole boot process cornered ;)
<samueldr>
mine boots from UEFI even! (no u-boot in sight, Tianocore loads grub, grub loads nixos as you would on x86_64)
<alex_giusi_tiri>
that's cool
<samueldr>
and before you ask: no real advantage AFAIK, I use it to test and dogfood the UEFI on AArch64 code in nixos
<alex_giusi_tiri>
but what i like about pis is that you can't brick the device, because there is no bios/efi nir any integrated chip holding alike fw that gets exposed to, eg, malware, or even user mistakes; as far as i understood
<samueldr>
though it kinda hurts to rely on SD cards :/
<samueldr>
oh, one thing booting using UEFI allows is that the sd card in my rpi3b only has the uefi firmware, it loads from a USB hard disk
<alex_giusi_tiri>
i prefer it that way; i would say that i's mire modular like that
<samueldr>
one can also boot from USB by blowing some fuses as a setting on the raspberry pi
<samueldr>
SD cards are not so reliable (but that's possibly overstated and less than expected), but often slow... frigidly slow :(
<makefu>
samueldr: i can confirm raspis eating sdcards like corn flakes
<alex_giusi_tiri>
i once searched for "overheating sd card" just by curiosity, and i was surprised to find many people experiencing cards catching on fire and/or exploding, with casualties - burns etc
<alex_giusi_tiri>
shocking
<alex_giusi_tiri>
do you mean they overuse/misuse/abuse then until they fail?
<samueldr>
I don't have hard evidence, but it's a commonly touted thing about raspberry pi and SD cards, that you'll eventually have issues with it
<samueldr>
I guess it's when you're actually using the damn thing :D
<alex_giusi_tiri>
i don't know, but i think pis could boot directly from a fat partituon on an external usb drive, without any sd card present
<samueldr>
yes and no, it can, but it may fail on some disks
<samueldr>
and generally will on "hard drive" types, so you're kinda left with flash storage
<samueldr>
(which may or may not be an issue)
<alex_giusi_tiri>
unfortunately, `the leading cause of obesity is eating food`
<samueldr>
and you have to "burn some fuses", which disables some GPIO pins :/
<samueldr>
>> We haven’t enabled this boot mode by default, because we first wanted to check that it worked as expected. The boot modes are enabled in One-Time Programmable (OTP) memory, so you have to enable the boot mode on your Pi 3 first. This is done using a config.txt parameter.
<samueldr>
well designed :/
<makefu>
"The Raspberry Pi 3+ is able to boot from USB without any changes"
<makefu>
sounds nice
<samueldr>
oh, good
<samueldr>
(last time I read that page I think the 3+ wasn't a thing)
<samueldr>
though yeah, having Tianocore on the µSD allows using spnning rust external hard drives which are too slow otherwise
<alex_giusi_tiri>
does uboot necessarily need a bootable flag to be set?
<alex_giusi_tiri>
i a thinking about things like booting from gpt/raid
<samueldr>
it does not *require* it, though here it ensures it won't see its old files
<samueldr>
(and here it's not *u-boot* using it, but the generic distro configuration concept)
<alex_giusi_tiri>
what do you mean it not seeing its old files? :-?
<samueldr>
oh, it looks for either /extlinux/extlinux.conf or /boot/extlinux/extlinux.conf, and I think the instructions don't say to remove them from the FAT partition