• 0 Posts
  • 118 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2024

help-circle

  • I do see your point and I’ll actually upvote you here. But I do think there’s a meaningful difference.

    Software is just an idea written down rigorously. Various societies created various conventions and social contracts to control dissemination and usage of ideas, both in their pure and written down forms. Capitalist societies generally defer to the author of the idea for how they want it handled (at least for the first few decades), so that the author can earn some money from it (of course, even ideas are monetized under capitalism) - this is patent and copyright law.

    The free software movement is just a novel application of the copyright law. By sharing ideas freely but with a license that forces everyone using the idea to share their derivative ideas freely as well, it is attempting to destroy the spirit of copyright law by using the letter of copyright law.

    With all this in mind, let’s examine what it would mean to add the “don’t be evil” clause to an otherwise FOSS license.

    1. In ideal circumstances, a society’s system of laws and social norms should incorporate “don’t be evil” in it already. Hate speech and nazism should be prohibited and punished, so the clause would be superfluous.
    2. In “ordinary circumstances” of neoliberal capitalism, there are agencies that will be acting in bad faith but will stand above any laws, be it geneva conventions, hate speech laws or (boring) copyright law. You won’t be able to enforce a “don’t be evil” clause against the CIA or ICE or the Rockefeller. They can just take your software and use it, so the clause would be of little use typically. This is partially applicable to our current situation.
    3. In extraordinary circumstances, such as capitalism in advanced decay a.k.a fascism, the law will be ignored by most evil actors anyways. Law is just a social contract and fascism is deliberately breaking all social contracts. Nobody will enforce copyright law in favor of an individual FOSS developer, especially against someone who’s on the side of the regime. So the clause is completely useless. This is also applicable to our situation.

    There is some edge-cases in the middle where a “don’t be evil” clause might make a bit of sense. If the contract law (which includes copyright law) is still well-respected, but the social contract itself is falling apart around it, it might be used to prevent some nazis somewhere from using your software for a short while, but that situation is always unstable and does not last. In any case nazis are known for ignoring all social contracts, including court orders, so even this is questionable.

    There are also downsides in any “don’t be evil” clause, because it requires you to rigorously define what you mean by “evil”. This is actually really hard to do well without relying on existing laws (which ruins the point), and will usually either leave nazis leeway to get away with using it, or harm legitimate users, or both - especially because legitimate users are less likely to try pushing the boundaries.

    This is explicitly different from what Bluesky is doing. They are hosting known nazis. Nothing is stopping them from banning ICE and making it into a point of pride, it is really easy. There is no downside, no legitimate user hurt. It’s as easy of a decision as one can make.

    To reiterate,

    So the mastodon service supports Nazis.

    Mastodon-the-service doesn’t really exist (unless you count mastodon.social). But the fediverse in general is not supporting nazis. Nazis are banned and defederated.

    Mastodon-the-software may “support” nazis in the same way as the idea of a printing press (from your other comment) supported nazis.

    They’re providing software to Nazis, and I don’t really see how that makes them better than providing a place to post.

    Bluesky is categorically worse because it doesn’t have the “don’t be evil” clause in the software licenses either, and it is hosting nazis directly on the platform they run.



  • Good to know there’s a second full-network relay (assuming this is what it is). Last time I checked all third-party relays only indexed some sections of the network, so my knowledge was outdated.

    Conceptually relays are the indexers of the network, you can view individual PDSes without them, but you won’t get cross-PDS discovery; this is because PDSes don’t actually federate with each other.

    This means that in practice, relays define what it means to be “on bluesky”. If you are banned on all relays, your PDS becomes just a weird standalone microblog.

    This is different from the fediverse, where all instances federate with each other by default and relays just enhance discoverability and connectivity, rather than being the only way to do it.

    And in any case this is all a bit academic, bluesky are hosting nazis on their own PDS, bsky.social.


  • Bsky is actually quite centralized. Bluesky the company owns the only full-network indexer (I think they call it a “relay” or something), which collects posts from all other servers and allows those posts to be rendered by various apps (e.g. bsky.app, but all other frontends use the same indexer). They could just ban them at indexer level.

    But even that is moot, because they are letting them host their account on a server Bluesky the company owns, bsky.social.



  • Telegram can serve you your old “Cloud” messages, in a decrypted form, on a new device, without any communication with the old device.

    This means that they possess the keys to decrypt the messages, since they can send them to you in a decrypted form.

    Those messages can’t even be encrypted with your cloud password (which would be a pretty weak encryption anyways), because you can reset the cloud password via your recovery email, and still retain access to your messages.

    Contrast this with encrypted chats on Matrix, where you have to go through the device verification procedure, which prompts the old device to send decryption keys to the new device (it’s actually more complicated but this gets the point across). If you lose access to all your devices (and your recovery key), your encrypted messages are gone, the server admin can’t restore them because they simply don’t have the key.

    No one can’t prove that Telegram use MTProto to encrypt content sent using Cloud Chat, stores them encrypted, and them decrypt them upon opening because the source code for MTProto is closed. So how can you prove that what you’re saying is the way they use?

    This is a distinction without a difference.

    My claim is:

    They possess the keys to decrypt your messages

    Whether this is implemented via MTProto encryption or disk encryption or whatever, it doesn’t matter, they can read your messages if they want to.

    Telegram is actually pretty transparent that Cloud chats are not e2e encrypted in their FAQ. They also go on to babble about “MTProto client-server encryption” but if you spend 2 minutes looking at it, you can see it’s just 256-bit AES with a shared key generated via Diffie-Hellman, not too dissimilar from plain HTTPS. In that sense it’s about as secure as e-mail over encrypted IMAP/SMTP, or IRC over TLS, or DMs here on lemmy.

    They also claim that their at-rest encryption keys are separate from the data they encrypt, and claim that somehow this “requires court orders from multiple jurisdictions” to force them to give over your data, which is just ridiculous from a legal standpoint and won’t stand up in court. And actually, it’s way more likely that they will just cave in and give up your message history without a lawsuit at all, just look at what happened to Durov in France.


  • All data sent to Telegram’s servers will be encrypted once they reach the servers

    Except for “secret chat” (which are only 1-on-1 chats, have flaky client support, and require both participants to be online at the same time to initiate; in other words, they are near useless) - this is just simple at-rest storage encryption. They possess the keys to decrypt your messages (again, except for secret chats), because that is necessarily what happens when they serve those messages to recepients.






  • I think if you have some use-case that Wayland doesn’t fulfill, it’s totally fine to just pin some version of Plasma and stick with it. Maybe even switch to Trinity. Chances are it will keep working for like a decade or more.

    I still use kdenlive 18.08, because I know how to use that version, and it does what I need it to do perfectly well. They broke something I needed in 19.whatever (I don’t remember what it was anymore), so I just pinned it and kept using it ever since. Maybe one day I’ll try to figure out the latest version, but there’s no real incentive for me to do so.


  • For context, I’m using NixOS, not Arch, but it’s a similar enough idea. I have a tiling/tabbed WM configured just the way I like it, and a window switcher thingy, and it makes juggling hundreds of windows really easy and quick. Combined with a terminal-based editor, a custom setup for my shell, and direnv for easy environment switching, I can be switching between a dozen different projects within a single day (sadly a requirement for my work right now).

    Whenever I look at how my colleagues with KDE/Gnome are managing their workflows, it makes me appreciate the work I put into my setup a lot.

    Also, I have a whole bunch of shell aliases and scripts for tasks I do often.

    Sure, you can configure any distro to do that, but things like Ubuntu or Fedora would get in the way. At some point, when you want to choose (or even write) every component of the system and configure it yourself, it’s easier to just build from scratch rather than start with a lot of pre-configured software and remove parts.



  • Is it shown that there are significant performance benefits to installing daemons and utilities à la carte?

    No, not really.

    Is it because arch users are enthusiasts that enjoy trying to optimize their system?

    This is IMHO the most important aspect. The thing they’re trying to optimize isn’t performance, though, it’s more “usability”, i.e. making the system work for you. When you get down to it and understand all the components of the OS, and all the moving parts within, you can set it up however you prefer and then combine them in novel ways to solve your tasks more quickly.


  • balsoft@lemmy.mltoScience Memes@mander.xyzAeroplane
    link
    fedilink
    English
    arrow-up
    5
    ·
    3 months ago

    if the autopilot is engaged, you can’t physically move the wheels, because it is moving them for you.

    I’m pretty sure on newer 737s the autopilot disconnects when it detects a sufficient physical force on the yoke. But yeah the button is easier and safer.

    most important: the switch for the “fasten seatbelt” sign is usually on the bottom of the top panel. You can flip it on and off as much as you want. (Older planes will also let you do this with the “no smoking” sign).

    Gee, how the hell did everyone miss this? The most important control element.


  • balsoft@lemmy.mltoScience Memes@mander.xyzAeroplane
    link
    fedilink
    English
    arrow-up
    8
    ·
    3 months ago

    Chill, it’s just a shitpost.

    BTW, a regular person can likely fly and land a 737 with some basic ATC instructions, there have been multiple experiments demonstrating this (in a simulator). A guide like this would be immensely helpful in that situation.


  • balsoft@lemmy.mltoScience Memes@mander.xyzAeroplane
    link
    fedilink
    English
    arrow-up
    51
    ·
    3 months ago

    Few additions:

    • “reverse thrust” → “slow down (after you land)”
    • (at foot pedals) “Push both to brake (after you land), push one or the other to turn”
    • “go fast” → “go fast (keep levers together)”
    • “keep it above the ground” → “keep it above the ground, but not too high”
    • (at IAS indiciator) “how fast you’re going”, “keep between 170 and 400, lower to 140 when landing”
    • “make wings bigger” → “make wings bigger, required when taking off or landing”

  • I’ve heard about Linux being highly customizable and decentralized OS, and suddenly I can’t define my own shortcuts because there is a list of un-features?

    You can customize it to do whatever you want. Heck, you can write your own terminal emulator that does exactly what you need. But some things can be harder to do than others and require skills and experience. Once someone implements those harder things, they become a “feature”. Before then, therefore, they are an “un-feature”. See https://xkcd.com/1349/

    E.g. it is probably possible to set up your shell to use shift-selection for the command you’re currently editing, but shift-selection for the output of a previous command will require terminal support. You will have to make sure that the two don’t interfere with each other, which can be quite complicated.

    I already have my workflow and I’m trying to transfer it to Linux

    Linux is a different OS that, by default, does things differently from others. You can configure it to emulate some other UX, but it won’t necessarily be easy. In the meantime, you can install the micro editor, set EDITOR=micro, and then Ctrl+x Ctrl+e in bash to edit the command in a more familiar setting.