Gotten myself both a large-screen Kobo Elipsa 2E, which does wonders with KOReader. Haven't used the pen much though, since that's not what I got the device for.
Also got myself an Xteink X4 and loaded it with the crosspoint firmware, which does amazingly for some casual reading on the go.
Been using Yggdrasil for quite a while at this point, both for encrypted service communication and also as unbreakable VPN links to various places where I don't want to have to mess about with NAT traversal.
It's been nice to be able to just drop it onto my router, add an ALFIS DNS entry, and have all my devices just work with Yggdrasil with no additional configuration.
I'm holding off on Fluxer until they decide how they're going to implement federation, since the designs they've communicated publicly so far have all seemed like they prioritize siloing and putting excessive load on self-hosted nodes.
Their first proposed solution would've required each self-hosted server to be able to handle every user on every other server in the network - a proposal which they've since scrubbed from their page.
The latest proposal I can find at least speaks about aggregating connections through the users server, so it's not as insane (Only requiring each self-hosted server to be able to handle requests from every other server on the network). But it still forbids intelligent caching, and instead seems to consider recommending the use of cloudflare to reduce the load from their design to be a good solution.
I made an NFC/QR code card for my wifi details at home, and that also includes the details written in clear text on the card, since some devices simply don't do QR (or NFC in my case).
It doesn't really solve my use-case, since we do a combination of direct stream when possible, as well as local sync/cache but only for transcoding purposes. As well as local users only, with the federated sharing taking care of permissions, so that we don't transfer user information between eachother.
Jellyswarrm is certainly a lot closer than other solutions people have suggested though.
Det är värt att notera att upphovsrättsfri kod inte alls behöver vara open-source, för det är ett begrepp med djupare betydelse än bara att den underliggande koden går att få tag i.
Sen så är ju ett av de största problemen med AI-generering specifikt runt datakvalitén, något som man vanligtvis inte hade något problem med i traditionell maskinlärning, eftersom dataset:en som användes för det var väl kuraterade. Om det fanns minsta chans till dåliga värden i traditionella dataset:et så kastades det och byggdes om, eftersom man ville få kvalitativa resultat.
Inte som dagens AI som istället desperat lärts med allt som kunnat skrapas från internet.
Moderna varianterna här verkar mer fokuserade runt idén att dränka skräpet i mängden data. Men det finns inte något sätt att i efterhand ta bort input-data ifrån en modell när det väl lärts in i den, utan att behöva rulla tillbaka hela modellen till innan det lärdes in. Så allt vi kan veta idag är att alla publika AI modeller garanterat har skräp i sin lärodata, och därför också garanterat kommer generera skräp. Det enda vi inte är lika säkra på är procenten av det de genererar som kommer vara skräp - eller baserat på skräp.
Jag har sett folk kunna använda AI för att generera data som inte är felaktig, men det har också krävt att personen i fråga har nog med kunskap i ämnet för att veta vad som är skräp och vad som är kvalitativ data, något som verkligen inte är en garanti.
Speciellt på projekt som försöker förklara sig som FOSS när de är till huvuddelen AI-genererade så lämnar det här en extremt dålig smak i min mun, för det lutar extremt åt hållet att personen som rattat AI:n inte vet vad de håller på med.
Jag tar mycket hellre och kör genererad kod om personen som tillhandahåller den också noterar att den är genererad och därför saknar garantier, samt inte bör försöka läsas av människor eller användas för FOSS verksamhet, för det antyder iallafall att de vet hur verktyget de använt fungerar.
Jag har läst nog mycket AI-genererad kod för att inte våga lita på programvaror där AI är en huvudförfattare. Om någon har kopierat ihop koden för hand så har de iallafall gjort aktiva val runt kodstyckena som valts ut, och så finns det någon form av domänkunskap i hur alla kodstyckena är hopkopplade i den slutgiltiga programvaran också.
Med genererad kod finns det varken någon sådan domänkunskap, och inte heller någon kvalitékontroll på kodstyckena som använts för att skapa slutresultatet.
Sen så är ju AI-generering inte direkt kompatibelt med foss heller, varken licensmässigt eller som ren gemenskapsfråga.
Nostr är byggd kring att data rekommenderas att spridas över många reläer, vilket ökar - men också naturligt balanserar - lasten, och eftersom varje relä lagrar datan så kan de alla skicka ut den till klienter också. Olika NIP:ar hanterar grupper olika i protokollet, men alla har någon idé runt att många reläer kan hantera samma grupp. Och användare kan nås över flera olika reläer samtidigt också.
Fluxers beskrivna design däremot kräver att all data för en specifik användare eller rum måste skickas till och läsas av just den noden som 'äger' användaren eller rummet, vilket betyder att oavsett vilket relä du går igenom i deras "federering" så kommer all datan i slutändan gå mot samma nod, vilket centraliserar lasten.
Edit:
För att beskriva lite djupare runt problemet;
Anta att jag har en nod som heter 'a, och det finns fem servrar/reläer A, B, C, D, och E. Anta sedan att varje relä har 50 användare som är intresserade av mina meddelanden. (d.v.s. i Nostr har en subscription, och i Fluxer är med i rummet)
Jag skickar nu meddelandet "Hej" med min nod.
Med Nostr så går det meddelandet ut till de reläer jag pekat ut (A-E i det här fallet), och varje relä tar sedan och vidarebefodrar det till de användare som är intresserade. Min nod - 'a skickar då ut fem utgående meddelanden, och varje relä A-E skickar sedan ut kopior av meddelandet till sina 50 användare.
Totalt har min nod hanterat en förfrågan - skicka meddelandet "Hej", och skickat fem utgående meddelanden till federeringen.
Om jag nu gör samma sak i Fluxer; D.v.s skriver meddelandet "Hej" i ett rum i min nod.
Då kommer det meddelandet gå till min nod - 'a - som kommer skicka ut det till varje användare på varje server/relä, (A-E) eftersom jag äger meddelandet. Så min nod 'a kommer då behöva skicka 50 kopior till användarna i A, 50 kopior till användarna i B, 50 kopior till användarna i C, etc...
Totalt har min nod fortfarande bara hanterat en förfrågan - skicka meddelandet "Hej", och sedan skickat 250 utgående meddelanden om detta till alla intresserade användare.
Om en av reläerna - säg A - nu helt plötsligt förlorar länkar för sina användare, på ett sådant sätt så att de måste läsa om datan.
För Nostr kommer det då betyda att A behöver skicka ut 50 nya meddelanden till användarna som är ansluta till den med den existerande kopian. Min nod 'a märker inte detta alls.
För Fluxers beskrivna design däremot så har inte A rätt att lagra mitt meddelande, så alla användare i A måste nu få en ny kopia av meddelandet, vilket betyder att min nod 'a behöver skicka ut de 50 kopiorna igen.
Nu har jag då med Nostr fortfarande bara skickat 5 utgående meddelanden totalt, men med Fluxer har jag behövt skicka 300, och kommer också behöva fortsätta skicka fler kopior allt efter tiden går.
Gotten myself both a large-screen Kobo Elipsa 2E, which does wonders with KOReader. Haven't used the pen much though, since that's not what I got the device for.
Also got myself an Xteink X4 and loaded it with the crosspoint firmware, which does amazingly for some casual reading on the go.
Been using Yggdrasil for quite a while at this point, both for encrypted service communication and also as unbreakable VPN links to various places where I don't want to have to mess about with NAT traversal.
It's been nice to be able to just drop it onto my router, add an ALFIS DNS entry, and have all my devices just work with Yggdrasil with no additional configuration.
I tend to go for House, DnB, or Electro Swing when coding. Something upbeat and with a steady rhythm.
No, the Rust standard library only contains functions useful for standard Rust, not POSIX/Linux user-space -specific functionality from libc.
Because it's a rust implementation of coreutils, and not a rust implementation of coreutils and libc?
Well, Valve did a randomization of the order queue. So your account value really shouldn't matter
I'm holding off on Fluxer until they decide how they're going to implement federation, since the designs they've communicated publicly so far have all seemed like they prioritize siloing and putting excessive load on self-hosted nodes.
Their first proposed solution would've required each self-hosted server to be able to handle every user on every other server in the network - a proposal which they've since scrubbed from their page.
The latest proposal I can find at least speaks about aggregating connections through the users server, so it's not as insane (Only requiring each self-hosted server to be able to handle requests from every other server on the network). But it still forbids intelligent caching, and instead seems to consider recommending the use of cloudflare to reduce the load from their design to be a good solution.
I made an NFC/QR code card for my wifi details at home, and that also includes the details written in clear text on the card, since some devices simply don't do QR (or NFC in my case).
Someone pulled some DRAM cost graphs, and with the >500% increase that's happened, the Deck did have to rise at least $200 to remain viable.
We really can't have nice things, first crypto and now AI insanity is really doing its best to remove computing as an affordable hobby.
It doesn't really solve my use-case, since we do a combination of direct stream when possible, as well as local sync/cache but only for transcoding purposes. As well as local users only, with the federated sharing taking care of permissions, so that we don't transfer user information between eachother.
Jellyswarrm is certainly a lot closer than other solutions people have suggested though.
The lack of library sharing is what's keeping me on Plex.
The ability to watch media across servers, and even transparently pull it for local transcode when necessary is just an amazing feature.
And it's not even just the people traveling here from the future trying to do it, it's also travelers from the past.
Det är värt att notera att upphovsrättsfri kod inte alls behöver vara open-source, för det är ett begrepp med djupare betydelse än bara att den underliggande koden går att få tag i.
Sen så är ju ett av de största problemen med AI-generering specifikt runt datakvalitén, något som man vanligtvis inte hade något problem med i traditionell maskinlärning, eftersom dataset:en som användes för det var väl kuraterade. Om det fanns minsta chans till dåliga värden i traditionella dataset:et så kastades det och byggdes om, eftersom man ville få kvalitativa resultat.
Inte som dagens AI som istället desperat lärts med allt som kunnat skrapas från internet.
Moderna varianterna här verkar mer fokuserade runt idén att dränka skräpet i mängden data. Men det finns inte något sätt att i efterhand ta bort input-data ifrån en modell när det väl lärts in i den, utan att behöva rulla tillbaka hela modellen till innan det lärdes in. Så allt vi kan veta idag är att alla publika AI modeller garanterat har skräp i sin lärodata, och därför också garanterat kommer generera skräp. Det enda vi inte är lika säkra på är procenten av det de genererar som kommer vara skräp - eller baserat på skräp.
Jag har sett folk kunna använda AI för att generera data som inte är felaktig, men det har också krävt att personen i fråga har nog med kunskap i ämnet för att veta vad som är skräp och vad som är kvalitativ data, något som verkligen inte är en garanti.
Speciellt på projekt som försöker förklara sig som FOSS när de är till huvuddelen AI-genererade så lämnar det här en extremt dålig smak i min mun, för det lutar extremt åt hållet att personen som rattat AI:n inte vet vad de håller på med.
Jag tar mycket hellre och kör genererad kod om personen som tillhandahåller den också noterar att den är genererad och därför saknar garantier, samt inte bör försöka läsas av människor eller användas för FOSS verksamhet, för det antyder iallafall att de vet hur verktyget de använt fungerar.
More expensive than the base-level Xbox/PS controller, but cheaper than their pro-version - as well as the Joy-Con 2s.
I'm down for it, nobody else is doing trackpad controllers after all.
Jag har läst nog mycket AI-genererad kod för att inte våga lita på programvaror där AI är en huvudförfattare. Om någon har kopierat ihop koden för hand så har de iallafall gjort aktiva val runt kodstyckena som valts ut, och så finns det någon form av domänkunskap i hur alla kodstyckena är hopkopplade i den slutgiltiga programvaran också.
Med genererad kod finns det varken någon sådan domänkunskap, och inte heller någon kvalitékontroll på kodstyckena som använts för att skapa slutresultatet.
Sen så är ju AI-generering inte direkt kompatibelt med foss heller, varken licensmässigt eller som ren gemenskapsfråga.
Bara lite synd att Fedibook är byggt med AI.
I'm really happy to see a piece of news about "... your companion for ..." and it not being about yet another soulless LLM chatbot.
Med vissa skillnader och begränsningar.
Nostr är byggd kring att data rekommenderas att spridas över många reläer, vilket ökar - men också naturligt balanserar - lasten, och eftersom varje relä lagrar datan så kan de alla skicka ut den till klienter också. Olika NIP:ar hanterar grupper olika i protokollet, men alla har någon idé runt att många reläer kan hantera samma grupp. Och användare kan nås över flera olika reläer samtidigt också.
Fluxers beskrivna design däremot kräver att all data för en specifik användare eller rum måste skickas till och läsas av just den noden som 'äger' användaren eller rummet, vilket betyder att oavsett vilket relä du går igenom i deras "federering" så kommer all datan i slutändan gå mot samma nod, vilket centraliserar lasten.
Edit:
För att beskriva lite djupare runt problemet;
Anta att jag har en nod som heter
'a, och det finns fem servrar/reläerA,B,C,D, ochE. Anta sedan att varje relä har 50 användare som är intresserade av mina meddelanden. (d.v.s. i Nostr har en subscription, och i Fluxer är med i rummet)Jag skickar nu meddelandet "Hej" med min nod.
Med Nostr så går det meddelandet ut till de reläer jag pekat ut (
A-Ei det här fallet), och varje relä tar sedan och vidarebefodrar det till de användare som är intresserade. Min nod -'askickar då ut fem utgående meddelanden, och varje reläA-Eskickar sedan ut kopior av meddelandet till sina 50 användare.Totalt har min nod hanterat en förfrågan - skicka meddelandet "Hej", och skickat fem utgående meddelanden till federeringen.
Om jag nu gör samma sak i Fluxer; D.v.s skriver meddelandet "Hej" i ett rum i min nod.
Då kommer det meddelandet gå till min nod -
'a- som kommer skicka ut det till varje användare på varje server/relä, (A-E) eftersom jag äger meddelandet. Så min nod'akommer då behöva skicka 50 kopior till användarna iA, 50 kopior till användarna iB, 50 kopior till användarna iC, etc... Totalt har min nod fortfarande bara hanterat en förfrågan - skicka meddelandet "Hej", och sedan skickat 250 utgående meddelanden om detta till alla intresserade användare.Om en av reläerna - säg
A- nu helt plötsligt förlorar länkar för sina användare, på ett sådant sätt så att de måste läsa om datan.För Nostr kommer det då betyda att
Abehöver skicka ut 50 nya meddelanden till användarna som är ansluta till den med den existerande kopian. Min nod'amärker inte detta alls.För Fluxers beskrivna design däremot så har inte
Arätt att lagra mitt meddelande, så alla användare iAmåste nu få en ny kopia av meddelandet, vilket betyder att min nod'abehöver skicka ut de 50 kopiorna igen.Nu har jag då med Nostr fortfarande bara skickat 5 utgående meddelanden totalt, men med Fluxer har jag behövt skicka 300, och kommer också behöva fortsätta skicka fler kopior allt efter tiden går.
What I'm hearing here is that they really need to build a flatpak, so there's a sane install method for it.