🅿🅸🆇🅴🅻

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

help-circle









  • True, but it depends from person to person and it counts if you have a small or big drive, how often you watch and rotate your media, how large the media is. If you only have a 1TB SSD, and often download and watch blue-ray quality, 20 movies will fill it. It won’t be long until the same blocks get erased, no matter how much the SSDs firmware tries to spread the usage and avoid reusing the same blocks.

    Anyway, my point is, aside from noise and lower power consumption advantages, I wouldn’t use SSDs for a NAS, I regard them as consumables. Speed isn’t really an issue in HDDs.



  • 🅿🅸🆇🅴🅻@lemmy.worldtoSelfhosted@lemmy.worldSSD only NAS/media server?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Failure rates for sdd are better than hdd

    I’m curious on where did you find this. Maybe they have lower DOA rates and decreased chances to fail in the first year, but SSDs have a limited usage lifetime / limited writes, so even if they don’t fail quickly, they wear out over time and at first they have degraded performance, but finally succumb in 5 years or less, even when lightly used (as in as OS drives).

    To avoid DOA / first year issues with HDDs, just have the patience to fully scan them before using with a good disk testing app.


  • From my experience, SSDs are more prone to failure and have limited writes. They are ment for running the OS, databases for fast access, and games / apps. They are not ment for long time storage and frequent overwrites, like movies, which usually means download, delete and repeat which wears the memory quickly. One uses electric current to short memory cells and switch them from 0 to 1 and viceversa, the other uses a magnetic layer which supports a lot more overwrites on the same bit.

    If keeping important data on them, I would use them only in a redundant RAID configuration and/or with frequent backups so I wouldn’t cry if one of them fails. And when they fail, there are no recovery options as with HDDs (even if very expensive, at least you have a chance).

    I also wouldn’t touch used server SSDs, their lifetime is already shortened from the start. I had 3 Intel, enterprise-grade SSD changes in our company servers, each after about 3 years - they just wear out. For consumer / home SSDs the typical lifetime is 5 years, but that takes into account minor / “normal” usage, ie. if used as OS disks. And maybe power users could extend that with moving the swap/pagefile and temporary files (ie browser cache, logs, etc) on a spinning disk, but it defeats the purpose of having an SSD for speed in the first place.

    If you have media (like movies) in mind, you’ll find sooner than later that you’ll need more space, and with HDDs the price per GB is lower than SSDs.

    If you have no issue with 1. noise, 2. speed (any HDD is fast enough for movie playback and are decent for download), 3. concurrent access, or 4. physical shocks from transport, go with HDDs, even used ones.

    My two, personal opinion cents.



  • Reading as a kid about virus analysis and how they work in a short column in a… newspaper. Yeah, they even listed full Windows Registry paths. Didn’t know what HKEY_LOCAL_MACHINE was, didn’t own a computer, only knew about some DOS commands, but I knew I wanted to be able to do that job and decompile stuff (whatever that ment) and see how it worked. Just like dismantling (and ultimately destroying) toys to see the inner workings.

    After finally owning a computer and being bored by the few games I had on Windows 95, being limited to Notepad, Internet Explorer (without an internet connection yet; or was it Netscape Navigator?) and Paint (in which I sucked, lacking any artistic talent), when I learned that I can just type stuff in Notepad, I borrowed a book about “programming” in HTML. Then Pascal, the pinnacle being a simple XOR encryption program, with a god damn white on blue “windows” interface with buttons (a la Midnight Commander). Writing TRIVIA “scripts” for mIRC channels made us gods. Then Delphi naturally followed, making my own tool to track how many hours I’ve spent on dialup a month (yes, internet was very expensive) while listening to 80’s music on Winamp. Nothing was more interesting than that. Then got a job and out of a sudden started making my own money by writing Delphi code. Up until then I wasn’t really aware that my passion would also bring food on the table. The rest is history.

    Programming in those days felt unreal. Felt like The Matrix. I knew that what I want to do for the rest of my life is look at text on a screen, hit CTRL+F9, see a crash, set some breakpoints, and ponder around the room or while taking a piss about what went wrong and how to solve it. I’m no Einstein, but I understood why science people dedicate their lifes to their work and disregard completely their social life.


  • My take: actual, hands-on programming is way more rewarding than reading and watching tutorials.

    I learned a lot at work (80% still self-tought, rest from interaction with other teams and other people better than me and with greater experience), and it usually came from needing to make my job easier, not to please the clients or management (scripting and automating things, Linux, DevOps, etc).

    The other part through personal projects (again, out of need). You need to take on a project with real use to you. And you get to use the latest frameworks / technologies which you might not at your workplace, depending on the company. Working on personal projects will give you a different kind of fulfillment and will keep you remember that you love to code. Work is work, play is play.

    And last, contributions to public, open-source projects. You need to read and understand other people’s code, get familiar with Github, write clean, documented code and respect the standards for the project. It will help you in the long run, and you could also add something to your CV.

    As for the actual things to learn, don’t get stuck on learning just the framework, which does a lot for you out of the box by running commands or calling packages. Try to go in-depth in a programming language and play with the bare-bones, learn the intricacies. Learn for example how code runs and where. I have colleagues still thinking that queues are magical and asynchronous, they write a few lines of code and just work when deployed, without any actual knowledge of the architecture of the system they run on, this leading to no thought in optimization and speed of their code. Or they use the ORM exclusively, which, again, doesn’t help when shit hits the fan and you need to debug and optimize for bulk processing.

    Also, learn a bit about cryptography and cyber security, even if only for yourself as a hobby. This is where I see a lot of developers lacking, to the point that most don’t know the difference between hashing and encryption. There is no project nowdays in the universe where security doesn’t matter.

    The difference between a mediocre programmer and a good one might not be obvious during an interview, but they will show during the trial period.




  • We return / display the translation key name if no translation is available for that language, including for the default (English).

    Also, on dev / test environments we can enable a config (.env) setting to append the text " [UNTRANSLATED]" to every value that doesn’t have a translation, as they’re easier to spot in the website / interface.

    I’m talking about a PHP /Laravel project so it was easy to override the default translation engine behaviour.