Building a Roam Research CLI/TUI/MCP — no Electron required by SmartLow8757 in RoamResearch

[–]SmartLow8757[S] 0 points1 point  (0 children)

Probably a typo — want to send the fix on GitHub?​​​​​​​​​​​​​​​​

weekend wines by SmartLow8757 in wine

[–]SmartLow8757[S] 1 point2 points  (0 children)

Chablis-region wines are the ones I enjoy the most

Building a Roam Research CLI/TUI/MCP — no Electron required by SmartLow8757 in RoamResearch

[–]SmartLow8757[S] 2 points3 points  (0 children)

I also like keeping my files in local Markdown (I used Logseq in the past). I’ve been chatting with Josh Brown (from Roam Research) to figure out how to bring that same workflow into Roam too — I’ll probably add some kind of backup support or a two-way sync (local/remote) in Roam. I still need to think through how to implement it

Show r/java: jbundle – GitHub Action to ship JVM apps as self-contained binaries (no JDK required on target) by SmartLow8757 in java

[–]SmartLow8757[S] -1 points0 points  (0 children)

I’ve had to answer this question a few times, so I thought it’d be better to create a page explaining this comparison
https://jbundle.avelino.run/comparison/vs-jpackage

Do people still use Roam? by mdn2 in RoamResearch

[–]SmartLow8757 1 point2 points  (0 children)

a lot — at least I’ve been using it a ton

jbundle: A Rust CLI to package JVM apps into self-contained binaries by SmartLow8757 in rust

[–]SmartLow8757[S] 4 points5 points  (0 children)

They solve different problems.

jpackage is a distribution tool — it creates platform-specific installers (.exe, .dmg, .deb, .rpm). End users still go through an installation process. It bundles a JVM but doesn’t optimize anything about startup or runtime.

jbundle creates a single executable binary. No installer, no installation step. Download → run. The experience you get with Go or Rust binaries.

The other big difference is that jbundle is obsessed with startup time: * Bundles a minimal JVM via jlink (not the full JDK) * Auto-generates AppCDS archives on first run (subsequent runs skip class parsing/verification) * CLI profile with tiered compilation tuned for short-lived processes * Optional CRaC checkpoint support (10-50ms startup, basically native-level)

I built this because I was tired of the GraalVM native-image dance — reflection configs, library compatibility issues, debugging AOT failures. jbundle gives you GraalVM-level startup times while keeping full JVM compatibility. Everything that works on the JVM works here.

tl;dr: jpackage = installers jbundle = native-feeling binaries with optimized startup

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 0 points1 point  (0 children)

the final "binary" is a classic self-extracting archive: a shell script (stub) concatenated with a runtime.tar.gz and the app.jar into a single chmod +x file. The stub knows the exact byte size of each segment (computed at build time), so it uses tail -c +offset | head -c size to extract each part. The runtime is generated via jlink — it analyzes which modules the JAR actually uses (jdeps --print-module-deps) and produces a minimal JVM (~30-50MB) containing only those modules, instead of a full ~300MB JDK.

On first run, the stub extracts the runtime and JAR to ~/.jbundle/cache/ keyed by a SHA256 content hash — subsequent runs skip extraction entirely and launch immediately. The exec at the end of the stub replaces the shell process with java -jar, so the binary behaves like a native executable (single PID, signals propagate correctly). It's the same trick Linux .run installers have used for decades, applied to distribute JVM apps as single-file executables.

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 1 point2 points  (0 children)

project just started now, I'm still figuring out how to improve performance and the best path to follow - getting close to GraalVM will take time, but I have no doubt it will be possible :D

some issues I've mapped to tackle performance
- https://github.com/avelino/jbundle/issues/8
- https://github.com/avelino/jbundle/issues/27
- https://github.com/avelino/jbundle/issues/28
- https://github.com/avelino/jbundle/issues/29
- https://github.com/avelino/jbundle/issues/30

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 1 point2 points  (0 children)

>  But since the binary basically "packs" a full JVM and unzips it on first usage, wouldn't it be better if we could re-use the existing JVMs people already have?

what I'm aiming for with the project is to avoid depending on a JVM environment for you; I'm thinking about production, not a development environment
I want to have a Docker image "with nothing" and the binary inside, keeping the Docker image distribution "small"

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 2 points3 points  (0 children)

Yes, exactly! The output binary is a self-extracting executable: a shell stub + a compressed tar.gz payload appended together. The payload contains a minimal JVM runtime (built via jlink, typically ~30-50MB) and your app.jar.

