IRC logs

Chat logs of #funderscore for Sunday, 2024-10-13

00:52 *** Quits: Larsenv/h (~Larsenv@141.148.22.56) (Client Quit)

00:53 *** Joins: Larsenv/h (~Larsenv@141.148.22.56)

00:53 *** moist/h sets mode: +v Larsenv/h

01:26 <rx> f_/h: those should use unix domain sockets

02:00 *** Quits: tweezers (~tweezers@103.108.229.68) (Connection closed)

02:00 *** Joins: tweezers (~tweezers@103.108.229.68)

03:08 <runxiyu> how do i check a funderscore pointer?

03:13 <longnoserob|m/h> by using a Goverscore?

03:13 <longnoserob|m/h> SCNR

05:21 *** Quits: tweezers (~tweezers@103.108.229.68) (The TLS connection was non-properly terminated.)

05:21 *** Joins: tweezers (~tweezers@103.108.229.68)

08:22 *** Joins: exxxxkc/h (~exxxxkc@disroot.org)

08:22 *** moist/h sets mode: +v exxxxkc/h

09:39 <f_/h> I was a hoover max extract pressure pro model 60

09:39 <f_/h> Now I apparently am a pointer

09:48 <hax[xor]> you're a pointer to the local hoover max extract pressure pro model 60 dealer

09:50 <f_/h> hax[xor]: Understandable, have a great day.

10:43 *** Joins: funderscore|win8 (~fundersco@webirc/funderscorewin8)

10:43 <funderscore|win8> hi

10:43 *** funderscore|win8 is now known as f_|Windows8

10:43 <f_|Windows8> Spun up my windows 8.1

10:43 <f_|Windows8> I have to saz

10:43 <f_|Windows8> say

10:44 <f_|Windows8> Im glad Im not using this OS daily

10:44 <f_|Windows8> this vm has been 'debloated'

10:45 <f_|Windows8> but I still dont trust it

10:45 <f_|Windows8> also the keyboard layout is wrong....

10:45 <f_|Windows8> anyway, just wanted to say hi

10:45 *** Quits: f_|Windows8 (~fundersco@webirc/funderscorewin8) (Connection closed)

10:46 <f_> There's not much in that VM..

10:46 <f_> Just a few Amlogic flashing tools.

10:46 <f_> Some web browsers

10:47 <f_> And that's mostly about it.

11:11 <longnoserob_> and it works

11:13 <f_> longnoserob_: it's laggy

11:13 <f_> Last time I used windows as main OS it was buggy

11:14 <f_> And I think I might've had malware running

11:14 <f_> well

11:14 <f_> windows is malware

12:43 *** Quits: f_[x] (f_[x]@195-15-242-30.dc3-a.pub1.etik-cloud.com) (Client exited)

13:59 <f_/h> morning

13:59 <f_/h> fireonlive++

13:59 -eggdrop/h- [karma] 'fireonlive' now has 575 karma!

14:06 *** Joins: f_[m]/h (~fundersco@fd1a:6295:5133::2099)

14:07 <f_[m]/h> a

14:07 *** f_[m]/h was kicked by f_/h (f_[m])

14:13 *** Joins: franzopow|m/h (~franzopow@fd1a:6295:5133::f738)

14:13 <franzopow|m/h> hi

14:13 <f_/h> morning

14:13 <longnoserob|m/h> evening

14:14 <f_/h> longnoserob|m: how are you today?

14:14 <longnoserob|m/h> good, got my pc working and setup again.. and dayoff tomorrow

14:14 <f_/h> oooh nice!

14:15 <f_/h> were you able to recover your data?

14:15 <f_/h> I know you had backups but still

14:19 <longnoserob|m/h> not all data unfortunately, but ill survive

14:20 <longnoserob|m/h> i had and have /home on a second disk and this disk failed hw-wise..

14:20 <longnoserob|m/h> some PCB and 3d printing stuff is lost, but it is survivable..

