💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2022-11-30.txt captured on 2023-01-29 at 03:44:03.
-=-=-=-=-=-=-
[2022-11-30T05:13:32Z] <testuser[m]> Probably much faster to write it in awk
[2022-11-30T05:13:42Z] <testuser[m]> Hi
[2022-11-30T05:19:48Z] <nullcoder> Hi
[2022-11-30T06:06:04Z] <wael[m]> Hi
[2022-11-30T06:39:25Z] <virutalmachineus> <illiliti> "https://github.com/dylanaraps/..." <- I just read sh bible and it change my life.
[2022-11-30T07:09:56Z] <wael[m]> illiliti: phoebos: phoebo's snippet ran 1% faster
[2022-11-30T07:10:28Z] <wael[m]> and then runs 5 times faster in some cases
[2022-11-30T07:11:18Z] <testuser[m]> Fake
[2022-11-30T07:11:47Z] <wael[m]> find ~/media/funny | longest-illiliti
[2022-11-30T07:11:52Z] <wael[m]> https://termbin.com/q5kr
[2022-11-30T07:12:02Z] <wael[m]> ignore that first mesage
[2022-11-30T07:12:06Z] <testuser[m]> wait does $(( do string comparison lol
[2022-11-30T07:12:25Z] <wael[m]> illiliti is using trentary or whatever it was called
[2022-11-30T07:12:36Z] <wael[m]> longest=$((len > longest ? len : longest))
[2022-11-30T07:16:05Z] <wael[m]> non-standard wc -L can do (on a stdin thats 491856 lines long) 480ms, while the shell will be 100000000% slower at 25 seonds
[2022-11-30T07:16:10Z] <wael[m]> i think ill stick to wc -L
[2022-11-30T07:17:05Z] <testuser[m]> Shell is slow as shit
[2022-11-30T07:17:22Z] <testuser[m]> No point in doing pure sh impl of anything unless the command to use is non portable
[2022-11-30T07:17:28Z] <testuser[m]> -L is non standard i think
[2022-11-30T07:17:32Z] <testuser[m]> Just write it in Awk
[2022-11-30T07:17:41Z] <wael[m]> i do not know awk testuser
[2022-11-30T07:17:59Z] <wael[m]> there is 'length > max_length { max_length = length; longest_line = $0 }
[2022-11-30T07:17:59Z] <wael[m]> END { print longest_line }
[2022-11-30T07:19:02Z] <wael[m]> which is about 20ms slower
[2022-11-30T08:29:29Z] <wael[m]> why is kiss extracting a tarball incorrectly
[2022-11-30T08:29:35Z] <wael[m]> https://github.com/hyprwm/Hyprland/releases/download/v0.18.0beta/source-v0.18.0beta.tar.gz
[2022-11-30T08:29:47Z] <wael[m]> kiss fetching this tarball makes it only extract the src
[2022-11-30T08:29:50Z] <wael[m]> aka src/ directory
[2022-11-30T08:30:04Z] <wael[m]> but extracting with normal means gives the real result
[2022-11-30T08:31:54Z] <wael[m]> decompress() with normal means also gives the real result
[2022-11-30T08:32:25Z] <wael[m]> wtf is going on here
[2022-11-30T08:49:32Z] <wael[m]> testuser: can you recreate
[2022-11-30T08:49:53Z] <wael[m]> with that tarball and meson setup build should not error
[2022-11-30T08:50:08Z] <testuser[m]> wael[m]: That's a personal question
[2022-11-30T08:50:18Z] <wael[m]> ok hmmmmmmmm
[2022-11-30T08:50:20Z] <wael[m]> sh -x time
[2022-11-30T08:51:01Z] <wael[m]> yeah this is literally by design
[2022-11-30T08:51:13Z] <wael[m]> kiss assumes all tarballs have 1 root directory inside them
[2022-11-30T08:51:17Z] <wael[m]> and in this case the tarball does not have a root directory
[2022-11-30T08:51:24Z] <wael[m]> all the files are in the top level
[2022-11-30T08:52:43Z] <testuser[m]> Pretty sure this was fixed
[2022-11-30T08:52:45Z] <testuser[m]> Weird
[2022-11-30T08:52:47Z] <testuser[m]> I'll check
[2022-11-30T08:53:03Z] <wael[m]> kiss 5.6.4
[2022-11-30T08:54:35Z] <wael[m]> yeah looks like it wasn't fixed
[2022-11-30T09:02:13Z] <testuser[m]> I had the issue with chroma
[2022-11-30T09:02:20Z] <testuser[m]> Binary Randall
[2022-11-30T09:02:23Z] <testuser[m]> Tarball
[2022-11-30T09:03:08Z] <wael[m]> wen fix
[2022-11-30T09:03:17Z] <testuser[m]> never
[2022-11-30T09:03:40Z] <wael[m]> ok i will use
[2022-11-30T09:03:43Z] <wael[m]> 10 thousand bandwidth
[2022-11-30T09:03:48Z] <wael[m]> because of hyprland subproject
[2022-11-30T09:48:50Z] <phoebos> kiss only extracts directories in the top level
[2022-11-30T09:49:19Z] <phoebos> you need to ask the project to fix their tarball
[2022-11-30T09:49:56Z] <testuser[m]> how is it not a kiss bug tho
[2022-11-30T09:50:01Z] <wael[m]> phoebos: which is what i did
[2022-11-30T09:50:21Z] <wael[m]> but still this is sorta an inconvenience because kiss just doesnt check
[2022-11-30T09:52:36Z] <virutalmachineus> can we make to the switch to rust and call it riss?
[2022-11-30T09:53:23Z] <virutalmachineus> s/to//
[2022-11-30T10:02:20Z] <phoebos> because tarballs conventionally have everything under a dir which has the name of the project or something
[2022-11-30T10:03:07Z] <wael[m]> :thumbs_up:
[2022-11-30T10:03:25Z] <phoebos> tarballs with everything in the top are considered unfriendly
[2022-11-30T10:04:58Z] <phoebos> perhaps kiss could check if there's just one directory in the top level, then go into it, otherwise extract the top level?
[2022-11-30T10:05:34Z] <testuser[m]> ye
[2022-11-30T12:16:16Z] <wael[m]> holy shit hyprland's meson and makefile shit is so fucking messy
[2022-11-30T12:41:49Z] <testuser[m]> hmm hotplug doesnt work with pipewire
[2022-11-30T12:56:43Z] <testuser[m]> illiliti: any clues for debugging?
[2022-11-30T12:56:55Z] <testuser[m]> it doesnt detect my mic unless i restart the service
[2022-11-30T14:20:51Z] <illiliti> did it work before?
[2022-11-30T14:24:51Z] <midfavila> testuser[m]: shell is good for prototyping or commands that won't be used often, or that would be too cumbersome to write in C
[2022-11-30T14:25:04Z] <midfavila> also, update on fetch, feature parity with hurl has just about been reached
[2022-11-30T14:25:12Z] <midfavila> supports HTTP, TLS and Gopher atm
[2022-11-30T14:25:19Z] <midfavila> in 1/4 the lines of C and 1/2 the binary size :D
[2022-11-30T14:25:41Z] <midfavila> a lot of the former is redundant though, I need to write a couple of abstraction functions
[2022-11-30T14:25:53Z] <midfavila> HTTP response header stripping over TLS is also kind of buggy
[2022-11-30T14:26:26Z] <midfavila> but otherwise I've been using it as my primary file transfer utility over the past few days and there don't seem to be many implementation errors aside from what was already mentioned
[2022-11-30T14:27:04Z] <phoebos> :D do push it to your git server
[2022-11-30T14:28:25Z] <midfavila> will uwu
[2022-11-30T14:28:35Z] <midfavila> main is still kinda crappy, but it's also still beta-quality, so, meh
[2022-11-30T14:28:57Z] <illiliti> btw fetch is a terrible name
[2022-11-30T14:29:05Z] <midfavila> it's a great name
[2022-11-30T14:29:10Z] <midfavila> illiliti is a terrible name
[2022-11-30T14:29:11Z] <midfavila> >:c
[2022-11-30T14:29:14Z] <illiliti> there's already fetch available
[2022-11-30T14:29:16Z] <testuser[m]> illiliti: never tried it before
[2022-11-30T14:29:21Z] <testuser[m]> only once few months back
[2022-11-30T14:29:24Z] <testuser[m]> weeks*
[2022-11-30T14:29:25Z] <midfavila> yeah I saw it the other day
[2022-11-30T14:29:27Z] <testuser[m]> didnt work then either
[2022-11-30T14:29:29Z] <midfavila> a clojure library or whatever
[2022-11-30T14:29:31Z] <midfavila> idc about it
[2022-11-30T14:29:35Z] <illiliti> https://www.freebsd.org/cgi/man.cgi?fetch
[2022-11-30T14:29:54Z] <illiliti> consider taking a different name before it's too late
[2022-11-30T14:30:02Z] <midfavila> that's lame
[2022-11-30T14:30:08Z] <midfavila> i wanted a fetch library of my own
[2022-11-30T14:30:18Z] <midfavila> thesaurus time
[2022-11-30T14:30:23Z] <illiliti> libfetch already exists too
[2022-11-30T14:30:27Z] <midfavila> yeah i saw
[2022-11-30T14:30:29Z] <midfavila> in the manpage
[2022-11-30T14:31:31Z] <midfavila> apportate it is
[2022-11-30T14:36:49Z] <midfavila> https://git.sdf.org/midfavila/apportate
[2022-11-30T14:37:00Z] <midfavila> as usual, no claims about quality
[2022-11-30T14:40:14Z] <midfavila> oh but the makefile works this time so that's good i guess
[2022-11-30T14:47:49Z] <illiliti> buflen must be size_t
[2022-11-30T14:47:57Z] <illiliti> actually any *len must be size_t by convention
[2022-11-30T14:48:34Z] <illiliti> malloc+memset could be replaced with calloc
[2022-11-30T14:48:56Z] <midfavila> why? is size_t a more opaque type?
[2022-11-30T14:49:34Z] <midfavila> the calloc thing, fair enough. i don't use it very often so i keep forgetting it exists
[2022-11-30T14:49:54Z] <illiliti> because that's what malloc accept
[2022-11-30T14:50:28Z] <illiliti> using int you're imposing non-portable limitations
[2022-11-30T14:51:33Z] <illiliti> if(!strcmp("http", urip->proto)
[2022-11-30T14:51:52Z] <midfavila> fair enough i suppose, although none of gcc, tcc, or splint give me errors
[2022-11-30T14:52:03Z] <illiliti> i would not do this with strcmp
[2022-11-30T14:52:21Z] <illiliti> strcmp return value is int!
[2022-11-30T14:52:25Z] <illiliti> it isn't bool
[2022-11-30T14:52:38Z] <midfavila> bools and ints are functionally equivalent in C
[2022-11-30T14:52:50Z] <illiliti> !strcmp is actually confusing
[2022-11-30T14:52:58Z] <midfavila> not really
[2022-11-30T14:53:00Z] <illiliti> strcmp() == 0 is better
[2022-11-30T14:53:21Z] <illiliti> it makes things explicit
[2022-11-30T14:53:26Z] <illiliti> do not abuse C pls
[2022-11-30T14:54:07Z] <midfavila> i'm not abusing C
[2022-11-30T14:54:18Z] <midfavila> bools are literally a subtype of ints
[2022-11-30T14:55:00Z] <illiliti> you are missing my point
[2022-11-30T14:55:43Z] <midfavila> no, I get your point, I just disagree with it in this context
[2022-11-30T14:56:04Z] <midfavila> your other complaints were valid, but I'm not going to use strcmp() == 0 instead of !strcmp
[2022-11-30T14:56:06Z] <illiliti> it doesn't matter that bools are interchangeable with ints
[2022-11-30T14:56:16Z] <illiliti> in this case
[2022-11-30T14:56:25Z] <midfavila> the only time legibility would be impacted by that would be if you've never read the strcmp manpage
[2022-11-30T14:58:28Z] <illiliti> ok you want to obfuscate you code and make it more confusing, do it
[2022-11-30T15:01:22Z] <illiliti> oh it's not limited to strcmp
[2022-11-30T15:01:30Z] <illiliti> you are doing it everywhere
[2022-11-30T15:01:40Z] <illiliti> if(connect(sd, ainfo->ai_addr, sizeof(struct sockaddr)))
[2022-11-30T15:02:47Z] <illiliti> if( !(sd = socket(AF_INET, SOCK_STREAM, 0)))
[2022-11-30T15:02:53Z] <illiliti> this is wrong
[2022-11-30T15:03:03Z] <illiliti> 0 is a valid file descriptor
[2022-11-30T15:03:14Z] <illiliti> -1 is invalid
[2022-11-30T15:04:22Z] <midfavila> 0 should be reserved for one of the standard IO streams
[2022-11-30T15:04:30Z] <illiliti> no
[2022-11-30T15:04:33Z] <midfavila> but that's actually fair
[2022-11-30T15:04:45Z] <midfavila> considering it does deviate from spec
[2022-11-30T15:04:48Z] <illiliti> 0 can be closed
[2022-11-30T15:04:57Z] <midfavila> never is, and never should be
[2022-11-30T15:05:00Z] <illiliti> process can be started with 0 closed
[2022-11-30T15:05:09Z] <illiliti> it is possible
[2022-11-30T15:05:17Z] <midfavila> on what system, and how?
[2022-11-30T15:05:29Z] <illiliti> you can do it on your system
[2022-11-30T15:05:36Z] <midfavila> my understanding is that all processes start under a Unix environment with FDs 0, 1, and 2 reserved for standard IO channels
[2022-11-30T15:06:01Z] <illiliti> these can be closed
[2022-11-30T15:06:16Z] <illiliti> you just close them and start a process
[2022-11-30T15:06:28Z] <illiliti> that process will not have them
[2022-11-30T15:07:11Z] <illiliti> it is not good idea to assume that 0 is always present
[2022-11-30T15:07:43Z] <illiliti> especially doing that:
[2022-11-30T15:07:49Z] <illiliti> if( !(sd = socket(AF_INET, SOCK_STREAM, 0)))
[2022-11-30T15:08:41Z] <illiliti> 0 is valid number for file descriptor
[2022-11-30T15:09:02Z] <midfavila> i'll take it into consideration, but i don't think a sane individual would ever close 0, 1 and 2 before executing apport. if they do, there are bigger concerns than a failed socket()
[2022-11-30T15:09:05Z] <illiliti> this 'if' implies that it isn't
[2022-11-30T15:09:13Z] <illiliti> this is wrong and bad
[2022-11-30T15:09:38Z] <midfavila> wrong, in theory. in practice, the worst thing that would happen is apport aborts.
[2022-11-30T15:11:13Z] <phoebos> either way, you're currently testing for 0 or nonzero, which isn't the difference between success and failure of socket
[2022-11-30T15:11:39Z] <illiliti> yeah
[2022-11-30T15:11:41Z] <midfavila> yeah, and that's fair.
[2022-11-30T15:11:50Z] <illiliti> you just need to stop assuming that everything returns a bool
[2022-11-30T15:12:18Z] <phoebos> ideally you'd also not assume AF_INET
[2022-11-30T15:12:33Z] <midfavila> UNSPEC or whatever, right?
[2022-11-30T15:12:51Z] <phoebos> UNSPEC for getaddrinfo, then getaddrinfo tells you what to use
[2022-11-30T15:13:03Z] <midfavila> aah, fair enough
[2022-11-30T15:13:37Z] <phoebos> like you do in connect; socket should also come after getaddrinfo
[2022-11-30T15:14:39Z] <illiliti> i think i see a potential fd leak
[2022-11-30T15:14:49Z] <illiliti> you too?
[2022-11-30T15:15:07Z] <illiliti> due to early returns
[2022-11-30T15:15:21Z] <illiliti> sd will be leaked
[2022-11-30T15:15:24Z] <midfavila> i should probably rewrite dial at some point soon. was one of the earlier functions, wrote it when i was pretty braindead
[2022-11-30T15:17:26Z] <midfavila> fd leak... should definitely be addressed, but it's also not a problem in practice
[2022-11-30T15:17:33Z] <midfavila> at least in this specific case
[2022-11-30T15:19:16Z] <phoebos> you can also freeaddrinfo
[2022-11-30T15:19:26Z] <illiliti> gopher.c:13
[2022-11-30T15:19:38Z] <illiliti> i think you need another byte for NUL
[2022-11-30T15:20:15Z] <midfavila> yeah, there are a few calls to malloc, getaddrinfo and etc that could and probably should have cleanup in main, before a stable release
[2022-11-30T15:20:19Z] <illiliti> cuz REQ_GOPH contains newline
[2022-11-30T15:20:56Z] <illiliti> oh wait no
[2022-11-30T15:21:38Z] <illiliti> no it should be fine
[2022-11-30T15:21:44Z] <midfavila> yeah i was gonna say
[2022-11-30T15:21:56Z] <illiliti> but you would add assert just in case
[2022-11-30T15:22:00Z] <illiliti> I*
[2022-11-30T15:23:39Z] <illiliti> assert for sprintf return value
[2022-11-30T15:23:50Z] <illiliti> ret == buflen
[2022-11-30T15:24:28Z] <illiliti> to confirm that your calculation is correct
[2022-11-30T15:26:03Z] <midfavila> ret+1, but fair enough
[2022-11-30T15:26:33Z] <phoebos> why do you close(sd) when doing tls?
[2022-11-30T15:26:43Z] <midfavila> so I can use tls_connect
[2022-11-30T15:26:50Z] <midfavila> plan is/was to upgrade the socket
[2022-11-30T15:27:03Z] <midfavila> but I wanted TLS working as soon as possible and tls_connect is easier to use
[2022-11-30T15:27:33Z] <phoebos> ah
[2022-11-30T15:27:37Z] <midfavila> otherwise a spare socket is floating around for the lifetime of the program
[2022-11-30T15:32:05Z] <illiliti> main.c:179
[2022-11-30T15:32:07Z] <midfavila> also re: assert I'm fairly certain that the program would abort long before dial() if an error occurs that would render the total string length calculation erroneous
[2022-11-30T15:32:07Z] <midfavila> (strlen(N_REQ) + strlen(path) + 1) only assumes that path is a string -- but considering dial() is called after uri_parse, which validates and breaks apart input, it's never passed anything that isn't a string
[2022-11-30T15:32:23Z] <illiliti> i would use memmem here
[2022-11-30T15:32:33Z] <illiliti> memmem will be posix
[2022-11-30T15:32:47Z] <midfavila> if it's not in posix, i won't use it
[2022-11-30T15:33:02Z] <illiliti> it's in draft
[2022-11-30T15:33:10Z] <midfavila> it could be in draft for years
[2022-11-30T15:33:26Z] <illiliti> ok
[2022-11-30T15:33:35Z] <midfavila> if i define my own version and then say i'll clean up later, versus using functions that are already in posix, there's no chance of spontaneous breakage
[2022-11-30T15:33:41Z] <midfavila> i've encountered a huge number of programs that do this
[2022-11-30T15:33:43Z] <illiliti> make sure that recvbuf is nul-terminated then
[2022-11-30T15:34:13Z] <midfavila> recvbuf is because it's bufsiz+1 and the for loop continously memsets it to null, but recv/tls_read calls only accept BUFSIZ bytes
[2022-11-30T15:34:51Z] <illiliti> ok
[2022-11-30T15:35:01Z] <illiliti> assert wouldn't hurt here too
[2022-11-30T15:40:32Z] <kqz> <testuser[m]> "it doesnt detect my mic unless i..." <- i have the same issue with pipewire and mdevd/libudev-zero, haven’t been able to find a solution
[2022-11-30T15:41:48Z] <illiliti> same question: did it work for you before?
[2022-11-30T15:47:51Z] <kqz> nope, works when I switch to eudev though so not sure if mdevd config issue or libudev zero incompatibility with pipewire
[2022-11-30T15:50:50Z] <illiliti> pipewire is from community, right?
[2022-11-30T15:53:54Z] <wael[m]> es
[2022-11-30T15:55:11Z] <kqz> yeah
[2022-11-30T15:56:23Z] <kqz> seems racy too, every now and again it’ll detect it without me having to restart pipewire
[2022-11-30T16:02:59Z] <illiliti> hmm
[2022-11-30T16:03:11Z] <illiliti> someone need to debug this
[2022-11-30T16:03:25Z] <illiliti> i doubt it will be me cuz i don't use pipewire
[2022-11-30T16:04:33Z] <illiliti> i would recommend starting with bisecting spa/plugins/alsa/alsa-udev.c
[2022-11-30T16:14:18Z] <kqz> i can investigate some more and see, not sure if any specific release or commit broke it though I’ve noticed the issue for a while
[2022-11-30T17:55:02Z] <wael[m]> why did dylan make the decision to switch to wayland?
[2022-11-30T17:55:22Z] <midfavila> probably because from an engineering standpoint wayland is significantly simpler than X11
[2022-11-30T17:58:04Z] <wael[m]> yeah idk why i need dbus or pipewire or tons of dependencies for screensharing
[2022-11-30T17:58:27Z] <wael[m]> maybe the engineering standpoint sure but theres no control in the wayland standards and i just find what weird
[2022-11-30T17:58:43Z] * midfavila shrugs
[2022-11-30T17:59:16Z] <midfavila> i'm still using x11 and i'll continue to until mgr or some similar display system is brought up
[2022-11-30T17:59:25Z] <midfavila> what wayland does is of no consequence to me
[2022-11-30T17:59:57Z] <wael[m]> maybe it needs bloated garbage like dbus and pipewire for ''''''''''''''security'''''''''''''''' but idk
[2022-11-30T18:00:22Z] <wael[m]> i wish there was a XCB/Xlib to wayland, one library that just does wayland stuff. but unfortunately wayland is more of a specification protocol
[2022-11-30T18:01:31Z] <testuser[m]> wael: actually none of that shit is technically needed for screen sharing
[2022-11-30T18:01:35Z] <testuser[m]> Like wf-recorder works just fine
[2022-11-30T18:01:36Z] <noocsharp> nothing about wayland forces dbus or pipewire, it's just that that's become the standard for screensharing
[2022-11-30T18:01:45Z] <testuser[m]> But it's used as an abstraction over various compositors
[2022-11-30T18:02:04Z] <testuser[m]> U can fork webrtc to add non pipewire back end
[2022-11-30T18:02:21Z] <wael[m]> but why did it have to be like this tho
[2022-11-30T18:02:50Z] <testuser[m]> Because everyone uses dbus
[2022-11-30T18:03:07Z] <noocsharp> go write the patches to fix it wael[m]
[2022-11-30T18:03:36Z] <wael[m]> maybe if i knew C or Rust i would
[2022-11-30T18:03:37Z] <testuser[m]> Ye
[2022-11-30T18:03:42Z] <testuser[m]> Then learn
[2022-11-30T18:04:06Z] <testuser[m]> No point in shitting on things you can't provide an alternative for
[2022-11-30T18:04:17Z] <midfavila> that's fallacious,
[2022-11-30T18:04:21Z] <midfavila> but the underlying message is sound
[2022-11-30T18:04:29Z] <midfavila> something something be the change you want to see in the world
[2022-11-30T18:04:43Z] <wael[m]> testuser[m]: xorg
[2022-11-30T18:04:55Z] <wael[m]> idk wayland is like the new thing and many things are switching to it
[2022-11-30T18:05:05Z] <midfavila> then just don't use those things
[2022-11-30T18:05:10Z] <testuser[m]> midfavila: i mean shitting on stuff without suggesting ways to improve / suggesting an alternative that already exists
[2022-11-30T18:05:21Z] <testuser[m]> Like u can say this dish sucks
[2022-11-30T18:05:22Z] <testuser[m]> But why does it
[2022-11-30T18:05:25Z] <testuser[m]> and how to fix
[2022-11-30T18:05:26Z] <midfavila> plenty of software and documentation exists for X wael[m]
[2022-11-30T18:06:51Z] <wael[m]> eh ur right
[2022-11-30T18:06:58Z] <wael[m]> but is there any advantage to wayland other than security?
[2022-11-30T18:06:58Z] <testuser[m]> And package/dependency count is meaningless
[2022-11-30T18:07:19Z] <testuser[m]> You could have a program that's super fat with no external deps
[2022-11-30T18:07:22Z] <wael[m]> i got out of that mindset
[2022-11-30T18:07:28Z] <wael[m]> what it depends on kinda matters more
[2022-11-30T18:07:39Z] <testuser[m]> And a smaller one which has many deps but combined they're still lless complex than that one package
[2022-11-30T18:07:39Z] <midfavila> it's not entirely meaningless, but it's only part of a larger equation
[2022-11-30T18:07:58Z] <wael[m]> testuser[m]: aka flatpak lol
[2022-11-30T18:08:19Z] <testuser[m]> if you were to unbundle every single bundled library from chromium it would add to like 30 packages
[2022-11-30T18:08:20Z] <testuser[m]> Or something
[2022-11-30T18:08:22Z] <noocsharp> the core wayland protocol is smaller than X, the downside is that it doesn't include everything everyone would want out of a window compositing protocol
[2022-11-30T18:08:55Z] <noocsharp> the upside is your can choose what you care about
[2022-11-30T18:09:10Z] <wael[m]> so from an engineering standpoint wayland is much easier to implement yes?
[2022-11-30T18:09:14Z] <wael[m]> which is why i assume dylan chose it
[2022-11-30T18:09:18Z] <midfavila> isn't wayland also largely linux specific?
[2022-11-30T18:09:26Z] <wael[m]> no
[2022-11-30T18:09:37Z] <midfavila> i know fBSD has their own compositor that they're working on, but I've not seen it be adopted much outside Linux
[2022-11-30T18:10:01Z] <wael[m]> https://docs.freebsd.org/en/books/handbook/wayland/
[2022-11-30T18:10:12Z] <midfavila> i already mentioned that
[2022-11-30T18:10:20Z] <wael[m]> but still, again, but is there any advantage to wayland other than security?
[2022-11-30T18:10:37Z] <midfavila> uh, it's conceptually simpler and it's free of cruft
[2022-11-30T18:11:05Z] <wael[m]> aaand?
[2022-11-30T18:11:17Z] <midfavila> that's really all it needs
[2022-11-30T18:11:19Z] <noocsharp> it's easier to debug and fix
[2022-11-30T18:11:30Z] <midfavila> if all you want is to dump windows on a framebuffer wayland will get you there faster than X
[2022-11-30T18:12:16Z] <midfavila> of course, X has peripheral support, flexibility and legacy compat on its side
[2022-11-30T18:14:00Z] <noocsharp> wdym peripheral support?
[2022-11-30T18:14:39Z] <midfavila> X still has the ability to handle things like monochrome displays and other less common interface devices
[2022-11-30T18:14:48Z] <midfavila> of course, that's not suuuuper relevant in today's world
[2022-11-30T18:15:11Z] <midfavila> but being able to choose four-bit color instead of 32-bit on my e-reader and the inverse on my desktop is a very nice feature to have
[2022-11-30T18:16:10Z] <midfavila> i'm sure a wayland compositor could do the same, but... well, it would only be one wayland compositor
[2022-11-30T18:17:58Z] <wael[m]> hm
[2022-11-30T18:18:56Z] <noocsharp> 32-bit color would still work on eink, right? just a waste of computation?
[2022-11-30T18:20:06Z] <midfavila> yes
[2022-11-30T18:20:09Z] <noocsharp> waste of computation when rendering at 32-bit instead of 4 that is
[2022-11-30T18:20:10Z] <midfavila> and a massive waste of memory
[2022-11-30T18:20:13Z] <wael[m]> because its 38 years old.
[2022-11-30T18:20:24Z] <noocsharp> ah
[2022-11-30T18:20:26Z] <midfavila> and considering it's a mobile device, memory usage and energy usage are fairly important
[2022-11-30T18:20:41Z] <midfavila> also jfc why is android so shit
[2022-11-30T18:20:47Z] <midfavila> there are no half-decent standalone ftp clients
[2022-11-30T18:21:02Z] <testuser[m]> ftp deprecated broo
[2022-11-30T18:21:07Z] <noocsharp> sftp
[2022-11-30T18:21:11Z] <testuser[m]> midfavila: use termux
[2022-11-30T18:21:17Z] <midfavila> sftp is gay and i'm already using termux
[2022-11-30T18:21:28Z] <midfavila> it's just a pain in the ass having to tap out individual letters using my styli
[2022-11-30T18:22:39Z] <wael[m]> youre gay
[2022-11-30T18:22:43Z] <midfavila> uwu~
[2022-11-30T18:22:57Z] <wael[m]> what the fu
[2022-11-30T18:24:42Z] <Glitch[m]> wael: helow awael
[2022-11-30T18:24:49Z] <wael[m]> hello glitch
[2022-11-30T18:25:06Z] <Glitch[m]> im use burger linu x\
[2022-11-30T18:25:15Z] <testuser[m]> Wat
[2022-11-30T18:25:22Z] <Glitch[m]> best dsitro
[2022-11-30T18:25:27Z] <Glitch[m]> bruegrign l;uinuxes
[2022-11-30T18:26:19Z] <wael[m]> never come back
[2022-11-30T18:26:26Z] <testuser[m]> Tf is buger linux
[2022-11-30T18:26:40Z] <wael[m]> he is doing a little bit of trolling
[2022-11-30T18:27:46Z] <midfavila> yeah i have no clue how people can tolerate using android...
[2022-11-30T18:27:53Z] <midfavila> even just transferring a file is painful
[2022-11-30T18:28:04Z] <midfavila> i guess if you used webshit it would be tolerable
[2022-11-30T18:28:50Z] <testuser[m]> That's literally what it's meant for
[2022-11-30T18:29:16Z] <midfavila> hell
[2022-11-30T18:29:36Z] <midfavila> can't wait until pmos can be flashed to the pine note
[2022-11-30T18:33:55Z] <illiliti> > isn't wayland also largely linux specific?
[2022-11-30T18:34:03Z] <illiliti> yes, absolutely
[2022-11-30T18:34:17Z] <illiliti> don't even mention freebsd support
[2022-11-30T18:34:21Z] <illiliti> it is joke
[2022-11-30T18:38:04Z] <wael[m]> aw
[2022-11-30T18:39:14Z] <illiliti> everytime people say that wayland supports freebsd, i cringe
[2022-11-30T18:39:40Z] <illiliti> i mean look at what freebsd did to get this "support"
[2022-11-30T18:40:10Z] <illiliti> instead of forcing wayland to use freebsd native interfaces, they forced freebsd to implement linuxism
[2022-11-30T18:40:31Z] <illiliti> libudev, evdev, libinput, epoll and other crap
[2022-11-30T18:41:09Z] <illiliti> i would not call this support
[2022-11-30T18:41:24Z] <illiliti> it's rather shim programming that a proper support
[2022-11-30T18:43:22Z] <illiliti> proper support is when software relies on OS's native interfaces
[2022-11-30T18:43:54Z] <illiliti> what wayland did is ridiculous
[2022-11-30T19:04:39Z] <phoebos> lol xcb and Xlib are different libraries using the same protocol
[2022-11-30T19:04:42Z] <phoebos> hi noocsharp
[2022-11-30T19:09:41Z] <midfavila> fwiw xlib just sits on top of xcb these days
[2022-11-30T19:24:44Z] <noocsharp> hi phoebos
[2022-11-30T19:25:54Z] <noocsharp> illiliti: and when a system implements an interface it becomes native
[2022-11-30T19:26:19Z] <testuser[m]> phoebos: but there could be an xz that doesn't even use -d/-c for (de)compression
[2022-11-30T19:26:24Z] <testuser[m]> The file format is well specified
[2022-11-30T19:26:28Z] <testuser[m]> But not any utility
[2022-11-30T19:26:48Z] <testuser[m]> Should be trivial to stub -T for any dev
[2022-11-30T19:27:47Z] <testuser[m]> For compression xz definitely benefits a lot from threads
[2022-11-30T19:31:38Z] <illiliti> of course, if said system is a linux puppet it will implement all shims and all interfaces
[2022-11-30T19:32:30Z] <illiliti> no matter how bad they are and no matter that system already have similar interface
[2022-11-30T19:32:44Z] <illiliti> only matter is result, right?
[2022-11-30T19:39:47Z] <phoebos> testuser[m]: if we find an xz that doesn't implement -d then we'll work around it
[2022-11-30T19:39:56Z] <phoebos> but there is one that doesn't support -T
[2022-11-30T19:40:19Z] <phoebos> however, i'll send them a message to see if they'll stub it