juni

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.

This just serves as another reminder that I need to finish reading SICP. But that said, I think this brings up some very interesting points. The example provided of DRY is focused on what is happening on a human/company level, while the abstraction barriers provided focus heavily on what is happening on a software level. This is a differentiation that I feel like is extremely important when programming robust, maintainable software. You cannot let non-software related terminology seep into what is fundamentally, well, software.

When you let non-software terminology work its way into software, the software has to start making assumptions. What is a C level employee? What bonuses do they require? Are these things subject to change? The list goes on. But if you approach the problem with software first and foremost, it is clear that all is happening is a variable bonus is added to an employees compensation. It is not this layers problem what that value is, nor is it this layers problem who is being compensated. That is all concerns for a DB layer (of some form) somewhere up the chain. All the financial layer cares about is applying the calculations.

So I don't feel like this is really a case against DRY, as much as it's a case against using non-software terminology and applying non-software assumptions to what is fundamentally, software. The arguments for maintaining independent layers is also important, but if you're thinking fully in terms of software operation, I feel you can more comfortable determine when layers can be interlinked.

My goodness that is the chromest thing I've ever seen, I love it! If it's restored properly and it feels smooth while riding it, I'd say it would definitely be a fun cruiser.

Calling OpenBSD "ducked taped together" feels rather crassly inaccurate. I won't pretend it's particularly modernized, but thats not a requirement for a lot of people using it. For many use cases, including many of mine, OpenBSD is easily the most consistent and quality Unix environment out there.

OpenBSD has, for a very long time, had their own isolation features, and have their own implementation of a myriad of modern kernel functionality. What they explicitly do not have is clones of Linux syscalls, which is why things like Docker (and Wayland, for that matter) do not work. And while unfortunate, I do not believe every Unix-like should be forced to imitate the Linux syscall API, as that is exactly what leads to the "duct taped" feeling other Unix-likes suffer from.

That said, I also do not blame FOSS developers for deprioritizing OpenBSD as a platform, as it is one of the smallest actively maintained Unix systems, and time is not infinite.

Same here, everytime I ever saw reddit in my search results I'd audibly sigh. How they've managed to make their user experiences so extremely hostile is beyond me.

I want to second this, should definitely ask a bike shop to try some out and get a feel for what will suit you.

After that its up to budget and time investment. You can get pretty good bikes for pretty cheap used, but of course they may come with some work to do. And if you can afford new and prefer a low time investment option, then that is at least equally as good!

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.

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.

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!

Couldn't agree more. Actually feel like I can contribute here, unlike on Reddit. Helps that Lemmy allows me to selfhost, which really helps my anxiety!

Absolutely, that is a far more eloquent way to put it! It's very freeing in it's own way.

Awh, I see! That would definitely be a nice feature to see.