Just your average being, of some form.
They state they take inspiration from Tor and IPFS, so there are added transport layers below the top layer “P2P” that obfuscates ones IP address. It’s nothing new really, and I’m honestly not sure what the advantages are over something like I2P, which largely doesn’t suffer from Tor’s issues of node ownership as there are no guard or exit nodes to own (unless expressly configured), while also being faster overall.
The fact they’re still hiding their testing methodologies behind floatplane makes me dubious of how effective this “housekeeping” week will be. Not that I plan on watching or interacting with anything LMG related going forward until the allegations brought up by Madison are properly handled anyway, in which then my final decision will be made.
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 also 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.
Most of my hobby programming is in ANSI C and C99, so I’m unfortunately far too aware of the weird and counter-intuitive things the C and POSIX standards say. :P
clock() is fantastic for sub-second timings, such as deltatimes in games, or peripheral synchronization, which matches the use case you mention very well. I recommended time() over it as OP’s use case is for calculating the amount of hours a user has had their software open, and unix timestamps are the perfect mechanism to do that in my opinion.
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.
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.
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 comfortably determine when layers can be interlinked.
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.
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!
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.
Excuse me if I misunderstood, but isn’t that the purpose of the “Subscribed” and “All” feeds on the home page of whichever instance you have an account on? Or do you mean some form of auto-discoverability?
Understandably so, I think haha. But for me, abandoning my car has made me actually realize distances in my city. Relying on a car, I barely even considered the distances I was traveling, and how necessary or not they were. I was more concerned about where I could park the thing than how far I was traveling just to do errands. But on a bicycle (and just walking), the first thing I do is consider the route, and distance, and I came to realize a lot of the distances I thought are best driven are… extremely walkable, or bikeable. And the distances that are a little far for a bicycle (in my current shape), I questioned why I even need to go that far. Especially if you’re in a city, there are a ton of businesses everywhere, it was easy to look for and find closer alternatives.
So I guess for me personally, it really helped me contextualize the distances I was actually traveling, and helped me more concretely view my city and what’s around me, compared to just driving through liminal spaces until I reach whichever destination I was headed towards.
Out of curiosity, could you clarify “close proximity”? Because I certainly agree a bike is not viable if you are in the countryside. However having switched to bicycling and no longer driving my car, it has shrunk the world around me far more than driving ever has.
Couldn’t agree more, and what about asymmetric prescriptions? This has been part of why I’ve never really been able to get into VR in general, the accessibility of it just isn’t there.
This is precisely it, and is a similar approach to the ones used by other anonymization networks as well. This allows your entry node to know your node/IP is using the network, but with a secure end-to-end tunnel, nobody along that tunnel knows the entire source -> destination path or data, so it is usually considered sufficiently anonymous and secure.