Avatar
SER
1348426a5ab0db04f2e2ec65472e08e3260b5faea53d2f2375aa16e8a48d9e20
Refugee from an endless series of Eternal Septembers

Food suggestions only? Because burning calories through exercise increases the deficit.

For intermittent fasting, never underestimate the efficacy of filling your belly with water. When you feel hungry, drink your fill of water.

Broth (e.g. boullion) doesn't have many calories, and satisfies that savory craving I always get.

Your's has a *nose*‽ That's genius. Or, just a snorkle mask. Anyway, my wife loves her onion glasses. I prefer to suffer.

If you're a B2B sales person trying to get my business, and you act as if it would be my honor to be your client, I'm going to assume your company treats all client interactions the same way and that your customer support is going to be insufferable.

I've seen discussions about alternatives, but no consensus. Shouldn't we have the new boat first, before we sink the old one?

It might be that 1,00 people building alternatives evolves a better format; it's even odds that everyone will just drown. I think it'd be safer to toss the golden apple into the room if Nostr were more established.

I would learn about you. Take me to your opposition.

This would make a perfect example of a great, legitimate use for a public ledger which _isn't_ cryptocurrency, and it seems like a no-brainer decision. The devil in the details is preventing conflicts: with github, a relative few are responsible for accepting PRs, which gives a point of control that effectively functions as a DB unique ID constraint on NIP IDs. How do you decentralize this and continue to prevent NIP ID conflicts?

Which Nostr node software supports all of NIPs required by 0xChat? Several don't.

Recommendations for a next-gen cron?

I have a half dozen systems running systemd... and one experiment running dinit. I find myself enjoying dinit immensly. It's incredibly fast, compared to systemd, and a pleasure to work with.

However, on that one dinit system, I'm running cron, and I _don't_ like that. I'd forgotten how bad it was; systemd timers are far better.

What's a next-gen cron replacement that isn't systemd? That treats non-root users as first-class citizens, acts sanely in an X session, and can load session vars?

Recommendations for people to follow who *don't* talk about zaps, or bitcoin, or cryptocurrencies? There are no end of people to follow for that content; I'd like some other content in my feed.

Replying to Avatar fiatjaf

I'm struggling to understand what "powa" and "puru" mean in Japanese.

#[0] 's https://github.com/mattn/algia has these two special commands that post these two very specific things, but translators are not helping me figure them out.

"powa" is obviously an homage to the 1991 cinema masterpiece, "The Perfect Weapon," where the intro is SNAP's hit "The Power."

"puru" is a Sanskrit word meaning "much," "many," or "abundant."

Their placement in the help text is an easter egg letting you know that, by mastering the tool, you achieve an abundance of skill and become the perfect Nostr weapon.

If you're going to do NFT, I'd rather have it on Bitcoin than have the token issued by some third party, as is common.

I fought the IRS' idiotic automated system, and I won.

Very few organizations make it so hard to give them money.

My hero.

Nym@nostr.fan is a midjourney art bot; I wonder how many Nostr accounts are ChatGPT?

Replying to Avatar Guy Swann

Prediction: AI is going to be a revolutionary *interface* to the ocean of software and tools we already use (including those that build more software and tools) that will unlock vast amounts of application function that is simply lost due to illiteracy and a far too vast information space.

Check out how Microsoft Copilot works: AI is more akin to the revolution in computer interfacing that the mouse and keyboard were, or that multi-touch was for the smartphone revolution, than it is a standalone app with some new specific functionality. It will end up being a computer (or internet) wide, contextually relevant knowledge base for how to use any and all of the tools available to you, as if it's all just a single, universal UI system to accomplish whatever you need at any moment.

AI will be able to use ALL of our apps, better than you we for most of them because it doesn't have to "learn" them. To the point that we might not need to bother to ever know how to use many apps, programs, CLI tools, or functions on our computers, because if the AI knows how to accomplish what we are looking for by using them, why bother?

