stack_underflow

12 เดือนที่ผ่านมาdiscuss

It sounds like they're doing something similar to Seagate's Field Access Reliability Metrics (FARM) log where IIRC it's much harder to reset or forge their wear-leveling/usage stats, vs SMART metrics which certain manufacturers seem to clear when drives are re-certified[0]. I've seen this tool[1] mentioned often in /r/DataHoarder discussions about checking whether second hand drives have had this stat-reset done. I'm assuming it compares `smartctl --log=farm` output with the attribute/device-statistic log counter values.

A friend and I have been building our own solution[2] for monitoring these wear-leveling attributes on NVMe and SATA drives, with the focus being on tracking and visualizing trends over time. We both have a large collection of drives in various servers and laptops and found that SMART metrics can be reported somewhat inconsistently from vendor to vendor so what started as a simple shell script to scrape `smartctl` output has now turned into a lightweight desktop agent that attempts to normalize all these inconsistencies and let us focus on the actual signals while also allowing us to define alerts/notify us of anomalies via email - maybe something HN users will find useful.

Fun fact: did you know that most drives maintain a pool of spare sectors/cells that are used by the firmware to replace blocks that have failed? It's one of the many metrics we like to track and visualize in Sentinowl [2]!

[0] https://github.com/gamestailer94/farm-check/tree/main

[1] https://www.heise.de/en/news/Fraud-with-Seagate-hard-disks-D...

[2] https://sentinowl.com/

stack_underflow

3 ปีที่แล้วdiscuss

Just curious, any reason you're using TMarkor instead of Markor? (https://github.com/gsantner/markor/ , https://play.google.com/store/apps/details?id=net.gsantner.m...)

Only asking since this was also the editor I ended up settling on in Android, but it seems like TMarkor is just a repackaging of Markor without any references to its forked(?) source.

My requirement was that the editor had to be open source so that I could audit the repo and compile the APK from source, as well as potentially fork it for personal modifications if needed.

stack_underflow

3 ปีที่แล้วdiscuss

Can also vouch for this. Bought a 2nd gen AMD Thinkpad T14 ~last year and haven't had any issues at all running Debian testing (bookworm). Swapped the m.2 with a 4TB one and added an extra 16GB of RAM to supplement the soldered 16GB. I believe they're on 3rd gen now but I imagine hardware compatibility is probably similar to 2nd gen.

The size/form factor is basically the same as my old T460s which I've had for ~8+ years and is still running, but a bit dated now with a 2c/4t Intel CPU. I believe back then the T460s was the "slim" version of the T460, but Lenovo seems to have dropped the "s" for the T14 even though the dimensions of both seem the same to me, maybe a couple extra mm in height on the T14.

stack_underflow

3 ปีที่แล้วdiscuss

One of my quick-and-dirty gotos for getting a rough idea of buffered-writes size + disk-write activity on random linux systems is: `watch -n1 grep -ie dirty -e writeback /proc/meminfo`.

You can invoke `sync` to watch the buffered-writes queue burn down when you have lots of pending writes.

see: `LESS=+/meminfo man proc` or https://github.com/torvalds/linux/blob/master/Documentation/... for more info

stack_underflow

3 ปีที่แล้วdiscuss

I think anyone who suggests daily driving Debian testing should also mention the fact that packages can disappear from testing for weeks/months at a time (and reappear later). It's recommended to configure `unstable` in your sources as well but set up apt pinning so that those packages are only pulled in if they're missing in testing. See: https://wiki.debian.org/DebianTesting "Best practices for Testing users"

In practice this means adding something like this to /etc/apt/preferences (along with adding entries for `unstable` in /etc/apt/sources.list)

    # use `n=` when referencing codename (i.e. buster/bullseye/...)
    Package: *
    Pin: release n=bookworm
    Pin-Priority: 550

    # use `a=` when referencing archive (i.e. stable/testing/unstable)
    Package: *
    Pin: release a=unstable
    Pin-Priority: 520

That way apt will pull in any packages missing in testing from unstable, and once the package is reintroduced to testing, will prefer that version rather than continue to track unstable.

Maybe I've been lucky but I've been running testing on my non-server desktops and laptops for 13 years now and have only rendered my system unbootable once (required having to boot up a live CD to reinstall an older working version of some bad libpcre update that had been rolled out).

stack_underflow

3 ปีที่แล้วdiscuss

If you're asking about specific examples, this book covers a lot of common patterns I've seen over the years; maybe a good starting point:

https://martinfowler.com/books/refactoringDatabases.html https://databaserefactoring.com/

stack_underflow

4 ปีที่แล้วdiscuss

> This eventually succeeded, giving the threat actor access to one of our GitHub organizations where they proceeded to copy 130 of our code repositories.

When I was at dropbox I saw quite a few devs provisioning non-mac laptops with their linux distro of choice. Always wondered what was stopping those people from just making a copy of rserver/rclient without IT/security noticing.

comments