14:21 <f_/h> oh :/

14:22 <longnoserob|m/h> need to improve my setup anyway.. this i7-4770 needs an upgrade sometime soon

14:23 <f_/h> you're on a 4th gen i7?

14:23 <longnoserob|m/h> anyone ever setup andrewfs or ceph for home use?

14:23 <f_/h> I'm still on 2nd gen :^)

14:24 <longnoserob|m/h> oh ok..

14:25 <longnoserob|m/h> building kernels must suck

14:29 <f_/h> nah.

14:29 <f_/h> It's ok-ish.

14:29 <f_/h> About an hour for the Amlogic pmOS kernel IIRC

14:30 <longnoserob|m/h> yeah have about 45min for a mainline kernel

14:31 <longnoserob|m/h> comparision, on the armv7 tegra-t30 tf201 its about 3h

14:31 <longnoserob|m/h> haven tested a full kernel build on my google-krane yet

14:44 <Noisybeep> longnoserob|m/h: install libreboot

14:45 <Noisybeep> anything newer than 4th gen would be a downgrade in freedom

14:49 <f_/h> Noisybeep: x86 is not very freedom-respecting anyway

14:50 <Noisybeep> f_/h: some are better than others

14:51 <f_/h> Noisybeep: Of course, but that doesn't say much regarding overall freedom you get.

14:51 <Noisybeep> nothing newer than haswell has free raminit currently

14:51 * runxiyu looks at their apple silicon machine

14:51 <Noisybeep> what blobs does apple silicon require?

14:52 <Noisybeep> I'm sure it's full of them, I just don't know what exactly

14:55 <runxiyu> https://github-wiki-see.page/m/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon

14:55 <runxiyu> (i prefer github-wiki-see.page to reading the actual wiki on github.com)

14:58 <runxiyu> > In the future, we intend to allow for the stage 2 chainload to maintain a secureboot chain, via signed m1n1 images. For this reason, the current chainloading code to load stage 2 from FAT32 is written in Rust, as it is part of the secureboot attack surface. This essentially eliminates the possibility of exploitable memory-safety bugs in that part of the code. The signature

14:58 <runxiyu> verification will also be implemented in Rust for this reason. The public key for verification will be configured at stage 1 installation time, and will be that of the entity expected to provide stage 2 builds for that particular OS container.

14:58 <runxiyu> i mean

14:58 <runxiyu> sure

14:58 <runxiyu> but a language doens't completely solve it

14:58 <runxiyu> but fair

14:58 <runxiyu> hax[xor]: ^

15:01 <Noisybeep> > Brick recovery / total system flash (DFU) requires phoning home

15:01 <Noisybeep> why?

15:01 <Noisybeep> > You do have to click through Apple's EULA in order to use the machines at all.

15:01 <Noisybeep> unacceptable

15:03 <f_/h> Noisybeep I'm quite sure Haswell has free raminit

15:04 <Noisybeep> f_/h: yes, that's what I said

15:04 <Noisybeep> "nothing newer than haswell has free raminit currently"

15:04 <Noisybeep> haswell is not newer than haswell

15:04 <f_/h> ah misread.

15:05 <katia/h> cia

15:05 <katia/h> o

15:05 <katia/h> !lista

15:06 <f_/h> [lista] no

15:07 <hax[xor]> runxiyu: lol at "yay a rewrite into rust will solve potential, but enirely avoidable, problems in this commonly-used software!"

15:08 <hax[xor]> because memory safety is definitely the main issue concern in signature validation

15:08 <hax[xor]> and definitely going to have a bunch of those bugs in well-known-and-used-and-tested signature validation software that's aleady been written

15:09 <runxiyu> yeah, i don't buy the argument

15:09 <runxiyu> however, memory safety is a big issue in current USB stacks

15:09 <runxiyu> and they're making the same argument for USB

15:09 <hax[xor]> true, usb isn't very sane

15:09 <runxiyu> yeah