Think about it like a calculator: Why learn how to manually do long division when it's just the "divide" button on one of numerous devices always within reach? Or having a physical map: why remember directions when you have a live map with traffic updates at all times in your pocket. One that speaks directions out loud?

This same relationship is about to apply to basically any or all software on your computer. It can integrate with web requests, run conversions, knows all the commands in your command line by heart and which ones will help in your current task, it will predict what you might need next, it can accomplish short, simple tasks that you might have needed an app or extension to accomplish before, but now AI can create a script or executable on the fly, specific to the exact situation & instance in which you need the functionality... so then why save it? The AI can just write and execute new code next time, that is specific to the next situation.

I bet that in just a few short years, interacting with a computer *without* an interfacing AI will feel like trying to sprint in knee deep water. This is going to put a 2x-4x growth trend every year in user speed and capacity to accomplish their goals **on top** of Moore's law's already exponential increase in *computing* power.

AI will create an exponential growth of *user* power on top of the already exponential growth in *computational* power.

The comment about long division is apt, I think. I do think increasingly fewer people understand basic concepts; we've reversed the great education of the masses that began with the printing press. I believe much of the anti-science conspiracy-based sub-culture we've been seeing is a result of this. Maybe we *will* let computers do all of our critical thinking for us, and move increasingly back into a dark ages of wealthy lords ruling superstitious peasants who think spirits make the wind blow, and people who can do algebra are magicians.

I hope not, but that does seem the direction it is going.

I shouldn't be as old as I am and still discovering new vegetables at the grocery.

"Ramps?" Really? A new sort of garlic/scallion/green onion thing?? WHERE ARE THESE THINGS COMING FROM‽‽

Replying to Avatar t4es5ter5

1. Performance issues: Some users have reported performance issues with VS Code, particularly when working with large projects. The Electron framework on which it is built can cause sluggishness, high memory usage, and slow startup times.

2. Privacy concerns: Some people are concerned about Microsoft's data collection practices. They may feel uneasy about using VS Code due to potential privacy risks, despite the availability of telemetry settings to control data sharing.

3. Extension quality and fragmentation: While the extension ecosystem is one of VS Code's strengths, it can also be a weakness. Some users have noted that the quality and compatibility of extensions can be hit or miss, leading to a fragmented experience.

4. Open-source alternatives: Some developers prefer to use open-source software and may dislike VS Code because it is developed by Microsoft, a company with a mixed history regarding open source. They may opt for alternatives like Atom, Sublime Text, or Vim.

5. Lack of advanced features: While VS Code is feature-rich, it may not have all the advanced capabilities that more specialized IDEs offer, such as deep language integration or robust refactoring tools. Some developers may prefer to use more powerful, language-specific IDEs.

6. Overwhelming configuration: The sheer number of configuration options in VS Code can be daunting for some users, who may feel overwhelmed when trying to customize their setup.

7. Frequent updates: VS Code has a rapid release cycle, which can be both a strength and a weakness. Some users may be frustrated by the constant updates and the potential for breaking changes or new bugs.

Ditto. You said it better than I could.

I think, also, because it's not built around a keyboard model, such as helix, emacs, vi(m), kakoune, et al. are. I find, when writing text, mousing in whatever hardware form is anti-ergonomic. Editors built around keyboards as an editing first-principle are better at it. VS Code starts at a disadvantage, for me, because it's designed around needing a pointing device for many things.

Filters - proper sieves - are such a great, never-implemented idea! But why not?

I keep almost posting a whiney rant I wrote about how utterly tired I am with Mastodon, b/c of The Eternal (Twitter-migration) September and how political content is practically unavoidable there now. It's exacerbated by the strong pressure to boost content.

A negative filter would do the trick, although most people probably wouldn't label their stuff well.

Yessss.

