Just your average being, of some form.

  • 2 Posts
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle



  • This will be my final reply on the matter as I do not believe you are operating in good faith. But in case you are:

    Firstly, the idea that you “cannot be forced to do something within your job description” is unequivocally false, and a sign of a toxic work environment. She actively requested to not be put in charge of a platform that made her uncomfortable, and the request was denied and she was forced, against her will, to do so. I have never in my life worked at a place where I could not request to be taken off a project or task due to being uncomfortable with it. This is not a point of discussion, this is a categorical fact.

    Secondly, it does not matter that she was not public facing on OnlyFans. She, alongside her coworkers, were active public figures on multiple LMG affiliated channels during her employment. And OnlyFans is a platform known to be near exclusively used for sexual gratification, and it is therefore entirely unsurprising that the LMG OnlyFans account received a large amount of sexual advancements, objectification, and harassment of LMG employees. And due to my prior comment, I fully believe a large majority of what was received would have been targeting the women employed at LMG. Therefore, putting one of the main victims of said harassment and objectification in charge of managing it is wholly and entirely unacceptable behavior by the management at LMG.

    These are not complex concepts, and are not even all that contemporary anymore. And as such I do not feel there is any real discussion to be had on the matter, there are people more intelligent than I that do a better job expressing these things in more empirical detail. I suggest you seek them out if you need more detail than I have provided here.



  • 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.


  • 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.


  • 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.


  • 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.




  • Juniper@skein.citytoProgramming@beehaw.orgWhen DRY goes wrong
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    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.





  • 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.