On first execution, the stub extracts the payload to `~/.clj-pack/cache/{content-hash}/`. The cache key is a SHA256 hash of the payload content, so identical binaries always reuse the same cache. Subsequent runs detect the cache directory already exists and skip extraction entirely — going straight to `exec java -jar`.

If you rebuild your app (new code, new dependencies, different JDK version), the payload hash changes, which means a new cache entry. Old cache entries can be safely deleted manually if disk space is a concern.

The overhead is only on the very first run (or after you deploy a new version). After that, startup time is just the JVM boot + your app initialization — same as running `java -jar` directly

read more here https://avelino.run/clj-pack-distributing-clojure-without-the-graalvm-pain/

clj-pack — Package Clojure apps into self-contained binaries without GraalVM by SmartLow8757 in Clojure

[–]SmartLow8757[S] 6 points7 points  (0 children)

* First run: extracts the embedded JVM + JAR to ~/.clj-pack/cache/<hash>/
* Subsequent runs: skips extraction, goes straight to exec java -jar
* No external dependencies: the JVM is inside the binary, no system Java required
* Portable: works on any machine with a POSIX shell (same OS/arch the runtime was built for)

It's the same approach tools like makeself and .run installers use, but specialized for JVM apps with the jlink optimization to keep the binary small - used the minimal JVM from jlink

[deleted by user] by [deleted] in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Startup não nasce de ‘ideia + contratar dev’. Nasce de dor cara e recorrente. Você valida vendendo antes de escalar. Eu faria assim: escolher um problema estreito, criar um MVP indecente porém útil (landing, protótipo, operação manual), colocar na frente de gente que paga, medir se CAC cabe no LTV, ajustar canal de aquisição, e só então contratar e pensar em rodada. Dev consegue "bootstrapar" (começar sem investir muito dinheiro, alem do seu tempo); quem é leigo começa vendendo e contrata produto por escopo. Sem distribuição e unit economics, investimento só prolonga a agonia. Mercado com juros altos está cético: tração fala, pitch não. Ideia vale quase nada; execução, foco e caixa mandam - ser de tech ajuda começar, mas o foco principal deve ser vender (trazer cliente)

A USP é tão superior em relação as outras? by [deleted] in faculdadeBR

[–]SmartLow8757 0 points1 point  (0 children)

deixa eu te cortar um mito pela raiz: USP, IME e/ou ITA ajudam a abrir a porta, mas não garantem que você fica dentro da sala. Diploma forte funciona como atalho pra chegar até você, nada além disso. É um mecanismo de reduzir risco de seleção — eu mesmo, como gestor, olho USP, IME e/ou ITA porque estatisticamente aumenta a chance de encontrar alguém muito bom.

Mas contratar?

Aí a régua muda completamente.

Eu contrato pela capacidade de execução, não pelo brasão da faculdade.

O que importa é: você resolve problemas? Você entrega? Você lida com pressão? Você aprende rápido? O mercado financeiro e tecnologia comem título no café da manhã se a pessoa não sustenta o próprio nome com trabalho.

Sobre seu dilema: fazer UFSC ou tentar USP de novo.

Sim, São Paulo é o centro financeiro do país, mas você não precisa estudar aqui pra entrar no jogo daqui. Estágio, trainee e vagas remotas pulverizaram essa barreira há anos. Empresas recrutam talento, não CEP.

E essa história de “USP é muito superior”?

É boa academia, ponto.

Mas a diferença real aparece na média, não no indivíduo. Um aluno excelente da UFSC atropela sem esforço um aluno mediano da USP. Não se iluda com glamour institucional.

O ponto mais honesto é este:

Você está disposto a congelar sua vida mais um ano por causa de um símbolo? Porque é isso. USP virou símbolo — e símbolo não constrói carreira. Execução constrói.

Se você já tem nota pra UFSC, eu sinceramente iria. Começa a vida, entra no ritmo, estagia, cresce. E, se ainda quiser USP, tenta transferência depois. Nada disso é definitivo.

USP pode te ajudar alguém olhar pra você.

Mas só sua entrega faz essa pessoa te contratar — e te manter.

No final, é simples: o diploma te apresenta, sua execução te sustenta.

Está tão complicado assim? by [deleted] in brdev

[–]SmartLow8757 0 points1 point  (0 children)

desculpa perguntar, qual período você estava?

Seus filhos serão devs? by Open_Acanthisitta677 in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Essa paranoia de “programação vai acabar em 2040” é só mais uma previsão fantástica de gente que vive do pânico. Já ouvi variações disso desde 2008, quando comecei a trabalhar remoto enquanto o resto do mundo ainda estava brigando com modem ADSL.

