• 1 Post
  • 53 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle

  • Correct ^_^
    Tank was likely captured in Egypt in the 50s or 60s, and transported to a military workshop next to the city - probably to study Soviet armour.
    Years later the city was expanding, so they decided to move the base someplace else and someone decided to just burry the thing instead of transporting it again.
    At least, that’s the official, “logical” explanation that we got that conveniently ignores the possibility of secret Soviet space-time travel experiments!


  • Construction workers were digging foundations at a local work site and found a Soviet T-34 tank burried in the ground.

    Important context:

    • My town is not in Russia or the former USSR.
    • My town is not in Europe either.
    • Our military doesn’t even operate Soviet equipment.
    • My town is also not next to a border with a country who might have operated Soviet equipment when it was also not so friendly with my country.

    There are some plausible theories, but to this day nobody really knows how it got here or why it got burried.

    Ohh and the real kicker: the street this all happened on is named after an indigenous tank, so the news headlines all basically said “Tank found on Tank street!”


  • There’s a very nice (albeit somewhat outdated) talk here.

    In a nutshell, both X11 and Wayland are protocols that define how software should communicate to (hopefully) display stuff on your screen.
    Protocols as in there’s a bunch of documentation somewhere that says which function a program must call to create a window, without specifying how either program or function should be implemented.
    This is great because it allows for independently written software to be magically compatible.

    X11 is the older protocol, and was working fine good enough for many years, but has issues handling a bunch of modern in-deman technologies - issues which can’t be fixed without changing the protocol in a way that would make it incompatible with existing software (which is the entire point).
    Plus its most used implementation - Xorg, consists of a huge and complex codebase that fewer and fewer people are willing to deal with.

    Wayland is the newer protocol, that mostly does the exact same thing, but better, in a way that allows for newer tech, and completely breaks compatibility in order to do so.

    The trouble with the whole situation was that in order to replace X with Wayland basically the entire Linux graphics stack had to be rewritten - and it was, with raging debates and flame wars and Nvidia being lame.
    They also wrote a compatibility layer called Xwayland that lets you keep using older X-only apps which somehow manages to outperform Xorg.

    Now we’re at the point where major distributions are not only switching to Wayland by default, but also dropping support for Xorg completely, and announcing that they’ll no longer maintain it, which is why posts about it keep popping up.












  • Wayland is trash and the fact that we are fourteen years into its life (YES, FOURTEEN) and still can’t get it working right is a good indication that we need to abandon it.

    lol, I don’t get why people keep using this argument…
    All of these developers, companies, toolkits, DEs and various other projects have decided that it’s easier to literally rewrite the entire Linux desktop than to continue hacking Xorg.
    In fact they don’t want to touch Xorg so much that they’re willing to spend 14 years (and counting) replacing it.
    And you see this as indication that Wayland is trash?

    Yes, you can. Seriously, people act like Xorg is some immutable black box no one can touch. IT’S FREE (AS IN FREEDOM) SOFTWARE. FIX IT.

    Go right ahead. Start by adding per monitor refresh rate.




  • There’s a bug open for Firefox and you can change VSCode’s behavior by putting this in your keybindings.json:

    {
        "key": "shift+insert",
        "command": "editor.action.selectionClipboardPaste",
        "when": "textInputFocus && !editorReadonly"
    }
    

    Not sure why either of them are messing with a “standard” shortcut…
    If you want a more system-wide solution there are utilities that let you sync the PRIMARY (on selection) and CLIPBOARD (Ctrl+c) buffers mentioned in the Arch Wiki entry.