PumpkinDrama @ PumpkinDrama @reddthat.com

Posts

114

Comments

111

Joined

2 yr. ago

Moderating

---

The scale sort, is simplistic, it gives more weight to posts by communities with low active users, but bot accounts with many posts and no users would always be on top. It doesn't get outliers.

I'm fine just using the hot sort or scaled sort in my subscribed communities. I don't participate much since I mainly post in niche communities, and Lemmy tends to smother those, so I have to keep using Reddit.

I think it is, and niche has lost to shitposting. Also, don't tell me what to do.

Nah it only rewards communities with few members, that means bot communities with lot of posts and almost no active users are always going to be top. That's not the outliers sorting that I want.

1. Compute raw post score (upvotes minus downvotes).
2. Normalize score by community size (e.g., divide by square root of active users).
3. Calculate z-score relative to community mean and standard deviation.
4. Apply time decay to prioritize recent posts.
5. Sort posts by adjusted z-score.

• Outcome: Posts that significantly outperform their community norm appear prominently, giving small and large communities equal visibility potential.
• Enhancements: Minimum engagement thresholds, Bayesian shrinkage for small communities.

Use a weighted ranking algorithm that normalizes engagement across community size and highlights statistical outliers.

Goal: Equal visibility potential for small and large communities by emphasizing relative performance over absolute volume.

Outline:

1. Inputs
   • ( u ): upvotes
   • ( d ): downvotes
   • ( t ): post age (in hours)
   • ( n_c ): number of active users in the community
   • ( μ_c ), ( σ_c ): mean and standard deviation of engagement (e.g., score = upvotes − downvotes) within community ( c )
