Juniper
Just your average being, of some form.
Chipped in a bit myself, regardless of the fact I’m self hosting. I really like what I’ve seen on Beehaw so far, and the admin teams communication has been stellar. Happy for it to become the “large instance” I interact with most!
Not sure if you got it sorted or not, but if you were following the docker-compose method documented by the devs, there were a couple hurdles I ran into. The one that may be relevant here is that at some point their docker-compose.yml did not expose the Lemmy backend to the Internet, and so all federation was failing. That said, I checked just now and they seem to have fixed that issue upstream. So you should be able to re-pull their docker-compose.yml and it should work.
As someone who went from FOSS -> Apple -> FOSS, I fully understand the love people have for the Apple ecosystem. In terms of proprietary hardware and software, they have a sheen and an inter-operation between their products that is genuinely unmatched.
That said, what ultimately pushed me out and back to Good Ole FOSS™ was the lack of any control, and the lack of any transparency. The idea of trusting a for-profit company with anything beyond my email address and sometimes phone number is just something I dislike doing. Apple’s processes are extremely opaque, and the last thing they want to give users is any control over their products, it’s an antithesis of what I desire from digital electronics.
As for if non-technical people should look into FOSS. I think FOSS can really give people a fundamental baseline of digital computing, and in the modern world such a baseline is extremely valuable. If they decide afterwards they prefer their proprietary ecosystems, Apple or otherwise, that’s their prerogative and there’s absolutely nothing wrong with that.
This is correct, however it is important to note that the C standard allows arbitrary values at the beginning of the program. The manpage does a better job explaining it.
Doing a bit of research, it looks like the POSIX time_t time(time_t *dest) function (man) is available on Windows (see here). So I would recommend that over clock_t clock(void) as it will operate more consistently across platforms.
Professional on a haitus here. Fully self taught, done a ton of hobby projects, most of my fleshed out ones being in either C89 or C99. Most recently has been a calculator application for myself in X11 too brush off the rust on my X11 knowledge, as well as a Lemmy client library for C.
Using clock() solely for delta values is absolutely a valid approach, as stated. The issue is that clock_t may not be large enough of some systems to safely keep you from an overflow, especially with arbitrary values. Additionally, some systems will include the time children processes were alive in subsequent clock() calls, furthering possible confusion. These are reasons why I would avoid clock() in favor of time(), even though your concerns are absolutely valid.
At the end of the day you have to determine which style of unpredictability you want to work around. Dealing with the times(), clock(), and clock_gettime() class of functions opens you up to managing what the kernel considers time passed, and what is accumulated vs what is not. While using time() can have shifts in time according to upstream NTP servers, as well as daylight savings time.
I would also make the argument that if an NTP server is adjusting your time, it is most likely more accurate than what your internal clock (CMOS or otherwise) was counting, and is worth following.
I agree with a lot thats been said in this thread. But I think a lot of it has to do with speed as well. The worlds moving so fast for so many people a break in their habit/routine too large a deal to manage.
Admittedly I also believe this acceleration of the world is intentional by the 1%, if not for this push for anxiety, just for increased perceived productivity. But those who are unable to slow themselves down will smash into changes in their daily lives much harder than those who can, and I think a lot of people are losing that ability due to technology and modern socioeconomic factors.
The infographic on carbon emissions per style of bicycle, with cars as the (predictably) most damaging bar on the graph is very interesting. I hadn’t anticipated materials in manufacturing to make quite this intense of a difference. Makes me glad I bought a 1980s steel frame junker that I maintain and repair as issues crop up, but that kind of “project bicycle” isn’t for everyone, let alone the compatibility issues driven by companies (likely to increase profit).
Something to keep in mind as I recommend bicycles to people who may not be as affectionate towards old beat up projects as I.
It was expressly against her will as per her own words. And as for why “a woman”, its rather well known women already deal with much more sexual harassment and maltreatment online than men do. Just look at the market of AI generated porn of celebrities and online personalities as proof of this. So forcing a woman, who already has a public presence no less, to manage a platform such as OnlyFans, and constantly see and have to manage sexual objectification and harassment towards her as well as her coworkers, is unacceptable in my opinion.