Extrapolated from the relevant information in the post (a single data point), that is a solid hypothesis.
I do my time tracking in org-mode, and export it to JIRA once a day or so. It is quite a specific/tailored setup, written in a mix of elisp and, well, org-mode (specific names and tags are used to configure some settings), but I'd love to look at this tool to see if I can extend my workflow by using it for the "massaging into a nicer shape" part. I might end up writing some extensions for either side (org-mode input format and JIRA REST calls output format).
My current tooling quantizes everything by rounding start and end times to the nearest full 15 minutes, and starting a new task at the end time of the previous one when clocking in, so that my team lead does not have to report so many fractions of hours to higher layers.
Die drie seconden dat je denkt dat het om een sequoia gaat.
Something like tac | head | tac, I guess? Yes, that's a valid use case indeed :)
I mean... it's nice that it exists and all, but I can't really think of many useful usecases.
Heh, no, but they do have a nice set of man pages and other documentation online. I prefer NixOS. Easier keeping track of configuration, easier rolling back of (and experimentation with) new stuff.
I don't think their "No" was a disagreement, but a confirmation of your second line. https://ell.stackexchange.com/questions/88502/how-to-agree-with-a-negative-statement-with-yes-or-with-no Sometimes, language can be a tricky tool to wield.
I wonder if there is a point where the graphs of "perceived effect on the water" cross for both this experiment and homeopathy, and what that means.
Probably understood that in the wrong direction. Ze (eng. phon.) would be spelled more like "sie" (ger. phon.) and would sound like "the" with a German accent. They would become either dey (eng. phon.) or zey (eng. phon.), spelled like "deej" or "seej" (ger. phon.), or even without the y (or j) at the end.
I think. I'm neither native German or English.
As Flatfire mentions, another issue can arise if plugins can modify the config. I assumed config to be read-only for the software, only editable by the admins, and never by the tools themselves.
I'd try to share the config space as much as possible. Options 1 and 3 make sense then.
What feels "right" to me, when using NixOS and its module system, is that all config has the same shape, and is therefor easily moved to a different section, or to a section that is shared by a subset of plugins.
Con: It could lead to bad practices like strengthening dependencies between plugins (if they hard code to use a specific config option of another plugin).
Pro: But if you can discourage that, or use "deprecated pointers" to the new location of an option, the ease of moving shared config options to a more generic level can make it easier to maintain the total configuration. Developers of the separate plugins can build on what others have already done, and even synergize functionality (add a convenient integration if they see another option configured).
If some options are "secret", though, and you don't want those shared, they should either be in their own config (easier), or you'd need some access control on the configuration storage/file for each plugin (more work). Allowing a plugin to have a separate file for credentials, for instance, could be a good choice.
Een vriend vertelde me een opmerkelijk feitje: alleen bij tijdseenheden die eindigen op een r is het correct om ze in enkelvoud te houden, ook al heb je het over meerdere. Bijvoorbeeld: mijn moeder is 42 jaar. Ik ben er over 3 kwartier. De marathon duurde 24 uur.
Ondanks dat hij dit feitje leerde van een leraar die goed aangeschreven stond en gepromoveerd was op de Nederlandse taal (details helaas vaag want herinnering van een aantal jaar geleden), zegt mijn gevoel dat dit niet aan die "r" kan liggen.
Nou is het mij niet gebruikelijk, maar ik hoor wel eens: mijn dochter is 7 maand. En we gebruiken bij andere tijdseenheden ook wel eens enkelvoud: ik wandel een kilometer in 7 minuut 20. Daarnaast zijn andere eenheden ook niet altijd in meervoud: ik weeg 70 kilo. Een veld van 100 hectare. Dat kost dan 9 euro.
Wat zijn jullie gedachten hierover? Is de "r" aan het eind slechts een ezelsbruggetje en ligt de oorzaak van het behouden van de enkelvoudsvorm in een andere eigenschap van het woord of de context (nadruk op telbaarheid of juist niet)?
Ik zie veel kommentaar van mensen die denken dat (de)federeren met Meta te maken heeft met privacy. Wel, ja en nee. Als ik het goed begrijp betekent federatie dat we de inhoud van onze communities syncen met die van de andere server, dus we maken het wel makkelijker, maar die data is toch wel publiek. Waar ik eventueel bang voor ben is dat Meta "voorstelt" om ActivityPub "voor het gemak" of "voor efficiëntie" uit te breiden met synchronizatie van private messages of andere zaken die meer en meer van onze privacy vragen.
Natuurlijk, dat hoeft niet iedereen te doen, maar reken maar dat de gemiddelde Meta-gebruiker daar minder moeite mee heeft en er zo meer druk komt op Lemmy om dat comfort ook maar te gaan bieden (vanuit nieuwe gebruikers of dergelijke).
Ik zie veel kommentaar van mensen die denken dat (de)federeren te maken heeft met de inhoud en kwaliteit van de communities van daar, en het gedrag van de gebruikers van Meta. Wel, ja en nee. In het fediversum zou idealiter iedere instantie opgebouwd zijn rond een kleinere gemeenschap met gemeenschappelijke interesses of belangen. Interesse of belangen die dan gedeeld worden met naburige instanties, kunnen dan ook gedeeld worden door federatie. Het idee zou niet zijn "alle gemeenschappen bereikbaar op alle instanties". Lemmy (en ActivityPub) is niet decentraal zoals bv bitcoin, waarbij iedereen een kopie van alles krijgt om te voorkomen dat "bad actors" informatie kunnen corrumperen of vernietigen. Het is gefedereerd, en dus niet één enkele globale gemeenschap maar meerdere kleine die met elkaar kunnen delen.
Threads klinkt als één grote hoop van alle wereldwijde gebruikers, de grote online webshop waar iedereen die ermee federeert omheen gaat moeten cirkelen om te kunnen blijven voldoen aan de grote vraag naar zaken die daar gebeuren, om te concurreren met de daar geboden prijzen (features), en die sommige zaken véél beter kan dan de kleine servertjes die elke losse gemeenschap zelf in beheer heeft.
Om die vergelijking door te trekken: Lemmy is bedoeld als de gezellige winkelcentra in het dorp of nabijgelegen steden. Het "comfort" en gemak en de prijzenconcurrentie die grote supermarktketens en webshops te bieden hebben leggen zo'n grote belasting op de kleine zaken dat die geen schijn van kans maken als ze zich inbeelden dat ze daarmee kunnen dansen.
Als we de deur openen naar grote gecentraliseerde instanties, die hun macht en invloed vast en zeker zullen aanwenden om groter te worden (meer gebruikers, meer advertenties, meer winst, aard van het beestje), geven we Lemmy geen kans om de voordelen te laten zien die de lokale gemeenschappen bieden. We worden "het mislukte hobbyproject dat hetzelfde doet als Threads of Twitter of Reddit, maar niet mee kon" in plaats van "de plek waar het gezellig is, waar elke instantie zijn eigen kleur of cultuur heeft, of <voeg hier meer voordelen van een gefedereerde structuur in, ook degene die we nog gaan ontdekken>" in de ogen van de niet-techneut.
De keuze om te (de)federeren in ActivityPub heeft te maken met het beheer van de andere instantie. Als die slecht beheerd is, bots toelaaat, het netwerk onevenredig belast, of een bron is van spam, dan defedereer je. Het gaat niet om de inhoud of om censuur (iedereen kan er een account aanmaken die het wil), het gaat om het willen koppelen met, en openstellen van je eigen server aan de grillen of goed beheerderschap van de andere server. Mijns inziens is het vertrouwen in het beheer van Threads, en de doelstellingen om gelijkwaardig te zijn en te blijven in een gefedereerde samenwerking met Meta te laag om ons daarvoor open te stellen.
Laten we focussen op de sterke kanten van het fediversum en niet federeren met een gemodereerde "niet te goeder trouw"-instantie. Laten we op een natuurlijke manier groeien, het opzetten van meerdere kleine instanties bevorderen (en met die federeren en ze supporten) in plaats van alles naar een grote opperbeheerder te laten graviteren omdat het eenvoudiger is om één account te hebben dan een extra account dáár aan te maken. Threads is geen fediversum.