Update Linux tutorial: remove outdated info and add plugin examples

[cpuu]

• Removed outdated references (e.g., deprecated ISF server)
• Updated symbol table instructions to match current Volatility 3 behavior
• Added or revised plugin usage examples:
  • pslist, pstree (updated output)
  • boottime, ip.Addr, ip.Link, malfind (newly added)
• Added a closing section encouraging plugin discovery and contribution

[cpuu]

Yep, looks good thanks! A few minor points, and happy to let other people weigh in but lemme know when you're happy for it to go in... 5:)

I've addressed all feedback with three additional commits. The pipeline has passed — kindly consider merging. Thanks!

[SolitudePy]

@ikelos @digitalisx @cpuu Hello sorry to jump in but I have some questions - why remove LiMe from the example tools? isn't this tool still widely used as a way to dump memory with a LKM?

regarding **Disassembly patterns**: Repetitive `add` instructions, `nop`, or unusual instruction sequences can be artifacts of shellcode, packer stubs, or JIT-compiled code - why repetitiveadd may indicate something suspicious? thats usually 00 00 so every empty buffer...

regarding the linux.malfind section (now called linux.malware.malfind btw) I think it should be standardized as in issue #1185 to be very robust (I would like to work on that issue if it's relevant), maybe even a separated documentation, blog or something that can help newcomers better understand the framework and the plugins it exports...

also, a general idea - why not make a separated repository for volatility-docs that will be rendered to your ReadTheDocs site and can be crossed here as a git submodule? some examples: https://github.com/mandiant/capa-rules => https://github.com/mandiant/capa https://github.com/Velocidex/velociraptor-docs

I asked ChatGPT to list a few advantages regarding that:

## ✅ Advantages of Separating Documentation into a Different GitHub Repo

### 🔒 Clear Separation of Concerns
- Keeps code and documentation logically separate.
- Easier to assign responsibilities to different teams.
- 📌 **Especially useful when documentation is written by non-developers** (e.g., tech writers, support engineers).

### 📦 Reusable Across Projects
- A shared docs repo can serve multiple forks, versions, or related projects.
- 📌 **Ideal if you want to reuse or rebrand documentation across different distributions.**

### 🧪 Simplified CI/CD for Docs
- Documentation builds (e.g., ReadTheDocs) won’t be triggered by code-only commits.
- 📌 **Recommended when docs have separate build systems, dependencies, or output (PDF, static sites, etc.).**

### 🌐 Custom Hosting or Branding
- A standalone repo is easier to deploy to custom domains or static site generators.
- 📌 **Great if you plan to host your docs under a marketing site or product portal.**

### 🕰️ Better Versioning and Branch Management
- You can maintain `v1`, `v2`, `dev`, and `legacy` documentation in a cleaner way.
- 📌 **Necessary when your documentation must reflect multiple released versions at once.**

### 🔁 Smaller Codebase and Faster CI
- Cloning/building the main code repo stays lightweight.
- Docs-related Python/Node dependencies don’t interfere with build/test pipelines.
- 📌 **Helpful in environments with strict CI runtimes or developer onboarding time constraints.**

### 🧩 Integration via Submodules or GitHub Actions
- You can include the external docs as a Git submodule if needed (for packaging or unified releases).
- You can sync version tags across both repos using GitHub Actions.
- 📌 **Works well in mature projects that automate release processes across code and documentation.**

---

## 🚦 When You Should *Definitely* Separate the Docs

- 🧑‍💼 Your documentation is actively maintained by **non-developer contributors**
- 📚 You are building **extensive documentation**, such as user guides, API docs, tutorials, FAQs
- 🏗️ You want **different release cycles** or **build processes** for code and docs
- 🔁 You want to **reuse the docs** for multiple forks/products/projects
- 🔒 Your company/org has **separate teams or permissions** for code vs docs

[cpuu]

@SolitudePy

1. As I mentioned earlier in the discussion, Volatility3 does not support LiME's raw format, and the project hasn't been maintained for over five years. That’s why I decided it was reasonable to remove it. AVML is currently the recommended tool for memory acquisition.

2. The behavior and implementation details of the malfind plugin are beyond the scope of this pull request. I’d recommend reaching out to the plugin's maintainer directly for further discussion.

3. I’d really appreciate your contribution to that issue — I’m looking forward to seeing what you come up with!

4. That's a great suggestion. A separate documentation repository sounds like a solid direction for the future.

[digitalisx]

Hi @SolitudePy, Thank you for your comment

As the @cpuu said, I thought it was an not good example because LiME has been not maintained for too long. We have an new method called AVML.

Decoupling a document project requires quite a lot of work, how about create another issue and create new PR?

I'm happy with the updates so far and it's okay to merge, there are many other topics that other issues and PRs can cover.

[ikelos]

@SolitudePy I've found that git submodules tend to just overly complicate things (people don't know how to check them out when they're just trying to grab a project, we'd need to verify the docs were present if we want to build them as part of the default pyproject.toml, etc, etc).

Also Chat GPT doesn't have the best reasoning:

• We want our code as self documenting as possible. You'll see there's very few actual documents that aren't generated from codestrings. They may be most of what people read, but ideally all the pertinent information should live in the plugins themselves. As such, separating concerns isn't as useful to use as it might sound.

• This is the documentation for volatility3. Using it across projects won't help the other projects, so... not sure this one's useful either.

• I think we're fine with the documentation rebuilds being triggered for live development by live development. It should only affect the latest docs, and by default we land people on stable docs.

• We're happy with where our docs live, and people can build them themselves if they want an archive of them.

• We also use tags and keep tagged versions of our documentation. It's pretty clean, so I'm not sure what Chat GPT is suggestion about our document hygiene... 5:P

• I think the docs are built by a separate system run by readthedocs, so it has no effect on our CI/CD build time?

• These don't sound like benefits, syncing with github actions sounds like extra work/complexity.

Did you happen to ask Chat GPT for reasons not to split the documentation into a second repo? I'd be interested to see what it spewed out... 5:P

So I don't think we'll be serparating the docs from the code any time soon. Users can make PRs on the main repo as easily as they can another one, so it would only be useful to delegate modifying/updating the documentation to others and at the moment I don't think we're popular enough to need that. 5;)