• 1 Post
  • 24 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle

  • homura1650@lemmy.worldtoProgrammer Humor@programming.devmoney
    link
    fedilink
    arrow-up
    14
    arrow-down
    2
    ·
    2 days ago

    Even without AI, Web Development was destined to be a short lived industry.

    Sure, it will be around in some form, but a lot of that space has been taken over by mobile app development. Another portion of the market has been taken over by social media (your business doesn’t need a website anymore; it needs an Instagram/twitter/etc). And yet another portion has been taken over by products like Wix that allow non-experts to make good enough websites themselves (even without AI).

    Really, thinking of “web dev” as a profession is a category error. You are a graphical designer and programmer that was working in the web industry. There are plenty of other industries that hire your profession.


    • /ram - tmpfs filesystem
    • ~/.local/bin - added to my path
    • ~/.local/software - any user-local program more complicated than a binary gets a directory here. Generally a binary would be symlinked to ~/.local/bin
    • ~/.local/venv - shared python venv to use for one liners and small scripts
    • ~/repo - local filesystem backed package repository for which the host system is configured to install from
    • ~/.local/repo - local filesystem backed package repository for which the host system is not configured to install from (used for mock, VMs, and external systems).
    • /overflow - Used to point to a large secondary hard drive (back when having a small ssd was the economical thing to do. Nowadays, it is just where my large directories go cause I can’t be bothered to get used to a more sane setup





  • I would argue that in your application, a wrong URL is a sever error. That error being improper handling of a client error.

    I’m not a web dev, but had a similar problem with a niche compiler I used to develop.

    We were pretty good at validating invariants at the mid and back-end. This meant that most user errors got reported as internal errors. Generally, these errors were good enough that users were able to get used to reading them and fix their code.

    It was next to impossible to actually get users to file bugs about this. Our internal error messages started with a banner that read “THIS IS A BUG IN <compiler name>. PLEASE REPORT TO <support email address>”. Despite that, whenever we actually got a bug report, it would inevitably start with “I’m pretty sure this isn’t actually a bug in the compiler, but I can’t figure out what I am doing wrong in my code”.



  • If you are running an AC, you might be able modify it to reduce the humidity.

    AC units naturally dehumidify (as TC points out, they are essentially the same thing as traditional dehumidifiers). However, the amount of moisture they pull out is mostly related to how long they are running, not how cold they can get. This means that if you have an overpowered AC, you get less dehumidifying effect because the AC is on less.

    Some ACs let you reduce their power, which will increase their duty cycle and increase the amount of water they pull out of the air. It also helps improve their lifespan as they need to cycle less.





  • Of course they collect content you upload. How else do you think they maintain a chat history so people can see what was said while they were offline?

    I see nothing in the privacy policy that says they can sell the data. There is, however, things that allow them to share the data with 3rd parties, including bot developers. Having developed Discord bots, I can tell you that you can get pretty unrestricted access (with the server owners cooperation) until you have been added to a bunch of servers (at which point you need Discord approval to get things like message content)


  • If you are building a static system, SELinux is amazing. You need a few lines of policy per application to label things appropriately, then you can see what accesses programs made and decide if you want to allow them or not.

    Taking a full Linux system and adding a locked down SELinux policy can be done in less than a week. If you are starting with an SELinux enabled system and just want to lock down your application, it can be done in less than a day.

    Once you know what you are doing, there is also a pretty powerful policy analysis tool that lets you see what a given domain can do; including transitive things like “domain sandbox_t can launch a program in Domain vim_t, which can write a file in Domain sshd_config_t, which can be read by domain sshd_t” which may indicate that your sandbox has a hole allowing it to compromise your sshd configuration. Although, to be fair, doing this level of analysis is not simple, even with the tooling. And you very quickly notice issues that are inherent in how Linux works.

    The problem with SELinux comes when you try applying it to general purpose systems, because you do not know ahead of time what the user will want to do. To be effective, policy needs to be written for the specific system it will be running on.

    An example I like to use is Android. Android makes great use of SELinux, and is a general purpose system. But the SELinux policy itself does not protect the general purpose Android system. It protects the special purpose system that is the Android runtime. All apps run with the same policy that says things like “cannot access the filesystem at all, unless given access by the Android runtime”, then the actual security policy users see is all implemented in use space by Android. SElinux is just a means of preventing apps from bypassing the Android permission system.


  • Also, AppArmor might not exist without SELinux.

    When the NSA first implemented SELinux, they did so directly, but were not able to get that merged into mainline because there was concern that SELinux was not the correct solution.

    What they ended up doing was creating the Linux Security Modules (LSM) framework, which is just a bunch of hooks in the kernel that a module can implement. SELinux was then rewritten as LSM module. This allowed other solutions like AppArmor to be implemented without any invasive work; they could just plug into the same system SELinux used.

    Some time later, the ability to run multiple LSMs at once was added.

    Incidentally, Linux capabilities are also implemented as an LSM.






  • That’s not how it works. I don’t know what social media is involved, but from according to Facebook’s TOS, you grant Meta a revocable license to use it it a manner consistent with your privacy settings.

    Specifically, when you share, post, or upload content that is covered by intellectual property rights on or in connection with our Products, you grant us a non-exclusive, transferable, sub-licensable, royalty-free, and worldwide license to host, use, distribute, modify, run, copy, publicly perform or display, translate, and create derivative works of your content (consistent with your privacy and application settings). This means, for example, that if you share a photo on Facebook, you give us permission to store, copy, and share it with others (again, consistent with your settings) such as Meta Products or service providers that support those products and services. This license will end when your content is deleted from our systems.

    There is a potential fair use argument to be had (particularly since the allegedly infringing party is news). And it is not clear from the article who owns the original copyright in the first place.