15:09 <hax[xor]> "fix usb not the language" :P

15:10 <runxiyu> hax[xor]: tbf i find kernel rust to be significantly saner than how people write userspace rust

15:10 <runxiyu> no rust-insane-package-management

15:10 <runxiyu> which is my main compliant

15:10 <runxiyu> my second biggest complaint is the standard style using 4 spaces

15:10 <runxiyu> my third biggest complaint is the advertising

15:11 <hax[xor]> runxiyu: do you find the same for kernel C vs how people write userspace C?

15:11 <hax[xor]> sure thise particular complaints don't apply to C, but my point applies to the other aspects

15:12 <hax[xor]> kernel usually forces some decency to the usage

15:13 <runxiyu> hax[xor]: c doesn't suffer from rust's insanities

15:13 <runxiyu> well, i don't really know kernel c, but at least error handling got to be saner... right?

15:14 <hax[xor]> overal quality is forced sane, no reliance on "likely won't happen so who cares? (mainly regarding resource exhaustion or other such situations)", etc

15:15 <hax[xor]> and yeah I don't think the kernel would use errno

15:16 <f_> linux does use errno internally.

15:16 <f_> Well

15:17 <hax[xor]> to what degree?

15:17 <f_> functions return errno values

15:17 <hax[xor]> that's fine

15:17 <hax[xor]> that's not the absurdity of errno

15:17 <f_> see errno.h in its tree

15:17 <hax[xor]> the problem is errno itself, not the values used behind it

15:18 <f_> functions setting errno you mean?

15:18 <hax[xor]> reading or writing to errno

15:19 <f_> I mean

15:19 <f_> just return whatever..

15:19 <hax[xor]> returning values and using macros starting with 'E' is not errno usage.

15:20 <hax[xor]> (and also perfectly fine)

15:23 *** Joins: emorrp1|m/h (~emorrp1fr@fd1a:6295:5133::f739)

15:23 <f_/h> o.O

15:24 <f_/h> will push some stuff, let's see if vdoGit still works

15:24 <f_/h> (the bot, I mean)

15:25 <hax[xor]> runxiyu: and yeah C isn't as bad to begin with, my point was merely that there's still the factors behind it

15:25 <vdoGit/h> [u-boot-kii-pro] wip/spl@bee7098022: Ferass El Hafidi: "arm: meson: dram-gx: a bit of cleanup in meson_dram_pll_init()"

15:25 <f_/h> nice.

15:26 <f_/h> runxiyu ^ There's your git bot.

15:26 <f_/h> just write a post-receive hook that sends stuff to IRC.

15:26 <Noisybeep> what's wrong with rust's error handling?

15:26 <Noisybeep> it does not use exceptions

15:26 <runxiyu> source?

15:27 <hax[xor]> rust has exceptions-but-we-renamed-them-and-made-them-worse.

15:27 * f_/h does not know Rust.

15:27 <Noisybeep> actually it does: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html, but I think rust code usually uses return values

15:27 <f_/h> runxiyu: reading git's hook docs and running a sircbot shall be enough

15:28 <f_/h> but if you want I can send what I have.

15:28 <hax[xor]> Noisybeep: secondly, how often does your normal rust library code decide to panic when it runs out of memory or such?

15:28 <f_/h> runxiyu: sircbot being what powers alpinelinux's algitbot IRC bot: https://git-old.alpinelinux.org/hosted/sircbot/

15:28 <hax[xor]> interpret "panic" to be anything other than "return peacefully as people expect non-exception-including code to work"

15:28 <runxiyu> hax[xor]: the stdlib does not, afaik

15:29 <runxiyu> but i have -1 bits of memory myself

15:29 <f_/h> it just doesn't support TLS.. so I have stunnel running as well (because I want TLS and Hackint IRC is TLS-only)

15:29 <f_/h> Also.

15:29 <f_/h> welcome franzopow|m emorrp1|m