2. Compute raw score [ s = u - d ]
3. Normalize by community size [ s' = \frac{s}{\sqrt{n_c}} ] (Square root dampens the effect of community population size.)
4. Compute z-score (outlier detection) [ z = \frac{s' - μ_c}{σ_c} ] This measures how exceptional a post is compared to typical posts in its own community.
5. Apply time decay [ z_t = z \times e^{-λt} ] ( λ ) is a decay constant controlling how fast posts lose prominence.
6. Sort order
   • Primary key: ( z_t ) descending.
   • Secondary key: recency or total engagement.

Effect:

• A post that performs far above its community norm (high z-score) rises regardless of community size.
• Large communities no longer dominate since normalization and outlier weighting make “exceptional” small-community posts equally competitive.

Optional adjustments:

• Cap visibility to prevent manipulation (e.g., minimum engagement threshold).
• Use Bayesian shrinkage if communities have low post counts to stabilize ( μ_c ) and ( σ_c ).

This yields a discovery feed surfacing statistical outliers across all communities.

If you're seeking programming Q&A platforms that are more welcoming and less likely to close your questions, here are some alternatives to Stack Overflow that foster supportive communities:

🌐 1. Reddit Programming Subreddits

Examples:

• r/learnprogramming
• r/ProgrammingBuddies
• r/AskProgramming

These subreddits are known for their friendly and supportive environments, making them ideal for beginners and those seeking guidance without fear of question closures. Users often share resources, answer questions, and provide mentorship. (Reddit)

💬 2. DEV Community

Website: https://dev.to/

DEV Community is a platform where developers share articles, tutorials, and engage in discussions. It's a great place to ask questions, share experiences, and learn from others in a collaborative setting. (DEV Community)

🧠 3. Hashnode

Website: https://hashnode.com/

Hashnode is a blogging platform for developers, but it also hosts a vibrant community where you can ask questions, share knowledge, and connect with other developers. The platform encourages open discussions and learning. (Index.dev)

📚 4. Quora (Programming Topics)

Website: https://www.quora.com/

Quora is a general Q&A platform with a wide range of topics, including programming. While not exclusively focused on coding, it has a large community of developers who can provide insights and answers to your questions. (Medium)

🧩 5. GitHub Discussions

Website: https://github.com/

GitHub Discussions is a feature within GitHub repositories that allows for open-ended conversations, Q&A, and community engagement. It's particularly useful for project-specific questions and connecting with other developers working on similar projects. (Index.dev)

🧑‍💻 6. DaniWeb

Website: https://www.daniweb.com/

DaniWeb is a programming and technology forum where users can ask questions, share knowledge, and participate in discussions. It's a community-driven platform with a focus on helping others learn and grow. (Meta Stack Exchange)

🧑‍🏫 7. CodeProject

Website: https://www.codeproject.com/

CodeProject is a platform for developers to share code, tutorials, and articles. It also has a community forum where you can ask questions and engage with other developers. (Index.dev)

🧑‍💼 8. Stack Overflow for Teams

Website: https://stackoverflow.co/

If you're part of a team, Stack Overflow for Teams offers a private space to ask questions, share knowledge, and collaborate. While it's based on the Stack Overflow model, it's tailored for team environments and may offer a more supportive atmosphere. (G2)

These platforms offer more relaxed environments where you can ask questions, share knowledge, and learn without the fear of having your questions closed. Each has its own unique features and community, so exploring them can help you find the best fit for your needs.

Here’s a structured map + curated resources to help you learn how to debug system-level issues on Manjaro (Cinnamon) or any Linux. You won’t master it overnight, but these will give you direction and tools.

1. Concepts, approaches, mindset

You need to treat the system like layers (hardware, kernel, init, services, user space). When something fails, you trace upward or downward from symptom to root cause.

Key strategies:

• Reproduce reliably, with minimal state.
• Check logs early (kernel, systemd, service logs).
• Isolate subsystems (network, disk, memory, UI).
• Use interactive and passive tracing tools.
• When reporting bugs, collect as much context as possible (versions, logs, stack traces).
• Understand that for some deep bugs you’ll need debug symbols (which Manjaro doesn’t provide by default). (ArchWiki)

2. Foundational references / web resources

These are guide‐level or canonical references you should read and keep bookmarked:

3. Tools & commands you must know

You’ll use these regularly. Practice them so they’re second nature.

Logging / logs

• journalctl — read systemd journal. Use --list-boots, -b, -k (kernel) etc. (Manjaro Linux Forum)
• Log files in /var/log/ (syslog, kernel logs, app logs) (cycle.io)
• dmesg — kernel ring buffer messages
• systemctl status <service> / systemctl logs

System inspection

• top, htop, free, vmstat — memory/CPU monitoring
• iostat, iotop — disk I/O
• lspci, lsusb, lsmod, lshw — hardware & modules info (CBT Nuggets)
• smartctl — check hard drive health
• memtester — test RAM (in user space) (YouTube)
• strace, ltrace — track syscalls / library calls
• gdb + core dumps — backtraces, debugging crashes (ArchWiki)
• systemtap (for dynamic tracing) (Wikipedia)

Benchmark / stress / diagnostics suites

• Phoronix Test Suite — benchmarking various subsystems. (Wikipedia)
• Various stress / diagnostic tools (CPU, memory, I/O) — e.g. stress, stress-ng, sysbench (Baeldung on Kotlin)

4. Manjaro / Arch‐specific challenges & tips

• Because Manjaro is based on Arch but with its own packaging, debug symbols are not generally provided for stable packages. You’ll often need to compile yourself or switch branches to testing/unstable to get matching symbols. (Manjaro Linux Forum)
• For serious debugging (crashes, backtraces) users often switch the mirror branch to “unstable” and fetch debug symbols from Arch repos. (Manjaro Linux Forum)
• When opening bug reports, include: package version, logs, backtrace, steps to reproduce.

5. Learning path & practice

1. Pick a subsystem you care about (e.g. UI, GPU, networking).
2. Introduce a minor fault (e.g. misconfigure something) and try to trace it using logs + tools.
3. Read ArchWiki’s debugging articles.
4. Explore journalctl and logs.
5. Try capturing a crash and using gdb or coredumpctl to get backtrace.
6. Practice using strace, ltrace on small programs.
7. When you do hit a real bug, do a write‐up: collect all context, logs, trace, then try submit upstream.

If you like, I can send you a custom curated “Debugging Linux / Manjaro” cheat sheet (PDF or text) you can use offline. Do you want me to prepare that for you?

Perfect! Here's a reusable LLM prompt template you can use to generate high-quality Git commit messages from diffs or summaries of changes:

LLM Commit Message Prompt Template

 text

    
I have made the following changes in my codebase:

<INSERT CHANGES OR DIFF HERE>

Please write a Git commit message following these rules:
1. Use the **Conventional Commits format**: <type>(<scope>): <short summary>
   - `type` can be `feat`, `fix`, `chore`, `docs`, etc.
   - `scope` should be the file or module affected.
   - Short summary must be under 50 characters.
2. Include a **detailed description** after a blank line explaining:
   - Why this change was made.
   - What problem it solves.
   - Any important details or side effects.
3. Write in a **professional, clear, and concise tone**.

Only return the commit message, without any extra explanation.

  

How to Use It

1. Copy your diff or a summary of changes into <INSERT CHANGES OR DIFF HERE>.
2. Paste the prompt into the LLM.
3. Select the commit message you like best and use it for Git.

Optional Enhancements

• Automatic diff inclusion: you could feed git diff --staged directly to the LLM.
• Team style: Add a line like Use our team's tone: friendly and concise if needed.
• Language localization: Add Write the commit message in <language> for multilingual projects.

If you want, I can also make an optimized version that’s short enough to use directly in a Git hook, so your LLM can auto-generate commit messages whenever you run git commit. This would make it fully automatic.

Do you want me to do that?

Perfect — that gives me enough to make a recommendation.

Based on your answers:

• You want something that just works out of the box.
• Your focus is everyday tasks with some programming.
• You prefer cutting-edge software, but the system itself can be stable.
• You want a graphical installer and easy GUI management.
• You like Cinnamon for a Windows-like UI.
• You’re okay with either pre-installed software or minimal install.
• You don’t mind if the distro itself has a smaller community as long as the parent distro is well-supported.

The Linux distro that best fits you is: Linux Mint (Cinnamon Edition), ideally based on Ubuntu (the latest LTS or even a newer Ubuntu release if you want newer software with PPAs).

Why it fits:

• Cinnamon gives you a familiar, Windows-like interface.
• Linux Mint is very beginner-friendly and works well out of the box.
• It has access to Ubuntu’s massive repositories and PPAs, letting you get cutting-edge software.
• Graphical installer and GUI management are excellent.
• The Mint community is smaller but backed by Ubuntu’s large ecosystem.

If you want, I can suggest a slightly more cutting-edge variant of Mint/Ubuntu that will give you newer software without much extra hassle. Do you want me to do that?

Ask me questions (one at a time) until you can recommend me the linux distro that best fits me

Absolutely! Instead of implementing per-directory command history, you can enhance your Zsh experience by integrating fuzzy search for command history. This approach offers several advantages:

• Fuzzy Matching: Allows you to recall commands even if you don't remember the exact syntax.
• Efficiency: Enables quick searching through your command history, saving time.
• Simplicity: Doesn't require complex configurations or additional plugins.

To implement this, you can use the fzf (fuzzy finder) tool in combination with Zsh's reverse search functionality. Here's how you can set it up:

1. Install fzf: If you haven't already, install fzf by running:

    zsh

       
   git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
   ~/.fzf/install
   
   
     

2. Configure Reverse Search: Add the following to your ~/.zshrc to bind Ctrl+R to an fzf-powered reverse search:

    zsh

       
   source ~/.fzf.zsh
   
     

   This configuration replaces the default reverse search with a more powerful fuzzy search.
3. Optional - Customize Key Bindings: If you prefer a different key binding, you can modify the bindkey settings in your ~/.zshrc. For example, to bind Ctrl+S to the reverse search:

    zsh

       
   bindkey '^S' fzf-history-widget
   
     

By following these steps, you'll have a fuzzy search integrated into your Zsh history, allowing for more efficient command recall without the need for per-directory history setups.

Let me know if you need further assistance with this setup!

Is fuzzy search a better alternative to exact reverse-search in Zsh?

It depends on how you work and how much benefit you'd get vs overhead. Here’s a breakdown to help you decide.

Pros

1. Easier recall in project contexts When you're working in a particular directory (project), your relevant commands are grouped. You don’t sift through unrelated commands.
2. Cleaner history per context Less “noise” when using reverse-search (Ctrl-R) or browsing history while in a directory.
3. Better separation If you work on many unrelated things, per-directory history isolates each context.
4. Toggle flexibility Some plugins allow toggling between global and per-directory history. (e.g. the per-directory-history plugin in Oh My Zsh) (Unix & Linux Stack Exchange)

Cons / Costs

1. Implementation complexity / maintenance burden You’ll need to manage hooks (chpwd, zshaddhistory), directory tree creation, collisions, trimming histories, etc.
2. Cross-shell or concurrent sessions issues Two shells in the same directory may write to the same history file -> race conditions or interleaving.
3. Disk & file overhead Many small history files over deep directory trees will clutter your ~/.dirhist (or whatever base).
4. Fragmentation of history Sometimes you do want to search across all your commands globally. If you forget some context, per-dir history might hide useful commands you used elsewhere.
5. Plugin shortcomings / bugs Some users report that existing plugins don’t handle all edge cases (editing history, switching modes reliably). (Unix & Linux Stack Exchange)

Recommendation

• If you frequently jump between multiple projects and find that global history is cluttered for you, it may be worth trying as an experiment.
• If you’re more of a generalist user (single domain, occasional commands), the overhead probably isn’t justified.
• Start simple: enable a mature plugin (e.g. per-directory-history) and use it for a few weeks. If you like the improvement and don’t hit issues, keep it.
• Always keep a global history fallback (so you don’t “lose” commands irrecoverably).

If you like, I can simulate (or produce) a benchmark or user feedback comparing both setups for your workflow to see whether it's worth it for you. Do you want me to do that?

Would you recommend using a per-directory history setup, or is it more trouble than it’s worth?

Italian Seasoning

Ras el Hanout

Cajun

Garam Masala

Curry Powder