gchristensen changed the topic of #nixos-chat to: NixOS but much less topical || https://logs.nix.samueldr.com/nixos-chat
<samueldr> hmm, naming things issue here
<gchristensen> how about a77d34a2-6e32-4a75-b13f-e2c8f25dc908
<samueldr> hmm, might have duck'd myself, thanks
<samueldr> only if you use the programming API I'm writing
<gchristensen> yep
<samueldr> brb, my irc client is confused again
samueldr has left #nixos-chat [#nixos-chat]
samueldr has joined #nixos-chat
<samueldr> it thought gchristensen wasn't a valid nickname to complete here...
<gchristensen> heh...
<gchristensen> woohoo, my second (trivial) patch to zfs merged
<qyliss> gchristensen++
<{^_^}> gchristensen's karma got increased to 206
<ajs124> nice, what are you patching?
<ajs124> my only patch there (see https://github.com/zfsonlinux/zfs/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aajs124) is even more trivial
<gchristensen> nice
<gchristensen> I'm a little scared to dig in to my PR's remaining failure :x
<samueldr> how scare are you on a scale of 53 000 000 rows being migrated?
<samueldr> how scared*
<gchristensen> I'd rather migrate another 110 million rows
<samueldr> don't say that, or it might happen
<gchristensen> lol
<ajs124> About that whole migration thing: I'm still kind of unclear how this will affect small hydra installs. Do I need to do this whole thing manually as well?
<gchristensen> quite likely yes
<gchristensen> though maybe it could be made to run automatically during hydra-init
<gchristensen> the down-side being if you have many rows, your hydra will be down for a long time
<ajs124> We have <100k builds, so I think we'd be fine. TBH, worst case I drop the database and start from scratch. I just want to be prepared ^^
<gchristensen> so much vacuuming
<gchristensen> 100k can be done in only a few seconds on a moderately powerful server :)
<gchristensen> it took 84 seconds to just count the number of records inthe builds table
<ajs124> vacuuming? sounds like you're in need of a mega maid (https://www.youtube.com/watch?v=O7aeWQCF1jM)
<gchristensen> lol
<cransom> i must not have watched that in a very long time. i never noticed the 'ready kafaka?' bit.
<cransom> s/kafaka/kafka/
<gchristensen> guh 1987
wildtrees has quit [Quit: Leaving]
<colemickens> gchristensen: kind of random, but you had mentioned ikwldpeppers (or something like that) working on Azure stuff a month or so ago. Do you know what came of that?
<gchristensen> he's still suffering through afaik :)
<samueldr> cc-by
<ashkitten> apparently the pinebook pro is on par with lower end ryzen cpus :o
<samueldr> on par how?
<samueldr> (not that I doubt)
<ashkitten> gf did a linux compile test and the pbp got 27 mins, her ryzen 5 2600 got 17
<ashkitten> thats 62% the speed
<samueldr> not bad
<samueldr> yeah
<ashkitten> and it's like, not an expensive laptop at all
<samueldr> I think graphical acceleration is the main issue to solve with nixos now
<samueldr> and well, the other small issues that are not nixos-specific
<ashkitten> honestly i'm really impressed
<ashkitten> my dream machine would be a risc convertible with at least 12 gigs of ram, a trackpoint nub, and one of those touchpads with physical buttons at both the top and bottom
<ashkitten> and usb c
<samueldr> hopefully a new SoC with a bigger RAM maximum will be usable soon for such an endeavour
<samueldr> RK3399 is limited to 4GiB
<samueldr> (and is getting a bit old)
<ashkitten> ahh
<ashkitten> yeah
<ashkitten> unfortunately the pinetab is the same soc as the pinebook and pinephone
<samueldr> yeah
<ashkitten> otherwise i'd be pretty interested
<samueldr> rk3399 was announced in 2016
<samueldr> I wonder how it compares to low and mid-end 2016 chips in x86-land
<ashkitten> if they released a pinetab with an updated soc and more ram i might get it
<samueldr> I also wonder if qualcomm would be ameniable to working with a "open source friendly" outfit like pine64 with their IP
<ashkitten> ehhhh
<ashkitten> i wouldnt bet on it
<samueldr> I wouldn't either :)
<ashkitten> they've been notorious for antagonistic business practices, yeah?
<samueldr> but they're the main name I know of that are "mobile" friendly and not older designs
<samueldr> yep
<samueldr> but... maybe no one asked?
<samueldr> it could be that the OEMs themselves want those horrible misfeatures?
<ashkitten> the oems definitely want garbage
<ashkitten> but which misfeatures?
<samueldr> biased opinion: having the firmware part of the main storage of the device, meaning that one slip of a `dd` and the device is now useless
<samueldr> those new qualcomm laptops also have a completely bonkers eMMC layout where the partitions for the firmware are interpersed with the windows partitions
<colemickens> gchristensen: I don't know what level of complexity they're aiming for, but if it's just a matter of basics, I might be able to help.
<samueldr> so you can't just erase the whole drive or you, simply put, delete the bios
<colemickens> I tried to help a way to contact that person, but couldn't figure it out.
<ashkitten> i absolutely hate when things let you easily brick them
<samueldr> and since qualcomm has some kind of "secure boot" scheme, you need a signed program to upload to the CPU to unbrick
<gchristensen> colemickens: I bet they would like help. maybe you could get on sometime early your morning?
<colemickens> I decided to try and get my nixpkgs PR count closer to 0 and my azure PR is a big outstanding one and enough people were interested that I want to finish it.
<samueldr> those often get leaked, but that's not a guarantee
<ashkitten> there should be immutable backup firmware somewhere no matter what, you shouldnt be able to brick a device
<colemickens> gchristensen: sure I can do that in the next day or two
<gchristensen> cool
<samueldr> exactly, the design for the firmware of chrome-based devices are imo the best example we have right now
<samueldr> while there is one chip you can't control, its firmware source code is available, so you can compile and compare
<samueldr> that chip allows you to recover if you erase the (separate) firmware chip
<ashkitten> huh
<ashkitten> neat
<samueldr> and unlocking your device for this is done in what, AFAIK, is a secure way, though understandably annoying
<ashkitten> but yeah like, imo it's so antagonistic toward the open source community if you make flashing a device dangerous and difficult
<samueldr> oh, and it runs coreboot, and the chrome hardware team contributes to mainline coreboot
<samueldr> on x86_64 devices you can generally install tianocore payloaded coreboot trivially
<ashkitten> that's cool
<samueldr> arm devices you probably could, but there's not the community building the equivalent
<ashkitten> i wish arm devices were like, easier to get working?
<ashkitten> x86 machines you just dump some files in a fat32 partition and boom you're up
<ashkitten> the process on arm is not really comparable
<samueldr> most often it comes from the fact ARM SBCs are "bring your own firmware"
<ashkitten> yeah, which is frustrating
<samueldr> EBBR is one way they are pushing in ensuring this stops being the case https://github.com/ARM-software/ebbr
<samueldr> x86_64 would probably be just as annoying if the firmware wasn't part of a chip already
<ashkitten> is ebbr comparable to the bios spec?
<samueldr> not exactly
<samueldr> but it mandates UEFI should be used
<samueldr> and how to store multiple firmwares together side-by-side
<ashkitten> so boards that support that spec should be as simple to work with as x86_64?
<samueldr> but also mentions that's when the implementor doesn't want to put the firmware on a separate chip
<samueldr> yes
<ashkitten> that's very exciting
<samueldr> you can technically make the Pine64 A-LTS EBBR compliant, and the pi, somewhat
<samueldr> when done, you can download the UEFI aarch64 iso for nixos and just boot it
<samueldr> I have here one pi with tianocore on SD card, and that pine A64-LTS with u-boot on SPI
<ashkitten> oh very cool
<samueldr> they both can boot the aarch64 iso like you would
<samueldr> uh, like you would on x86_64
<samueldr> now, it's more about mainline linux being less of a pain
<samueldr> and that's part of the issue here...
<samueldr> you know how it's bring-your-own-firmware?
<ashkitten> sure
<samueldr> they uh... made the bad decision (imo) of being keepers of device trees
<samueldr> and "fix" all kind of things in device tree properties
<samueldr> if you want to boot the most recent kernels, you also have to use the right device tree
<samueldr> which technically can be done by a bootloader
<samueldr> but it's not part of the UEFI spec or EBBR (AFAIK)
<ashkitten> i'm a bit confused
<samueldr> so, now you have to update your firmware to get the right device tree to boot the most recent kernel, or else things may fail
<ashkitten> oh i see
<ashkitten> that is bad
<samueldr> imagine if on x86_64 you had to update your bios to boot kernel 5.5?
<ashkitten> hah
<samueldr> they _already_ have to handle this in-kernel rather than involve updating unrelated parts for x86_64
<ashkitten> as if motherboard manufacturers would update anything if they didn't have to
<samueldr> I'm a bit sour that this is not done that way on aarch64
<samueldr> since this means that EBBR can't really work until the kernel stops doing what they are doing
<ashkitten> yeah i see
<samueldr> or handle loading dtbs as part of a "kernel" task
<samueldr> it would be perfectly fine with me if, during early boot, the kernel somehow looked at the `compatible ` string for the board, and then loaded the "right" dtb (according to the kernel) that would be built-in the kernel imag
<samueldr> image*
<ashkitten> right
<samueldr> rather than assuming it will be done by the bootloader
<ashkitten> that makes sense
<ashkitten> at least the silver lining for nixos is that we can effortlessly revert to a previous generation that worked
<samueldr> we can't with EBBR
<ashkitten> no?
<samueldr> or, uh, we can't if the bootloader doesn't load the device tree for the right kernel
<samueldr> let me rephrase again: we're stuck with *one* device tree that the firmware knows about, with UEFI
<samueldr> unless we start adding better generic FDT support in e.g. grub
<ashkitten> grub supports aarch64?
<samueldr> yes
<ashkitten> that's news to me
<samueldr> that's what is used by the UEFI installer on aarch64
<ashkitten> huh
<samueldr> and on tianocore on the raspberry pi it's fully graphical
<ashkitten> ah, neat
<samueldr> not sure with the most recent u-boot on Pine A64-LTS, but it falls back to graphical on 18.09
<samueldr> ooooh, pinebook A64, it's graphical
<samueldr> my pinebook A64 uses UEFI boot through trickery
<samueldr> when I bought it I was assuming it had an SPI flash, it doesn't :(
<ashkitten> ah
<ashkitten> so let me get this straight: linux doesn't try to load the correct device tree, which means if you try to boot a kernel that expects features or fixes that aren't in the device tree your firmware loads, it won't boot. yes?
<samueldr> it may boot, but that thing it fixes won't be fixed
<samueldr> it's also, imo, an issue with multi-operating-system interaction
<samueldr> all the BSDs, haiku, they could very well do the same thing
<ashkitten> i'm confused the issue if it does in fact boot. if i haven't updated the firmware to include a fix, i would expect my system to boot without the fix
<ashkitten> what is the deviation from expected?
<samueldr> that's it, it boots, but the fix isn't there
<samueldr> it could be something like configuring the display driver for the panel
<samueldr> maybe in the past the driver hardcoded a refresh rate
<samueldr> now they want to make the driver more generic, move the refresh rate to a _configuration_ inside the device tree of the devices using that driver
<ashkitten> then when i boot it won't initialize the panel because it expects the fix now?
<samueldr> though, tbf, it _is_ a hard problem, fixing stuff after the fact
<samueldr> ashkitten: pretty much, the module could fail since there is no way to know the refresh rate
<ashkitten> so you want linux to vendor the device tree so it will stay in sync, yeah?
<samueldr> they do, but they leave *loading* their updated device trees as an exercise to the system implementor
<ashkitten> so again the silver lining as far as i see is that if i update the kernel but the new device tree is not installed, i can still revert to the previous generation right?
<ashkitten> as long as grub is not somehow broken by that
<samueldr> yep
<ashkitten> this all makes sense to me
<ashkitten> thanks for explaining
<samueldr> thanks for listening
<samueldr> I hadn't thought up until now that it might be possible to do something kernel-side to build-in all device trees and manage loading them
<samueldr> as long as it's a task that happens before it wants to be used, it should be possible, even conditionally loading a device tree overlay that's built-into the kernel
<samueldr> like dtoverlay=rpi3-spi-is-now-a-chicken.dtbo, that would somehow map in the built-in table to the right dtbo and the kernel would overlay it
<samueldr> (does it show, that I've never had a real use for dtbos so I don't know what one would actually be named?)
<ashkitten> ahh
<ashkitten> lol
<samueldr> looking at feasability, dtbs are ~9.1MiB, this would be added on top of 35MiB kernel images for "defconfig" mainline
<samueldr> which at this point I think shouldn't be considered "added weight" as you *anyway* need to ship those file
<samueldr> I hate this, I don't have the time to do this, but I feel this would be immensely beneficial to improving the story of booting kernels on device tree platforms
<samueldr> hey, someone, steal my idea, implement it, I promis I'll (not) be mad that someone did what I wanted to
<samueldr> depends if you want to spite or help me
<samueldr> oh, and continuing from a previous tangent, another thing that muddies the water with booting in ARM-land is how u-boot is both the firmware *and* the bootloader in most situations
<ashkitten> ah
<samueldr> and the trick I used for UEFI on SPI-less allwinner https://nixos.wiki/wiki/NixOS_on_ARM/Allwinner_GPT_Installation
<gchristensen> only 23,413,861 to go. g'night.
<samueldr> with the main drawback that you'll need to be careful with the device tree for booting updates, if any
<samueldr> (I haven't been using the pinebook a64 at all, due to its frustrating keyboard)
<ashkitten> yeah i'd use it but the keyboard is just too bad
drakonis has joined #nixos-chat
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined #nixos-chat
<colemickens> This was a nice update https://news.ycombinator.com/item?id=22295102
colemickens_ has joined #nixos-chat
<drakonis> its nice.
<drakonis> guix in the comments, as per usual.
waleee-cl has quit [Quit: Connection closed for inactivity]
garmanarnar has joined #nixos-chat
KeiraT has quit [Ping timeout: 240 seconds]
ajs124 has quit [Remote host closed the connection]
<colemickens> I like seeing related tech in comments, but the comment didn't really make sense. The stuff listed about Guix is the stuff it inherited from Nix, as I understand it. It didn't really highlight why I'd want to checkout Guix if I were already happy with Nix.
<DigitalKiwi> ...did you expect better from the orange site?
<colemickens> I mean, of course not. But more from a fellow Nix/Guix evangelist, yes :)
<colemickens> I'm just happy to see mentions of Nix and Guix accelerating. I don't think I'm imagining it.
<drakonis> the comment wasnt very good, but there's a variety of things it has inherited and augmented through scheme
<drakonis> i'm hoping to see see some measure of an arms race between both, to see how much either will grow
<drakonis> the writer of the guix comment wrote a follow up at least
<drakonis> not much either
<drakonis> hm, an evolutionary race rather than arms race
<infinisil> Hm, we could really use some roadmap for high-level goals to improve Nix
<drakonis> indeed,
<infinisil> Would imo include: Improving docs, reducing nixpkgs complexity, improving quality of nixos modules
<drakonis> but look at this person talking about how nix is dropping osx support for ideological reasons
<drakonis> reducing nixpkgs complexity is a lofty goal
<drakonis> a lot of things depend on it
<drakonis> as is, so changes will likely require a lot of sweeping to improve it
<infinisil> Yeah
<drakonis> it'd also significantly cut down on the package count
<infinisil> Also another thing: Improving and unifying support for different language builders
<drakonis> yes please.
<drakonis> doing away with builder automagic would be pleasant
<drakonis> reduce build process assumptions
<drakonis> there's a noticiable amount of per package hooks
<drakonis> i'm not sure if i can sufficiently appreciate the build being modified by my input packages
<drakonis> rather than some deliberate action such as picking the build system
<drakonis> fixing that would likely break everything in nixpkgs, right?
<samueldr> right, that's not even the root of the issue
<samueldr> it would break users of nixpkgs
<drakonis> the whole thing is approaching non maintainability
<samueldr> I was only answering the specific "would break everything in nixpkgs?" question
<drakonis> fair enough, the answer was already known.
<samueldr> I feel this is something that needs to be Proof-of-concepted and RFC'd rather than shouted in the void that is the off-topic nixos irc channel ;)
<drakonis> hah, alright.
<drakonis> its a lot of work to completely redesign nixpkgs
<samueldr> I agree that we shouldn't necessarily sit on our hands with the status quo
<samueldr> and yes, it's a big, huge task
<samueldr> any effort, even if it's a failure, is a good place to learn what to do and what not to do
<drakonis> i honestly dont have enough dominion over nix lang to do such a thing
garmanarnar has left #nixos-chat ["WeeChat 2.6"]
endformationage has quit [Quit: WeeChat 2.6]
drakonis has quit [Ping timeout: 265 seconds]
vesper has quit [Ping timeout: 240 seconds]
vesper11 has joined #nixos-chat
lovesegfault has joined #nixos-chat
drakonis has joined #nixos-chat
cole-h has quit [Ping timeout: 268 seconds]
drakonis has quit [Ping timeout: 240 seconds]
<ashkitten> samueldr: oops.. i thought gf was talking about her desktop when she said "ryzen" but she meant her laptop, with a 2500u
<ashkitten> i feel very silly now
makefu has quit [Quit: WeeChat 2.6]
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-chat
__monty__ has joined #nixos-chat
colemickens_ has quit [Quit: Connection closed for inactivity]
drakonis has joined #nixos-chat
waleee-cl has joined #nixos-chat
drakonis has quit [Ping timeout: 246 seconds]
<pie_[bnc]> lolwut lolwut i dont even know who to show this to https://wiki.haskell.org/Meet_Bob_The_Monadic_Lover
<eyJhb> Tried to sell LEGO on NixOS during my last meeting. They seemed somewhat interested :p
<Taneb> I've definitely asked this twice before, but LEGO here means some software that your organization (university?) uses, and isn't in fact plastic building blocks
<Taneb> Right?
<eyJhb> Taneb: LEGO in this case is lego.com, so the plastic building blocks :p
makefu has joined #nixos-chat
<eyJhb> OCTP is the other thing! But LEGO has employed me to work on OCTP ( https://gitlab.com/deviosec/octp )
<Taneb> Right! I am glad I asked
<Taneb> That's pretty cool
<eyJhb> I can understand the confusing, isn't always easy keeping track of :p - But I was at a meeting last year, and tried asking what distros they used etc. where I mentioned NixOS would be nice if they wanted to test it out
<eyJhb> The conversation quickly turned to Golang, since one of the devs had some Golang code he really wanted to show me
<eyJhb> Is there any "number" of what the biggest company is, that uses NixOS internally?
<eyJhb> Like, how many actual machines
<Taneb> I can give you a very low lower bound
<eyJhb> Taneb: Hit it
<Taneb> We have 2 NixOS machines
<__monty__> IOHK must run a few, clever?
<eyJhb> Taneb: that is less than I have at home :p
<eyJhb> Reminds me, I should update the router now that I am alone
<eyJhb> __monty__: https://iohk.io/ ?
<Taneb> It's the same number as I have at home (we use way too much proprietary software that makes assumptions that just don't hold on NixOS)
<eyJhb> Waiting for the day OpenSource can completely take over... So much that can be switched in Denmark, e.g. Hospitals using Office
<eyJhb> It would be amazing using opensource journal systems
<eyJhb> "This experience was hell, lets improve this !" would be awesome...
<pie_[bnc]> eyJhb: whats a LEGO
<pie_[bnc]> besides expensive toy blocks
<pie_[bnc]> oh its right there in the scroll
<eyJhb> pie_[bnc]: yeah the company :p
Seto_Kaiba has joined #nixos-chat
Hunterkll has quit [Ping timeout: 256 seconds]
m1cr0m4n has quit [Ping timeout: 260 seconds]
m1cr0m4n has joined #nixos-chat
<DigitalKiwi> LEGO MY EGGO
tilpner_ is now known as tilpner
aanderse has joined #nixos-chat
<aanderse> :)
drakonis has joined #nixos-chat
ajs124 has joined #nixos-chat
das_j has joined #nixos-chat
waleee-cl has quit [Quit: Connection closed for inactivity]
DigitalKiwi has quit [Quit: quite.]
DigitalKiwi has joined #nixos-chat
waleee-cl has joined #nixos-chat
Seto_Kaiba is now known as Hunterkll
<worldofpeace> lol, nixos support over mastodon https://mastodon.social/web/statuses/103631567654364956
<gchristensen> nice, at least you can send support messages > 280 char :P
<worldofpeace> 😎 that's why I can't use the birdsite
<worldofpeace> you can't fit any good prose
* gchristensen really wants grahamc.com running masto
evanjs has joined #nixos-chat
<worldofpeace> why do you need to be graham@grahamc.com? hehe, an instance for your fans?
<gchristensen> because I don't want to have my identity tied to another org like that. unlike Twitter, the server you're on means something and it ties me to them in a way I don't like (and have avoided for email for at least a decade)
<worldofpeace> I see what you mean, but with the fediverse it's not as chained like that. I think? Well I guess then you'd have multiple identities if you had to switch an instance
<worldofpeace> * multiple online identities
cole-h has joined #nixos-chat
<infinisil> worldofpeace: Doesn't mastodon support changing instances now? I think I read something about that
Synthetica has joined #nixos-chat
<worldofpeace> yes
<worldofpeace> "easy and painless"
KeiraT has joined #nixos-chat
drakonis has quit [Remote host closed the connection]
drakonis has joined #nixos-chat
drakonis has quit [Client Quit]
CRTified has joined #nixos-chat
endformationage has joined #nixos-chat
lovesegfault has quit [Quit: WeeChat 2.7]
wildtrees has joined #nixos-chat
wildtrees has quit [Remote host closed the connection]
wildtrees has joined #nixos-chat
emilazy is now known as emily
emily is now known as emilazy
emily has joined #nixos-chat
<emily> I think you can't migrate between different fediverse server software, though?
<emily> only Mastodon→Mastodon
<emily> I might be wrong here
<emily> would be interested in hearing how it works if I am
<gchristensen> git-am is so nice and so frustrating
<samueldr> how?
evanjs has quit [Quit: ZNC 1.7.5 - https://znc.in]
<samueldr> haven't had much use of it yet, so maybe some frustration isn't obvious
<gchristensen> if it fails to apply it just dumps the patch in to a .ptach file in .git
<samueldr> though the one I had is "git is now in a confused state, try to find the right incantation to cancel" as most commands have
<samueldr> though --abort has been added to more and more git commands, thankfully
evanjs has joined #nixos-chat
<etu> worldofpeace: Oh, you found my toot :-) https://chaos.social/@sa0bse/103624640439287571 -- different username but it's me:-)
<worldofpeace> etu: oh, hi 👋 You should probably add github to your profile metadata
<qyliss> gchristensen: git am --reject
<samueldr> that issue is extremely frustrating
<samueldr> since it's possible every one of the corroborating comments "it happens to me too" are different issues
<samueldr> and short of having the same exact setup, computer, bios configuration, usb drive even, it's hard to reproduce
<samueldr> funny how I can bet I can scrounge up the other distros bug trackers and find similar unsolved issues
<samueldr> jokes?
<samueldr> and... even more frustrating: the bootloader *completely changed* since this issue was opened
<samueldr> so if it's a bootloader issue, rather than a kernel issue, it's not even relevant
<samueldr> I'm willing to bet exposing the "new kernel" variant of the issue could have helped a couple of those facing the issue
<samueldr> I'm not even sure UEFI is relevant for some
<ashkitten> emily: i think the only issue would be that other servers don't support the migration feature
<samueldr> the more I think about it, the more it seems to be a failure of the "bug tracking" software with github
<samueldr> we can't simply pick a comment and split it into its own issue to work out
<ashkitten> emily: you should be able to support migration from any server that can mark you as "moved" to any server that can send out the migration event
<samueldr> so we have this omnibus "I can't boot" issue that is seemingly unsolvable
<emily> ashkitte1: it's complicated; other servers can have fundamentally different data models
<emily> I forget the details but I remember it being a mess
<ashkitten> it's not that complicated really
<ashkitten> it's just a matter of letting servers know that you've moved
<ashkitten> oh you mean importing/exporting follows?
<emily> well, ok
<emily> I meant if you wanted to migrate posts, follows, etc.
<ashkitten> migrating posts is not possible at the moment
<emily> right
<emily> activitypub basically only standardizes post interchange to my understanding so it'd be hard to do fully-featured migration without speccing a lot more mechanism/policy?
<ashkitten> migrating follows is easy, i know mastodon and pleroma can both export/import a csv of your follows
<emily> I'm no expert though; I don't even have a fediverse account ^^;
<ashkitten> the problem with migrating posts is partly that of identity verification but mostly that of federation
<ashkitten> you could in theory rewrite the posts and store them locally in your database as if a local user created them, but you would have to manually notify every server that they exist
<ashkitten> as far as i know there is no way for a server to federate a post from itself without it appearing as if it was just created
<ashkitten> er like
<emily> right
<ashkitten> there's no way to federate a post and not have it show up in people's timelines right away
<ashkitten> because mastodon for instance doesn't sort timelines chronologically by creation, but chronologically by time of reception
<ashkitten> which, to be fair, is mastodon's own problem. but it does put a damper on our ability to federate older statuses without spamming followers
<ashkitten> ofc there's the added issue that we should really be batching these somehow so that every server in a metaphorical 10 mile radius doesn't have to process a 100k post history at once
<ashkitten> but even that poses its own issues
<ashkitten> you can see why this hasn't been solved yet, i hope :p
<emily> yeah
<emily> hence me replying to 「"easy and painless"」 :p
<emily> (and why I still don't have a fediverse account yet; need to set something up on emily.moe)
<ashkitten> good luck
<ashkitten> you've been working on that mastodon pr for nixpkgs, right?
<__monty__> Did mastodon get more popular than diaspora because of UIcandy?
<ashkitten> because it looks nicer, you mean?
<__monty__> Yeah, diaspora dates much further back afaik?
<ashkitten> i don't know much about diaspora* to be honest
<ashkitten> i know they use their own protocol
<emily> nope, not me
<__monty__> Also, doesn't that post ordering cause replies to be ordered before the comment they're meant as a reply to sometimes?
<ashkitten> __monty__: yes, if someone's sidekiq queue is acting up. and if the reply is processed first then it won't get attached to the parent
<__monty__> Ouch, that sounds horrible.
<ashkitten> but to relay some history, mastodon started out as gnu social compatible because, as i recall, eugen wanted a gnu social frontend that was more like tweetdeck
<__monty__> Tbh, everything I've heard about ActivityPub (including from the original author) is horrible.
<ashkitten> the current state of the activitypub fediverse doesn't quite follow what chris had envisioned
<ashkitten> fwiw i think a lot of that is eugen's fault
<ashkitten> (it's partly his fault that gnu social people hate mastodon users, too)
<__monty__> Why is that? Do they feel cheated?
<ashkitten> because he abused the ostatus spec to graft on features he liked, and didn't care how they impacted the experience of existing ostatus users
<ashkitten> and then mastodon users came along and there was a lot of fud spread about gnu social because it didn't support the features he had grafted on
<ashkitten> things like post visibility levels weren't a thing until he went and created them, but if your post federated to a gnu social instance anyone could see it
<ashkitten> and mastodon users were lead to believe this was an intentional thing gnu social people were doing
<ashkitten> if you look at mastodon's history there's a number of instances of mastodon users being real shitty to people on other federated softwares, spreading fud, etc. and a lot of it can be traced back to "eugen implemented a thing in a bad way and didn't stress the caveats enough"
<emily> to be fair i think you'll also find a number of instances of literal nazis on gnu social being real shitty to people on other federated software too...
<etu> worldofpeace: Good point, I'll do that
<ashkitten> emily: yes, and you'll find mastodon instances with nazis as well. and?
<emily> I think there would be a substantial amount of strife between gnu social people and any new influx of people as a result of that regardless of how server/client devs behaved
<ashkitten> i mean
<ashkitten> i don't know that there's any substantially higher percentage of nazis on any one software
<ashkitten> and if there is i don't think that's a result of the software itself
<emily> shrug I don't remember the last time I found myself on a GNU Social instance and thinking I'd want to ever interact with the people on it, but this is mostly cached memories from years ago, and there's obviously sampling bias there
<emily> nothing to do with the software though, yeah
<ashkitten> i know pleroma is claimed to have a high percentage of bad actors but that's partly down to it being easier to spin up a pleroma instance
<emily> I just think some kind of schism was probably inevitable given sufficiently divergent userbases existing in a very incomplete federated system
<ashkitten> for the record i don't like the pleroma devs personally, but i don't see anything wrong with their software
<emily> part of the reason I don't have anything on emily.moe yet is because all the server software seems not great, tbh >_>
<ashkitten> but i can tell you, having been on the fediverse watching all of this happen since 2016, a lot of strife could have been avoided if eugen had accurately described what his features could and especially could not do
<emily> mhm
<ashkitten> and if it had been portrayed that instances that don't respect his features are not necessarily malicious
<emily> free software is hard; controlling what a large userbase thinks is even harder
<emily> not to necessarily say he did nothing wrong either since I don't know the details
<emily> but "interoperating with arbitrary existing clients in a federated system while still implementing important new features at a reasonable pace /and/ communicating proactively about all of that" is a tricky balance to strike
<__monty__> This visibility level thing seems particularly flawed though.
<emily> yeah that's not great
<__monty__> If the servers have to decide whether or not to show a post to someone, all anyone has to do to see things they're "not supposed to" is run their own server instance.
<ashkitten> it doesn't help that there isn't a great way for a server to communicate what it doesn't support
<__monty__> The semblance of privacy where there is none is particularly toxic.
<ashkitten> __monty__: well, assuming someone who is meant to see the post is also on your instance
<__monty__> You said these posts were federated over to gnu social servers though?
<ashkitten> right, if the post is addressed to someone on a gnu social server
<__monty__> Even within the same instance it sounds like the posts would be stored in cleartext. That's still a pretense of privacy.
<emily> that's a pretty wide definition of pretense
<emily> some degree of trust may be less than ideal, but it's not a dealbreaker
<emily> (trusting arbitrary servers is of course unreasonable, but two people both on instances run by people they trust – why not?)
<ashkitten> when you sign up on an instance it's assumed that you trust the admins of your instance
<ashkitten> when you talk to someone on another instance you know that an admin of their instance could read that if they are malicious
<__monty__> Except apparently most people didn't understand at all.
<ashkitten> if you don't want real privacy guarantees use matrix with e2ee
<__monty__> Hence the effectiveness of the FUD.
<ashkitten> people didn't understand the difference between a software not having support for post privacy vs actual malicious behavior
<__monty__> I hope that's a mistaken negation? Has Matrix e2ee been found to be vulnerable?
<ashkitten> sorry, yeah
<ashkitten> messed up that sentence
<ashkitten> if you want real privacy guarantees use matrix with e2ee
<__monty__> I guess I don't consider a communication between N people private if N + x, where x > 0, people can listen in.
<ashkitten> my point is, eugen didn't say that post privacy would have to be implemented in a server for it to work, so people thought the only reason post privacy was broken on other softwares was that the admins were actively publicizing their posts
<ashkitten> and it's not just about private communication (individually specifying recipients) it's about posts with followers-only visibility too
<__monty__> Thanks for the glimpse into the fediverse. Once again I have to say I've been discouraged from participating.
<ashkitten> shrug
<ashkitten> i think the problems have drastically decreased, at least in my circles
<ashkitten> ofc ymmv, but i think it's at least better than birdsite
<__monty__> The problem is a completely broken system built atop broken foundations by people who seemingly don't seem to care about what's important to me in such a system.
<emily> 22:19 <__monty__> I guess I don't consider a communication between N people private if N + x, where x > 0, people can listen in.
<emily> this isn't the same as disregarding all distinctions between the values of x
<emily> I'd ask if you ever use telephone calls but knowing the crowd maybe you'd bleed out to death before giving the emergency services your address :p
<__monty__> I don't participate on twitter. But that does have an undeniable network effect going for it.
<ashkitten> i think you're being a little overdramatic
<__monty__> Choosing to share private information is very different from being led to believe communication is more private than it really is, emily.
<emily> it is true that social software is not built for utmost privacy above all else
<emily> I think you'd prefer antisocial software, which exists, and is valid... but is never going to replace Twitter
<ashkitten> maybe you'd like scuttlebutt
<ashkitten> though i've heard it's very hard to implement the protocol in anything but javascript
<__monty__> I don't really care about replacing twitter tbh. Hence my apathy towards the fediverse.
<__monty__> I do like what I've seen of scuttlebutt more than what I've seen of the fediverse.
<__monty__> Can't imagine how being so tied to JS came about though. And that definitely sounds like a problem.
<__monty__> The social platform I like best is IRC, mainly freenode.
<ashkitten> i use matrix when i need privacy, i use fedi to talk to my friends more generally
<ashkitten> more like a forum (in the traditional sense of the word)
<__monty__> Thanks for the conversation. nn
<ashkitten> np
__monty__ has quit [Quit: leaving]
drakonis_ has joined #nixos-chat
tilpner has quit [Read error: Connection reset by peer]
tilpner_ has joined #nixos-chat
KeiraT has quit [Ping timeout: 240 seconds]
KeiraT has joined #nixos-chat
KeiraT has quit [Remote host closed the connection]
KeiraT- has joined #nixos-chat
KeiraT- is now known as KeiraT