15:30 <f_/h> !flags franzopow|m*!*@* +V

15:30 -moist/h- f_ (funderscore) set flags +V on franzopow|m*!*@*

15:30 <f_/h> !flags emorrp1|m*!*@* +V

15:30 -moist/h- f_ (funderscore) set flags +V on emorrp1|m*!*@*

15:30 <f_/h> !sync

15:30 -moist/h- f_ (funderscore) used SYNC.

15:30 *** moist/h sets mode: -v+vv f_[z]/h franzopow|m/h emorrp1|m/h

15:30 *** f_/h sets mode: +v f_[z]/h

15:30 <hax[xor]> https://users.rust-lang.org/t/handling-memory-exhaustion-state-of-the-art/87375 hmmmmmmm

15:33 <hax[xor]> yay memory safety! btw memory issues result in an abort(), crashing your plane.

15:33 <Elestren> yay!

15:36 <hax[xor]> runxiyu, Noisybeep: ^

15:40 *** Joins: Rampoina|m/h (~rampoinam@fd1a:6295:5133::f73a)

15:41 <Rampoina|m/h> hi

15:42 <f_/h> oh hi Rampoina|m you too?

15:42 <f_/h> !flags Rampoina|m*!*@* +V

15:42 -moist/h- f_ (funderscore) set flags +V on Rampoina|m*!*@*

15:42 <f_/h> !sync

15:42 -moist/h- f_ (funderscore) used SYNC.

15:42 *** moist/h sets mode: -v+v f_[z]/h Rampoina|m/h

15:42 <f_/h> Why are y'all joining this chan

15:42 <f_/h> 🤣

15:49 *** f_/h sets mode: +v f_[z]/h

15:49 *** f_/h sets mode: +v vdoGit/h

15:50 <Rampoina|m/h> f_ you linked it as an example lol I was just checking if it works

15:50 <f_/h> Rampoina|m: right

15:50 <f_/h> Well from what I can tell it works for matrix.org users

15:50 <f_/h> but not for others

15:50 <Rampoina|m/h> history doesn't load for me either

15:50 <f_/h> At least nicklist doesn't load for me, and things like that

15:50 <f_/h> Rampoina|m: wait history is loading for you?

15:51 <f_/h> The room is set to not send history upon join I think

15:51 <f_/h> so why does it try to fetch history anyway?

15:51 <Rampoina|m/h> no, I said it doesn't, it's a neverending spinner

15:52 *** Joins: f_[m]/h (~fundersco@fd1a:6295:5133::2099)

15:52 <f_/h> that's what I mean

15:52 <f_[m]/h> neverending spinner on mostly everything

15:52 <f_[m]/h> and yes it is set to not send history upon join

15:52 *** Parts: f_[m]/h (~fundersco@fd1a:6295:5133::2099) ()

15:52 <Rampoina|m/h> nick list works here

15:53 <f_/h> Does not for me

15:53 <f_/h> and I don't maintain the matrix-side

15:54 <f_/h> (it's just hackint's matrix bridge portal thing)

15:57 <Rampoina|m/h> ¯\_(ツ)_/¯

15:58 <Rampoina|m/h> just one more data point

15:58 <emorrp1|m/h> wfm

15:58 <Rampoina|m/h> fwiw it also loaded in like 2 seconds without sliding sync

15:58 <f_/h> It loaded in like 2 seconds because there are matrix.org users in already, Rampoina|m.

16:00 <f_/h> emorrp1|m: wdym?

16:00 <runxiyu> hax[xor]: https://drewdevault.com/2022/05/12/Supply-chain-when-will-we-learn.html

16:00 <Rampoina|m/h> f_ wfm -> works for me

16:01 <f_/h> ok

16:02 <f_/h> so it might as well be the homeserver I use then

16:02 <f_/h> franzopow|m, Rampoina|m, emorrp1|m Thanks for testing

16:02 <Danct12/h> i move like a moth or a butterfly

16:03 <Danct12/h> craving a change in the wind

