aka "bros: in order to be rich, just don't be poor."

Desktop web-apps won. Simply because native UI libraries never evolved past their 90s days. Either the UI is defined in some DSL, that's loaded (or compiled) and then you spend most of the time writing getElement(pathToElement) and wiring it up, or you have to boilerplate create each element and parent.addChild(element).

And wiring it up is also a pain. Send a signal or event, add a listener or slot, or whatever fancy name each framework comes up with, and if you have to modify another element, it means querying for it, or having a singleton, or passing a reference/pointer, or whatever. It's so friggin-old school.

In the meanwhile, the web discovered reactivity, components, declaring the UI and having the logic in the same file, live debugging, tight development loops, and so much more.

Is it just too difficult for native frameworks? Is it a sunken cost issue or fear of breaking backwards compatibility? Why can't native UI development be as easy and approachable as web dev?

Don't get me wrong, I need webdev like a child needs cancer, but I've tried Slint, imGUi, Qt, Gtk, wxWidgets, and more and the experience makes me want to blow my brains out every single time. I dread writing any native GUI that I got desperate enough to try writing a TUI but that's unbelievably worse!

It's gotten so bad, that Tauri and Dioxus are now on the menu. I never wanted to mix web dev into my native applications, but it feels like the abominably anachronistic state of native UI development is just forcing not only me, but anybody who wants to have a good experience writing native UI apps (especially those that are multi-platform), to use a fucking web view! A memory-hogging web view!

Didn't know where to share this, but I thought maybe someone else finds this useful :)

I initially made this for an artist who does not have a builtin animation utility in their digital art program. They can export their frames/layers as usual and the program updates its preview automatically.

It is my first time working with async Rust on an actual project, which was a bit tricky but I think I like it. The preview timing is not extremely accurate but it's OK.

cross-posted from: https://lemmy.world/post/46594968

Hey everyone,

I recently open-sourced OpenOSINT, a Python-based CLI framework designed to automate reconnaissance and threat intelligence workflows.

The architectural problem: Traditional OSINT automation usually relies on rigid bash scripts or static Python pipelines. If a tool fails, or if a specific finding requires a sudden pivot (e.g., finding an unexpected subdomain and needing to run a specific vulnerability check on it), a static pipeline simply breaks or requires massive if/else chains.

The approach: To solve this, I built an orchestrator leveraging the native tool-use/function calling APIs from Anthropic and OpenAI.

Here is how it works under the hood:

• Dynamic Orchestration: You provide a target (IP, domain, email) and a query. The LLM acts purely as a reasoning engine.
• Tool Registration: Local OSINT scripts are mapped as available tools. The framework reads the Python functions, parses docstrings and type hints, and feeds them to the LLM as an array of available actions.
• Execution Loop: The LLM decides which tools to call, in what order, and dynamically pipes the structured output of one tool as the input parameter for the next one.
• Modularity: Adding a new capability is plug-and-play. You just drop a new Python script into the modules directory, and the agent automatically knows it exists and how to use it based on the schema.

It's strictly CLI-native and outputs structured reports.

You can check out the code and the CLI demo here: https://github.com/OpenOSINT/OpenOSINT

I'm looking for some technical feedback on the codebase. Specifically, I'd love to hear your thoughts on how to better optimize the context window limits when dealing with massive raw outputs (like huge DNS dumps or nmap scans) before feeding them back into the LLM's memory.

Any architectural critiques or suggestions are welcome!

When I built workdash, its goal and vision wasn't immediately clear to all people. So I thought it could be interesting for people that's don't immediately see it to read the principles and frustrations that made workdash what it is.

On my daily life I maintain and contribute to multiple opensource projects and work repositories, which means I constantly juggle git repos, issue trackers, CI, reviews, terminals, coding agents, logs, and random operational tasks.

In the past I tried to keep up with all of this in many different ways: Emails, GitHub Notifications, Aggregators, the classic “I’ll just ignore everything, if it’s really important someone will ping me” mantra and even more odd automation I won’t share here because would only make your life worse and not better (no, really, don’t try to delegate your life organization to an agent).

None of those worked really for me, because most developer dashboards try to solve this by replacing your workflow with their workflow.

Your editor becomes secondary. Your terminal disappears. Git becomes a button inside somebody else’s UI. Eventually the dashboard becomes the place where everything must to happen.

The question I found asking myself most frequently was "why can't I just open a shell here?"

This is more or less the story of how that question lead me to create "one more tool" and how maybe someone else will find it useful too.

cross-posted from: https://infosec.pub/post/46083169

Hello,

I’m here to ask for guidance on an ongoing project. A number of years ago I wrote an Articles of Association for a worker’s cooperative as I think it should run. The main difference between a conventional co-op and mine is that a conventional co-op tends to have no hierarchy while in mine there is a CEO who gets elected periodically based on their business plan. The theory is that this brings democratic ideals into the workplace without sacrificing the productivity gains that result from hierarchical teamwork. You can read more detailed information on my Beehaw Post.

To put it into practice I need to create an open-source enterprise application server with applications specifically designed for the management of these companies. I created a block diagram to show you what I envision (attached to the post), and this represents my ideal “wish list” for what it should include.

The controls listed at the bottom will determine the permissions everyone has on the network and will be used to design GUI screens. I was going to draw connectors to each of the services but it would have turned into spaghetti.

I’m pretty decent with local programming including database and GUI design, but I lack experience with network programming.

So far I think I need to use XMPP for the messaging client and SSH for the rest. Since I’m most comfortable in Python I was going to look into Paramiko.

So my question is, where should I go in my research? Is there a particular component in the diagram you think I should try to build first?

Thanks in advance for any help, Juniperus

Crossposted from https://lemmy.ml/post/46897859

It is not my project.

I was looking for a lite version of Zed IDE without AI integrations, collab feature, telemetry etc and suddenly found it ^_^

I didn't test it excessively yet, but definitely give a try.

If you already tried it, please share your opinions.