I do want the coffee, though. I've discovered that the trick is to get the right volume of insulated mug. Too big, it cools before I'm done. More, smaller cups > fewer, larger cups.

The exception are Zojirushi thermoses. I swear those have magical R-values.

Someone on Mastodon just posted a discussion titled: "Right of Reply, or: who should be able to reply to your posts on a social network, and how do we technically enforce that?"

I'm going to put it out there that people will one day look back and say, "this is the day Mastodon jumped the shark."

The first step was this effort to create defederation lists based on subscription to the defederation list; the second was the assertion by some people that, if you run a node, you have some moral obligation to police your users -- the words used were "this was the job you signed up for." This concept of "right of reply" is absurd.

You're posting content *publically.* You want the right to selectively silence people responding in the public sphere? You get to talk, they don't? If they don't reply directly to your comment, but reference the comment in a completely separate thread, do you get the right to silence them there?

I can't even begin to wrap my brain around the ethical gymnastics needed to justify this, much less the technical impossibility.

Dicking with plugins and package managers wasn't giving me enough churn; I was still too productive, so I switched to kakoune. After I'd gotten used to it, it was too much like emacs, relying heavily on chording, so I switched to helix. Helix is mostly vi with multiple selection ranges and a self-consistent model. And no plugins, if you don't count external LSP servers.

Replying to Avatar fiatjaf

nostr:nevent1qqsgj29telj4jstnkppvjysvvg7salac6cuw3edynu72w2ngl7vacvcpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhszgthwden5te0wfjkccte9ehx7um5wghxyctwvshhyetnw3exjcm5v4jqz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy08wumn8ghj7mn0wd68yttsw43zuam9d3kx7unyv4ezumn9wshszrnhwden5te0dehhxtnvdakz7ds2yrp

Once upon a time I started hosting my small projects on a self-hosted Gitea (I think this was it) server. The problem was that once someone showed up and wanted to make a contribution they were totally unable to. They had to create an account on that stupid server, then the ssh access didn't work for them, then they lost their password on my server and I didn't have SMTP configured to send them a password reset, it was all very very painful.

It would have been beautiful if they could have done

- git nostr send-patch

And then I would do

- git nostr list-patches

- git nostr apply-patch

Or my repositories could have webpages that would list pending patches found on relays and also allow people to comment on them from their browsers.

This is what Sourcehut has done, only with `git send-email` and project mailing lists. They even have CI driven by patch emails.

It's a proven workflow. You're just replacing email with nostr, right?

https://sourcehut.org/blog/2020-07-14-setting-up-ci-for-mailing-lists/

Anyone else have personal experience with this?

I have a friend on Mastodon who I recommended nostr to. He joined, was immediately flooded with what I can only describe as crypto-spam, and bounced. I've spent the past couple of days trying to convince him it's not all that bad, once you get your follows dialed in.

The issue is that the default new users see is pretty awful. Like you say, a casual glance presents a strong "crypto bro" vibe. Personally, I stayed only because the NIPs are so inspiring.

Also, Jack's somehow become the face of Nostr, to the point outside people think he's the inventor. I guess that's neither here nor there, except that Nostr looks from the outside like "Jack's Bitcoin scheme," which is an awkward preconception to have to overcome.

This is the idea behind NIP-39, isn't it? Except that 39 is unfortunately specific; naming service-specific schemes in a NIP is restrictive (how do I verify self-hosted gitlab? Sourcehut? Whatever replaces github?), and also oddly enshrines & sanctifies a small set of services. If NIP-39 were abstracted, and ideally store attestations in notes as you suggest, it would be less tightly coupled.

I was thinking about this issue from a different direction: an attestation mechanism for use in authorization -- kerberos-in-nostr. It'd be a combination of NIP-03, NIP-40, and possibly NIP-06. Keyoxide covers a lot of use cases, so there's overlap. Both assert an (ownership) relationship between two accounts, but one additionally has an attestation from one of the service owners.