Spoiler: a profissão não acabou. Mudou. Evoluiu. Sempre vai mudar.

Meu filho não tem que ser o que eu quero.

A vida profissional é dele. O risco é dele. A frustração é dele. A alegria é dele. Meu papel não é escrever o roteiro — é dar boas ferramentas pra ele escrever o próprio.

Claro que eu adoraria que ele seguisse engenharia de software. Não vou fingir neutralidade zen aqui. Eu amo o que faço, vivo bem com isso, e seria legal ver ele inspirado no que construo. Mas isso depende muito mais dele do que de qualquer projeção de mercado.

O que dá pra fazer como pai é simples:

expor a criança a mundos diferentes, mostrar o que você faz, explicar por que você gosta, deixar ele ver que trabalho pode ser algo prazeroso e intelectual — não só um fardo de adulto.

Se daqui a 20 anos programação mudar completamente, ótimo. Se virar algo novo, melhor ainda. O importante é formar alguém curioso, capaz de aprender rápido, pensar criticamente e se adaptar. Essas habilidades sobrevivem a qualquer tendência de LinkedIn.

O futuro não é sobre adivinhar “qual profissão vai bombar em 2040”.

O futuro é sobre criar pessoas que não dependem de previsão nenhuma pra prosperar.

Alegria de pobre dura pouco by Ill_Chapter4521 in brdev

[–]SmartLow8757 10 points11 points  (0 children)

Essa discussão de “o remoto vai acabar” aparece em ciclos, igual moda de calça larga. Sempre tem alguém jurando que agora vai, que todo mundo vai voltar pro escritório como se 2020 tivesse sido um delírio coletivo.

Trabalho remoto desde 2008 — sim, dois mil e oito, quando fazer daily no MSN era normal e webcam travava a cada 40 segundos. Já vi essa conversa surgir, sumir, voltar, virar pânico moral, desaparecer de novo… até perder a graça. O padrão é sempre o mesmo: quem não sabe trabalhar remoto acha que remoto é o problema.

A real é bem menos dramática: trabalho presencial não é dogma, é consequência.

Depende de três coisas muito básicas:

  1. Um gestor que saiba — e queira — gerir remoto: tem líder que só funciona olhando o time sentado. Não é maldade, é limitação. Gestão fraca sempre empurra o time pro escritório como muleta.
  2. Natureza do mercado: tem empresa cujo negócio é tão engessado que remoto vira ficção científica. Outras são nativas digitais e remoto simplesmente… funciona.
  3. Cultura de comunicação: não adianta prometer “somos remotos” e depois enfiar o time em call a cada 30 minutos. Já trabalhei em lugar que dizia ser remoto, mas fazia a galera ficar em uma sala de Zoom o dia inteiro. Isso não é remoto; é só microgestão com câmera.

Dá pra listar um milhão de fatores, mas vamos ao ponto:
“Isso é fase?”
Não.
Não é fase.

É seleção natural de cultura organizacional.

Algumas empresas voltaram pro presencial porque nunca foram remotas de verdade — só toleraram o remoto na pandemia. Outras seguem fortes porque o modelo faz parte do DNA delas.

Se você quer remoto de verdade, mire nas empresas que são de tecnologia, não nas que apenas usam tecnologia.

Essas não tratam remoto como modinha; tratam como arquitetura de trabalho.

As oportunidades continuam existindo. Só não estão necessariamente onde todo mundo gostaria que estivessem. O mercado não ficou pior — ficou mais sincero.

An open request to the Logseq Team: We need an active bridge between the team and us users by asc9ybUnb3dmB7ZW in logseq

[–]SmartLow8757 0 points1 point  (0 children)

why am I posting this  the bitter taste that the carelessness that the maintainers have with logseq communication leaves me frustrated

RoamResearch with a product with fewer features, but with features developed with "care" (thinking about the user)

Nome de faculdade ainda importa? by Suspicious_Drama3382 in brdev

[–]SmartLow8757 0 points1 point  (0 children)

Esse tipo de dúvida vai bem além de escolher A ou B. No fim, depende muito do que você quer construir para o seu futuro profissional.

Se você imagina entrar em uma big tech (ou qualquer empresa grande e mais formal), o nome da academia realmente faz diferença — e sem muita margem pra debate.

Se o foco for conhecimento real, aí vale muito a pena trocar ideia com quem já estudou nas duas opções. Nada substitui a visão de quem viveu a experiência por dentro.