• 0 Posts
  • 76 Comments
Joined 1 year ago
cake
Cake day: April 3rd, 2024

help-circle
  • To quote that same document:

    Figure 5 looks at the average temperatures for different age groups. The distributions are in sync with Figure 4 showing a mostly flat failure rate at mid-range temperatures and a modest increase at the low end of the temperature distribution. What stands out are the 3 and 4-year old drives, where the trend for higher failures with higher temperature is much more constant and also more pronounced.

    That’s what I referred to. I don’t see a total age distribution for their HDDs so I have no idea if they simply didn’t have many HDDs in the three-to-four-years range, which would explain how they didn’t see a correlation in the total population. However, they do show a correlation between high temperatures and AFR for drives after more than three years of usage.

    My best guess is that HDDs wear out slightly faster at temperatures above 35-40 °C so if your HDD is going to die of an age-related problem it’s going to die a bit sooner if it’s hot. (Also notice that we’re talking average temperature so the peak temperatures might have been much higher).

    In a home server where the HDDs spend most of their time idling (probably even below Google’s “low” usage bracket) you probably won’t see a difference within the expected lifespan of the HDD. Still, a correlation does exist and it might be prudent to have some HDD cooling if temps exceed 40 °C regularly.


  • Hard drives don’t really like high temperatures for extended periods of time. Google did some research on this way back when. Failure rates start going up at an average temperature of 35 °C and become significantly higher if the HDD is operated beyond 40°C for much of its life. That’s HDD temperature, not ambient.

    The same applies to low temperatures. The ideal temperature range seems to be between 20 °C and 35 °C.

    Mind you, we’re talking “going from a 5% AFR to a 15% AFR for drives that saw constant heavy use in a datacenter for three years”. Your regular home server with a modest I/O load is probably going to see much less in terms of HDD wear. Still, heat amplifies that wear.

    I’m not too concerned myself despite the fact that my server’s HDD temps are all somewhere between 41 and 44. At 30 °C ambient there’s not much better I can do and the HDDs spend most of their time idling anyway.



  • Honestly, I’m still very much in the “classes define what a tag represents, CSS defines how it looks” camp. While the old semantic web was never truly feasible, assigning semantic meaning to a page’s structure very much is. A well-designed layout won’t create too much trouble and allows for fairly easy consistency without constant repetition.

    Inline styles are essentially tag soup. They work like a print designer thinks: This element has a margin on the right. Why does it have that margin? Who cares, I just want a margin here. That’s acceptable if all you build are one-off pages but requires manual bookkeeping for sitewide consistency. It also bloats pages and while I’m aware that modern web design assumes unmetered connections with infinite bandwidth and mobile devices with infinitely big batteries, I’m oldschool enough to consider it rude to waste the user’s resources like that. I also consider it hard to maintain so I’d only use it for throwaway pages that never need to be maintained.

    CSS frameworks are like inline styles but with the styles moved to classes and with some default styling provided. They’re not comically bad like inline styles but still not great. A class like gap-2 still carries no structural meaning, still doesn’t create a reusable component, and barely saves any bandwidth over inline CSS since it’s usually accompanied by several other classes. At least some frameworks can strip out unused framework code to help with the latter.

    I don’t use SCSS much (most of its best functionality being covered by vanilla CSS these days) but it might actually be useful to bridge the gap between semantically useful CSS classes and prefabricated framework styles: Just fill your semantic classes entirely with @include statements. And even SCSS won’t be needed once native mixins are finished and reach mainstream adoption.

    Note: All of this assumes static pages. JS-driven animations will usually need inline styles, of course.


  • “Legally required”, so they’re seeing it in the local laws. Some countries require websites to disclose who operates them.

    For example, in Germany, websites are subject to the DDG (Digitale-Dienste-Gesetz, “digital services law”). Under this law they are subject to the same disclosure requirements as print media. At a minimum, this includes the full name, address, and email address. Websites updated operated by companies or for certain purposes can need much more stuff in there.

    Your website must have a complete imprint that can easily and obviously be reached from any part of the website and is explicitly called “imprint”.

    These rules are meaningless to someone hosting a website in Kenya, Australia, or Canada. But if you run a website in Germany you’d better familiarize yourself with them.








  • My most used features so far are vertical splitters, vertical nudging, and the new placement modes for conveyors and pipes. With an honorable mention going to conveyor wall holes, which also free up a lot of design options.

    Honestly, though, just about everything in this update has been a godsend. Priority splitters are the only thing I haven’t really used yet. Even the elevators rock; being able to zoop up to 200 meters up or down in one go can make them useful even as a temporary yardstick for tall structures. (Also, I did end up needing to go 150 meters straight down to get at some resources and can confirm that elevators handle their intended purpose very well.)