published refreshed chimera iso images this evening
most important and notable change: terminal icon more cute now
published refreshed chimera iso images this evening
most important and notable change: terminal icon more cute now
@domi @pj @wezm when your mirror is fast the parallel fetches don't really matter that much anymore and then the rest of it wins (especially considering apk fetches and installs at the same time)
@domi @pj @wezm sure, makes sense :)
apk is probably the fastest in general when it does not run into the download bottleneck
when using tmpfs bldroot, cbuild gets away with bootstrapping an entire build container in like ~1s and that's like 70 packages and 700MB (most of it is llvm being a big chungus though)
@psykose @CounterPillow this is not gnu style, gnu style indents code blocks by 4 while also indenting braces by 2 (on their own line) so you have braces half-indented between the declaration and body
@lnl it's called upstream because you constantly have to fight against it
"if the far right won in your country and you did not vote/voted for a small party/whatever it's actually a you problem and not a problem with that half the people in the country voted far right"
imagine unironically posting that kind of garbage
@mia in the end any access on vector is no different from a bunch of allocated memory, because that's all it is
where c++ vector actually suffers performance-wise is growth, because c++ allocators have no concept of realloc, which means you are allocating new data + copying + freeing the old each time the capacity increases (in practice it does not matter too much)
@mia unless your stdlib is compiled with assertions, the operator[] is no different from the array syntactic sugar, because it just gets inlined from the header
e.g. this is the definition from libc++ https://gist.github.com/q66/2f3d394637b72e2b8130d96fc1a1a350 and it's in the header obviously, not in the library, since vector is a template class
@mia destroy all computers
@lanodan @psykose @vyivel you don't need to do that, just don't put pointless/annoying obstacles in potential contributors' way and all is good
@vyivel @psykose i've had a 1 line UB fix in libseccomp pending for like a year now because of their dumbass "policy"
@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner this is super funny to me because
1) have you been to the devuan forums? if not i suggest taking a look
2) ftr i strongly dislike systemd and am actively driving efforts to have properly portable session tracking and the likes without nasty and deficient workarounds like elogind
any accusation against me that i'm a part of some kind of ibm conspiracy is both hilarious and sad
@domi @lanodan just recolor the splash with purple and yellow
then it's a nonbinary blob
@dashdsrdash @jnpn @apicultor @ariadne @bremner yes just like approximately 98% of people who smugly trashtalk systemd
@Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner what is devuan doing other than endlessly holding onto shellscripted boomerware in their 2010-ass distro and building a community of chuds and flatearthers
(well, to be fair, they did write a libseat support patch for xorg, but i can't really think of anything else)
@apicultor @Okanogen @dashdsrdash @jnpn @ariadne @bremner my experience with devuan community has included a larger than usual proportion of people like https://dev1galaxy.org/viewtopic.php?pid=36804#p36804 and https://dev1galaxy.org/viewtopic.php?pid=36792#p36792
@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner anyway, apologies if i was antagonistic in this discussion - i never intended to aim that at you or anybody interested in good faith discussion, and i've had a lot of bad experiences with people around your distro, and am a bit cranky due to my disappointment with the whole situation... so sorry :)
@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner ftr i'm not even talking about most users here because users don't have any such obligation (and most don't have the knowledge) and it's perfectly fine to be dissatisfied with how things are
but there are also many people who could be doing it and choose not to
@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner a rc-style daemon has to do significantly more things:
a supervised process just runs and has to do nothing (it will become a child process of the service manager and the service manager will be aware of its entire lifetime)
a "traditional" daemon has to fork, then setsid(), then usually fork again, and tracking it becomes impossible as a result
@wyatt8740 @Okanogen @dashdsrdash @jnpn @apicultor @ariadne @bremner that leads to scenarios like "you have a daemon, said daemon dies, service manager doesn't know that, something else subsequently takes over its pid, service manager tries to do something with it, suddenly is manipulating an entirely wrong process"
pidfile tracking is just extra fragile
and the whole rc infrastructure around it is hardly simple at all (do you know how all that stuff actually works?)
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.