robryk @robryk@qoto.org
I enjoy things around information theory (and data compression), complexity theory (and cryptography), read hard scifi, currently work on weird ML (we'll see how it goes), am somewhat literal minded and have approximate knowledge of random things. I like when statements have truth values, and when things can be described simply (which is not exactly the same as shortly) and yet have interesting properties.
I live in the largest city of Switzerland (and yet have cow and sheep pastures and a swimmable lake within a few hundred meters of my place :)). I speak Polish, English, German, and can understand simple Swiss German and French.
If in doubt, please err on the side of being direct with me. I very much appreciate when people tell me that I'm being inaccurate. I think that satisfying people's curiosity is the most important thing I could be doing (and usually enjoy doing it). I am normally terse in my writing and would appreciate requests to verbosify.
I appreciate it if my grammar or style is corrected (in any of the languages I use here).
Joined Nov 2020
@skry @esther@strangeobject.space @vonneudeck@hachyderm.io
I guess they meant proton&co, the wrappers around wine that steam uses.
One thing that people do sometimes is that they self-boost toots that were unlisted (e.g. because they were deep in a reply chain under something unlisted), so that they appear once in the public timeline (and/or on their "toots" list instead of only "toots and replies").
("Unlisted" means technically that as:Public is not in the `to` field, but in the `cc` field.)
I'd've been really surprised if the warning were about cabin pressure itself. I rather expect that they were of the form "the pressurization system has to work way to hard to maintain this pressure difference, something is likely leaking there". I'll be curious to read the NTSB report when it comes out.
@koakuma Actually, I think one can do with just one shared "buffer", at least in the world where you can fit a counter of operations in half of the CAS word -- while filling the buffer, which is composed of <prev version, word> pairs, you CAS its elements so that you start failing if there was an intervening update.
Why do x-ray emitters present typical lamp current as an important metric? (E.g. on faceplate) Its relation to luminosity depends greatly on emitter geometry, so is emitter-specific.
@koakuma without memory linear in the number of threads that could be involved?
@bhaugen do your hearing aids support induction loop sound reception? If so, you can have the audio transmitted into a coil that you wear like a necklace. There are ready-made devices that do that, but making it yourself would only involve making a necklace coil of correct impedance.
I don't have any practical experience with these setups though, so might not know about some unobvious annoyances.
Usually squash and merge: when bisect points at a squashed commit or a merge commit one gets much less information (so merge is somewhat better than squash, because you _might_ get a commit on the merged-in branch as a result).
Rebase is much better, _as long as the project wants all commits on the main branch to actually build. If that's not the case, it's the worst (but then the notion of a commit as a version of the software is very degenerated anyway).
@b0rk A difference that was meaningful for me a few times is that they differ in the flavor and amount of suffering one gets to experience during bisection.
Zaufanie do SORów nie bierze się IMO z wyników, ale z (braku) nieuzasadnionych porażek. Jeśli to prawda, to to też jest jakaś postać zaufania do procesu a nie do samych skutków.
Zgadzam się, że skutki braku zaufania są inne (aczkolwiek wydaje mi się, że niedoszacowujesz te dla SORu).
Nie rozumiem za to, w jaki sposób sam proces decydowania o tym, czy czemuś ufamy jest w tych wszystkich sytuacjach różny (w wielu z tych pozostałych również mamy adwersarzy, którym zależy na zniszczeniu zaufania). Czy może chcesz powiedzieć, że ludzie generalnie by niezrozumiałemu systemowi ufali (dopóki nie mieliby podstaw[1] sądzić przeciwnie), ale skutki utraty zaufania są znacznie gorsze, więc akceptowalne ryzyko jest mniejsze?
[1] co do przykładu z USA -- nie wiem jak o nim myśleć, bo w tamtej okolicy następuje strasznie dużo przekonywania ludzi za pomocą absurdalnych stwierdzeń, którego nie umiem modelować (chociażby nie mam zbyt dobrego pojęcia o tym, co wpływa na to, które absurdalne stwierdzenia są bardziej przekonujące)
> Żeby głosowanie było godne zaufania, konieczne jest, by osoby głosujące rozumiały, jak system wyborczy działa.
Nie wiem, czy się z tym zgadzam, bo to nie jest standard, którego używamy w innych okolicznościach.
Popatrzmy na pogotowie ratunkowe i SORy. Pacjenci owych zwykle nie mają doświadczeń z osobami tam pracującymi, ani nie wiedzą wystarczająco dużo, żeby rozumieć ich postępowanie. Mimo to zwykle ufają, że instytucja pogotowia rękami swoich pracowników przeciwdziała ich śmierci lub poważnemu uszczerbku na zdrowiu.
Wydaje mi się, że takie podejście jest bardzo powszechne w naszych życiach (jednak często w sytuacjach, których regularność i charakter pozwala każdemu z nas zbudować zaufanie na bazie doświadczenia): raczej nie rozumiemy, jak to działa, że pedał gazu przyspiesza samochód, ale ufamy że tak jest. Podobnie z bezpiecznym przechowywaniem żywności, działaniem środków telekomunikacji, skutecznością ochrony pasażerów samochodów przed skutkami zderzeń.
Czy uważasz, że wybory są w jakiś sposób specjalne albo może źle rozumiem ten mechanizm (nadmiernie go generalizując?)?
@isomer For the average ratio to change, you don't need to change any of the averaged ratios but just their weights. They seem to say that the average churn changed and imply that those who use copilot have larger churn than they would otherwise have. There is at least one obvious alternative explanation to that (that those who use copilot had larger churn already, and now are just writing more code with the same churn) which is not obviously wrong.
Obv. they could be more precise somewhere in the whitepaper, but I find a result where the central point is implied without being stated outright very suspicious.
Code churn is a weird metric, because it is strongly affected by how commit-happy developers are (if you rewrite everything you write once, code churn will count it only if you commit it), which depends on e.g. code review practices. So, the effect on code churn (as described in the abstract, I didn't want to jump through the hoops to download the whole whitepaper) can be caused by e.g. organizations where code review standards are laxer increasing their code writing rate.
The style of documentation that describes what the author of the library wants people to try to do using the library is sadly quite common.
You still have such computers today: e.g. microcontrollers. Ones with external memory buses are rarer than they used to be though, so the next steps are larger.
@rooster@chaosfem.tw
Huh, what is the thing that becomes apparent only when you have larger amounts of heavy water? From things that aren't obviously related to density, I only know of the weird sweet taste but that can be tested on tiny quantities too.
I enjoy things around information theory (and data compression), complexity theory (and cryptography), read hard scifi, currently work on weird ML (we'll see how it goes), am somewhat literal minded and have approximate knowledge of random things. I like when statements have truth values, and when things can be described simply (which is not exactly the same as shortly) and yet have interesting properties.
I live in the largest city of Switzerland (and yet have cow and sheep pastures and a swimmable lake within a few hundred meters of my place :)). I speak Polish, English, German, and can understand simple Swiss German and French.
If in doubt, please err on the side of being direct with me. I very much appreciate when people tell me that I'm being inaccurate. I think that satisfying people's curiosity is the most important thing I could be doing (and usually enjoy doing it). I am normally terse in my writing and would appreciate requests to verbosify.
I appreciate it if my grammar or style is corrected (in any of the languages I use here).
Joined Nov 2020