16:04 <f_/h> o/ Danct12

16:04 <hax[xor]> runxiyu: lol interesting

16:04 <Danct12/h> hi f_

16:04 <f_/h> How are things going?

16:04 <Danct12/h> fine

16:05 <Danct12/h> still grr while working on my mainline project

16:05 <Danct12/h> anyway do you know that no one can leave once they merge

16:05 <runxiyu> hax[xor]: Go be like: no central repo at all

16:05 <f_/h> thanks for the tip

16:05 <hax[xor]> runxiyu: yeah that's even more fun

16:06 <runxiyu> though go.mod lists all packages that a module needs

16:06 <runxiyu> so it's not like it's the worst thing ever

16:06 <hax[xor]> runxiyu: recursively, though?

16:06 <Danct12/h> i hope you enjoy the tip

16:06 <hax[xor]> recursive dependencies sounds like all kinds of fun when someone updates something

16:06 <Danct12/h> anyway better off dead than flying where i shouldnt be

16:07 <runxiyu> yes, recursively

16:07 <runxiyu> hax[xor]: also, note that go code is statically linked, which of course has issues, but it makes package managing a slightly different job

16:07 <hax[xor]> not too bad then, just annoying since you'll have to change things any time such a dependency changes... helps make you avoid having a million dependencies at least

16:08 <hax[xor]> well yeah there's that, but all the real problems still present

16:08 <runxiyu> go mod tidy does it automatically or something

16:09 <runxiyu> i usually do a go get -t (for updates) and then go build, so i can make sure there aren't new dependencies

16:09 <hax[xor]> -> runxiyu likes compiling external code of unmanaged sources without reading it?

16:10 <runxiyu> and review go.mod with a diff, before go build

16:27 <runxiyu> “By cancelling, I acknowledge: HP Instant Ink subscription cartridges will no longer work after my final billing cycle ends, even if they are already installed in my printer.”

16:27 <hax[xor]> HP++

16:27 -eggdrop/h- [karma] '<&hax[xor]/rx> HP' now has 1 karma!

16:27 <hax[xor]> HP--

16:27 -eggdrop/h- [karma] '<&hax[xor]/rx> HP' now has 0 karma!

16:27 *** Parts: Rampoina|m/h (~rampoinam@fd1a:6295:5133::f73a) ()

16:32 <Noisybeep> printers are why RMS started GNU

16:33 <Noisybeep> do we have a fully free printer yet?

16:33 <f_/h> HP--

16:33 -eggdrop/h- [karma] 'HP' now has -1 karma!

16:33 <Noisybeep> HP--

16:33 -eggdrop/h- [karma] '<+Noisybeep/rx> HP' now has -1 karma!

16:33 <f_/h> <+Noisybeep/rx> HP++

16:33 -eggdrop/h- [karma] '<+Noisybeep/rx> HP' now has 0 karma!

16:33 <Noisybeep> broken bot

16:33 <f_/h> HP--

16:33 -eggdrop/h- [karma] 'HP' now has -2 karma!

16:34 <f_/h> Noisybeep: broken relaybot you mean

16:34 *** Quits: tweezers (~tweezers@103.108.229.68) (Ping timeout: 240 seconds)

16:35 <hax[xor]> yeah, I'm sure there's no patents left on the printing press that haven't already expired, and due to having no software, there's no software freedom issues

16:35 <hax[xor]> so, yes, there's a fully free printer :P

16:54 *** Joins: tweezers (~tweezers@103.108.229.68)

17:00 <runxiyu> i once cut a stamp out of an eraser to fake "homework validated" stamps

17:05 <f_/h> runxiyu Why™

17:05 <runxiyu> yes

17:05 *** Parts: exxxxkc/h (~exxxxkc@disroot.org) (Disconnected: unexpected eof while reading)

17:07 <f_/h> yes

17:07 -moist/h- f_ (funderscore) disabled the VERBOSE flag