Saturday, July 29, 2023
dev@conference.yunohost.org
July
Mon Tue Wed Thu Fri Sat Sun
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
           

[00:11:49] <Aleks (he/him/il/lui)> https://lwn.net/Articles/939568/
[00:12:02] <Aleks (he/him/il/lui)> Wooot ? O_o
[00:55:41] <Aleks (he/him/il/lui)> https://news.ycombinator.com/item?id=36914880
[01:14:55] <Aleks (he/him/il/lui)> https://kylechayka.substack.com/p/the-dream-of-the-personal-machine
[13:04:22] <autra> > <@Alekswag:matrix.org> https://kylechayka.substack.com/p/the-dream-of-the-personal-machine

interesting! But I'm not sure that any device could ever "urges its holder into new, unfamiliar places" 🙂 Or at least, never as e
[13:04:29] <autra> well as fellow humans!
[13:05:17] <autra> (who wants a philosophical debate on Saturday at 3pm?)
[13:06:15] <autra> > <@Alekswag:matrix.org> https://lwn.net/Articles/939568/

yup! I still don't know how I feel about that (I tend to favor message-passing instead of memory sharing when I do multi-threading dev in python anyway)
[14:29:21] <Aleks (he/him/il/lui)> but maybe one of the niche use case is AI / machine learning so still a big deal in terms of "being *THE* language" or something
[14:30:56] <Aleks (he/him/il/lui)> yeah i'm seeing quite a lot of comments on hackernews like "how actually useful is this" and it seems the no-GIL stuff is only useful for niche use cases where you want as little overhead as possible compared to regular multiprocessing or IO-intensive multithreading so like, yeah, to me the "no-GIL" thing sounds like something a lot of people ask about while not realizing that it's not a magic silver bullet and how dangerous it is
[17:11:12] <Yunohost Git/Infra notifications> [moulinette] @alexAubin pushed 2 commits to boring-login-api ([4104704a87b9...a6c7e55d1dcf](https://github.com/YunoHost/moulinette/compare/4104704a87b9...a6c7e55d1dcf))
[17:11:13] <Yunohost Git/Infra notifications> [moulinette/boring-login-api] api: Add a proper mechanism to allow specific, configurable CORS origins - Alexandre Aubin
[17:11:19] <Yunohost Git/Infra notifications> [moulinette/boring-login-api] api: fix authentication failure not deleting expired cookies - Alexandre Aubin
[17:15:58] <Yunohost Git/Infra notifications> [yunohost] @alexAubin pushed 3 commits to portal-api ([f69f87fa6583...09c5a4cfb91c](https://github.com/YunoHost/yunohost/compare/f69f87fa6583...09c5a4cfb91c))
[17:16:02] <Yunohost Git/Infra notifications> [yunohost/portal-api] portalapi: Add new yunohost-portal-api to yunohost services - Alexandre Aubin
[17:16:07] <Yunohost Git/Infra notifications> [yunohost/portal-api] portalapi: fix cookie not being deleted because maxage=-1 or something - Alexandre Aubin
[17:16:13] <Yunohost Git/Infra notifications> [yunohost/portal-api] admin and portalapi: propagate new configurable CORS mechanism from moulinette - Alexandre Aubin
[17:17:42] <Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#949486504](https://gitlab.com/yunohost/yunohost/-/pipelines/949486504) failed on branch portal-api
[17:19:51] <Yunohost Git/Infra notifications> [moulinette] @alexAubin closed [pull request #324](https://github.com/YunoHost/moulinette/pull/324): [fix] CORS Prefech OPTIONS
[17:19:51] <Yunohost Git/Infra notifications> [moulinette] @alexAubin [commented](https://github.com/YunoHost/moulinette/pull/324#issuecomment-1656793165) on [issue #324](https://github.com/YunoHost/moulinette/pull/324) [fix] CORS Prefech OPTIONS: Superseded by https://github.com/YunoHost/moulinette/commit/328107c94699074cd00692451fd55589c96f16f2
[17:19:52] <Yunohost Git/Infra notifications> [moulinette] @alexAubin deleted branch fix-cors-options
[17:20:35] <Yunohost Git/Infra notifications> [yunohost] @alexAubin closed [pull request #1484](https://github.com/YunoHost/yunohost/pull/1484): [wip] Enable CORS on API
[17:20:39] <Yunohost Git/Infra notifications> [yunohost] @alexAubin deleted branch api-allow-origin
[17:20:40] <Yunohost Git/Infra notifications> [yunohost] @github-code-scanning[bot] [commented](https://github.com/YunoHost/yunohost/pull/1387#discussion_r1278343716) on pull request #1387 WIP : New portal API to partially replace SSOwat: ## File is not always closed

File is opened but is not closed.

[Show more details](https://github.com/YunoHost/yunohos...
[17:20:40] <Yunohost Git/Infra notifications> [yunohost] @github-code-scanning[bot] [commented](https://github.com/YunoHost/yunohost/pull/1387#discussion_r1278343718) on pull request #1387 WIP : New portal API to partially replace SSOwat: ## File is not always closed

File is opened but is not closed.

[Show more details](https://github.com/YunoHost/yunohos...
[17:32:32] <Yunohost Git/Infra notifications> [yunohost-portal] @alexAubin pushed 1 commit to main: Update dev instructions ([136ad443](https://github.com/YunoHost/yunohost-portal/commit/136ad443f500cb36fb03a8bf56a2434a15a0192b))
[17:59:17] <cippr> Hello, it's been a while I don't login on the forum and i've just received a dozen summary mails from the forum since about 1 hour.
[18:01:07] <cippr> I've login the forum just to see if it could stop sending mails.
[18:17:29] <Yunohost Git/Infra notifications> Failed to run the source auto-update for : shiori. Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening! Debug log : http://paste.yunohost.org/raw/jaqowilelu
[18:22:20] <cippr> It seems to work : nothing for 30'.
[19:57:43] <lapineige> > <@Alekswag:matrix.org> yeah i'm seeing quite a lot of comments on hackernews like "how actually useful is this" and it seems the no-GIL stuff is only useful for niche use cases where you want as little overhead as possible compared to regular multiprocessing or IO-intensive multithreading so like, yeah, to me the "no-GIL" thing sounds like something a lot of people ask about while not realizing that it's not a magic silver bullet and how dangerous it is

Can someone summarize what's the big deal with no-GIL, in a word what's the proposal ? 🤔
[20:02:23] <Aleks (he/him/il/lui)> One of the main thing people complain about Python (despite that, as mention, maybe they don't realize it's not such a huge deal), is the lack of actual "threading" mechanism in Python for parallelization. This is because there's a thing called "Global Interpreter Lock" effectively preventing to have multiple threads running at the same time.

This doesn't mean that you cant do multithreading or that multithreading is useless in Python, because there are stuff like "I/O-intensive tasks" (such as downloading 100+ app logos in parallel) which can be done using multithreading ... but you can't run CPU-intensive tasks on multithreads because .. well, only 1 thread runs at a single time. You can however use multi-process perfectly fine (that is : computing stuff on several cores in parallel, as opposed to several threads inside a single core)
[20:04:35] <Aleks (he/him/il/lui)> yet still apparently people are still very much pushing to have CPU-intensive multi-threading capabilities in Python, which means removing the GIL mechanism (or making it optional), but that's just so fundamental that it's pretty hard to foresee the consequences. And such kind of parallelisation is actually hard, because all threads manipulates the same variable, and you can quickly end up in "race conditions" where some data gets partially modified, and ends up in disaster
[20:06:21] <Aleks (he/him/il/lui)> for example, take your bank account : when you send / receive money, there's actually too operations going on behind the scene : adding N € to one bank account, and removing N€ to the other bank account ... but somehow the code gets to "pause" between the two operations .. then for a short amount of time, you have a situation where you gained money out of nowhere and you could find ways to exploit this
[20:08:36] <Aleks (he/him/il/lui)> so it's not just about "remove the GIL and get free multithreading" ... so far *all* code in Python has been conceived under the assumptions that there is always one single thread running. If you drop this assumptions, then a load of funky stuff can start happening. And you possibly need additional technical bureaucracy to declare operations as being "atomic" (ie you can't "pause" the code during that operation), etc
[20:09:21] <Aleks (he/him/il/lui)> So TL;DR : this thing about dropping the GIL can legit feel like dangerous (both in technical and "human" terms, as in "adding complexity to a language supposed to be simple) only to satisfy niche applications
[20:10:00] <Aleks (he/him/il/lui)> but other people argue that it's actually not such a huge deal, at least not "that" massive to stuff that already happened in Python such as 32bits->64bits, unicode strings, etc
[20:53:37] <lapineige> Wow that was way longer than expected, thanks ^^ 🙂
(in particular, I never understood the multi-threads vs multi-process thing before ^^)