• 0 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle
  • Or just :set mouse=a if your terminal emulator was updated in the past decade. gVim has nothing to offer anymore, except that it bundles its own weird terminal emulator that doesn’t inherit any of the fonts, themes, settings or shortcuts of one’s default terminal. Blegh.

    Also if you’re not going to leverage Vim’s main feature and just want to click around on stuff, just install VSCod(e|ium), which is genuinely amazingly good.


  • There are good sides to DST, such as coming home “earlier” (by the sun clock but not by the social clock) from school or work and therefore having more hours of daylight during the free time after work. These positive effects may go beyond subjective feelings. A study has shown for example that activity increases with longer evening daylight (Goodman et al., 2014) – albeit with small biological effect sizes (≈6% difference in the daily activity between the Standard Time of the year and DST, adjusted for photoperiod). Interestingly these results of the above study were culture-specific: a significant increase was mainly observed in Europe and to some extent in Australia, while no significant effects or even slightly negative effects were seen in the United States and Brazil.

    Fucking duh. This is the sticking point for me, and I am disappointed that the article doesn’t mention the effect of latitude here. Very easy for muricans to say “DST is not useful” when these fuckers never get pitch-black night before 6pm or full daylight before 6am ST.

    Brussels is on the same latitude as Calgary. ST robs every office worker of one hour of useful daylight. That’s it. That’s the whole argument for permanent DST. Businesses will not change their opening hours, so permanent ST means a net loss of one active hour in the day for every office worker. Permanent DST in Europe means someone working 9-6 would not have to drive home at night for 4 months of the year and could maybe even take the dog for a walk in the evening sun.


  • Good software does not come out of companies without a bottom-up approach to software development. Top-down approaches are either terrible or extremely expensive.

    Agile development is something that at my company we fought for, not against. It’s literally impossible to fight against actual agile development since it has to come from the workers. Agile is not scrum, and neither are a collection of ceremonies. It’s just a framework to give agency to developers.


  • Scrum is not the be-all end-all, but in organizations that cannot implement scrum effectively, no system could hope to achieve anything meaningful either.

    Scrum aims at empowering workers to remove power from clueless MBAs and meritless CEOs, if they don’t want to play ball then the idiocracy will win every time regardless.


  • I’ve witnessed similar corporate screwups from the inside, I know the greed and political games and misaligned incentives that allow for such an obviously and catastrophically badly scoped project to be pushed dead-on-arrival in production, against the advice of literally anyone with a pair of eyes and literally any honesty.

    Intellectually, I understand. Yet my heart doesn’t, because it refuses to believe the sheer amount of collective stupidity and outright malice at every level of management, consistently for years on end, required to achieve these outcomes. How anyone can sleep at night with “Product Manager for New Outlook” on their resume is beyond me.


  • I mean, bad programming sucks regardless of the “paradigm” (and vice-versa, mostly). But as someone whose job it often is to sift through production logs hunting for an issue in someone else’s component, at least I have a chance with OOP, because its behavior is normally predictable at compile time. So with the source and the backtrace I can pretty reasonably map the code path, even if the spaghetti is 300 calls deep.

    Now where shit really hits the fan is OOP with dependency injection. Now I’m back to square 1 grepping through 15 libraries because my LSP has no idea where the member comes from. Ugh.


  • Anyone who praises FP is either a student, works primarily in academia, or otherwise never had to look at a deep stack trace in their life.

    Every time a production system spits out a backtrace that’s just 15 event loop calls into a random callback, I lose 6 months life expectancy. Then I go look at the source, and the “go to definition” of my LSP never works because WHY WOULD IT, IT’S ALL FUNCTIONAL hapi.register CALLS

    I hate it I hate it I hate it I hate it. I support UBI because the people pushing functional programming in real production systems should be reassigned to gardening duties.




  • The title of the post is literally “I love my Gitea”.

    The content of them meme does conflate “git” with its various frontends (like gitea), but it’s an incredibly common misnomer so who cares?

    The person I responded to then went on a weird rant about how “git by itself is distributed” which is completely irrelevant to the point since OP’s Gitea provides a whole lot more.


  • You’re completely missing the point. Even Gitea (much simpler than GitHub, nevermind GitLab) is much more than a git backend. It’s viewable in a browser, renders markdown, has integrated CI functionality, and so on.

    Even for my meager self-host use-case, being able to view markdown docs in the browser is useful from time to time, even on my phone.

    As for the things I use (a self-hosted) GitLab instance at work for… that doesn’t even scratch the surface.


  • I get what you’re both saying, but it’s technically wrong. TCP exposes segments and those are guaranteed to be transmitted. That may however require the retransmission of several IP packets.
    So losing a packet is fine, while losing a segment is worth worrying about.

    Anyway I can’t speak for OP if they genuinely misunderstood because of terminology or just got wooshed. But they’re technically right, even if by accident.




  • azertyfun@sh.itjust.workstoProgrammer Humor@lemmy.mlDateTime
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    11 months ago

    You misunderstand what Unix Time is. It’s the number of seconds since 1970-01-01T00:00+00:00. It’s always relative to UTC. And the number of seconds since epoch is always the same regardless of where you are on Earth.

    As I write this it’s 1702600950 for you, for me, and in Sydney. Timezones (and DST, and leap seconds, and other political fuckery) only play a role once you want to convert 1702600950 into a “human” datetime. It corresponds to 2023-12-15 00:46:02 UTC and 2023-12-14 16:46:02 PST (and the only sane and reliable way to do the conversion is to use a library which depends on the tzdata).


  • azertyfun@sh.itjust.workstoProgrammer Humor@lemmy.mlDateTime
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    11 months ago

    EDIT: NVM I’m a goddamn idiot, Unix Time’s handling of leap seconds is moronic and makes everything I said below wrong.


    Unix Time is an appropriate tool for measuring time intervals, since it does not factor in leap seconds or any astronomical phenomenon and is therefore monotonously increasing… If T1 and/or T2 are given in another format, then it can get very hairy to do the conversion to an epoch time like unix time, sure.

    The alt-text pokes fun at the fact that due to relativity, at astronomical scales then time moves at different speeds. However, I would argue that this is irrelevant as the comic itself talks about “Anyone who’s worked on datetime systems”, vanishingly few of which ever have to account for relativity (the only non-research use-case being GPS AFAIK).
    While the comic is funny, if:

    • Your time source is NTP or GPS
    • “event 1” and “even 2” both happen on Earth
    • You’re reasonably confident that the system clock is functioning properly

    (All of which are reasonable assumption for any real use-case)
    Then ((time_t) t2) - ((time_t) t1) is precise well within the error margin of the available tools. Expanding the problem space to take into account relativistic phenomena would be a mistake in almost every case and you’re not getting the job.