mazambazz

I don't think it's equivalent. When Rebble did what they did, it was because Pebble was going under and they had no EOL plan. Rebble took it upon themselves to carry the torch without having been passed it.

If Core were to do the same thing here, it's not the same, because Rebble is still active. You can't kill what's already dead (Pebble), but Rebble is very much still alive.

I've seen you make the comment about the OS being open-sourced a lot. But this largely has nothing to do with the OS. This is a conversation about infrastructure and data. The concern (from what I gathered and will condense greatly) is that Core will take in all the current app data and infrastructure setup, duplicate it themselves, move themselves off of Rebble, and continue developing on it privately.

From the post on rebble.io

> We made it absolutely clear to Eric that scraping for commercial purposes was not an authorized use of the Rebble Web Services.

So, another point of consideration is whether looking at names and pictures so you can personally favorite them constitutes as commercial use. Based on what Eric said, I don't really think so.

I hardly think wanting to be more productive/efficient on your own behalf is "bending over backwards" to save a company.

It could be a project with a deadline, and you want to knock some things out earlier so that there is less crunch time needed in a few weeks.

Maybe you want to get some of your work done early so you can take it easier in near future where you anticipate yourself being preoccupied with other responsibilities.

Or, hear me out. You feel secure in your job position, and simply take pride in your work. You will be there working anyways. I would rather get stuff done and feel productive at work than to have meaningless down time twiddling my thumbs, waiting for a response.

Videos are typically already summarized substitutes for complex topics--topics for which you might need to read text or literature to get the full context of. Now we want to min-max and summarize the video themselves. Then what? If that video summary is too long, we throw it into another LLM to summarize the summary of the summary? To what extent does this end?

There's more to learning than just information density. There's visuals, presentations, explanations. And if you want more proof, then a video played a 2x speed is twice the information density, yet we all know that many videos would be extremely hard to retain anything from at that speed.

Ntfy is phenomenal. I love having my own compiled app for the background notifications on a self-hosted instance. It's so easy to hook any update or alerts I want into and get it delivered to any of my devices.

Also, a really nifty cross-platform clipboard.

Even though I haven't used one in a really long time, the Pebble Time still stands out to me as something I wish I still had.

It's an absolutely shame that Pebble was so innovative and functional, but couldn't reach mass market. But, I am extremely excited and happy that the Pebble team can start it again. I don't like Google for many things, but, I am grateful that the open-sourced PebbleOS. What a joyous day!

I, too, have been caught in the trap of trying to accommodate all possible user flows.

Sometimes you just have to put your foot down and just say "No, that is not how you use this tool".

> Trying to hack on other people's junk with NixOS is just asking for pain.

Yeah, but being that Nix is essentially a giant wrapper for the system, that kind of goes without saying. The other side of the coin is that, using other people's Nix junk is extremely easy. Far easier than what any other distro could hope to achieve.

My favorite example is simple-nixos-mailserver. Try passing someone a dovecot, postfix, and openssh configurations/instructions in any other distro and see how long it takes before they mess up, or more likely, give up.

Whereas with simple-nixos-mailserver, you're guaranteed to get something to work, essentially right out of the box.

Nix and containerization aren't drop-in replacements for each other.

You can use Nix to build containers. Containers on their own don't guarantee reproducibility, especially if the build process isn't static and pure ( how many times do we `sudo apt update` inside a Dockerfile )?

And not everything is going to be containerizable. That only works for most applications. What if we're trying to manage our cloud servers? That's where Nix really shines.

Do you really think that Nix developers don't know how to containerize applications? You think people are using Nix because they refuse to learn how to containerize, and therefore opt to learn a _much more_ difficult and arcane build process? The logic doesn't track there.

I think you're taking the term "immutable" too literally.

Immutable does not mean you cannot change it according to your wishes. It just means that each change must be explicitly declared in order to be included in the next system image.

In some ways, having a declarative, immutable distribution makes the process even easier, as is the case with NixOS. If you want to patch your sudo, it would be as easy as doing

security.sudo.package = { pkgs.sudo.overrideAttrs (old: { patches = [ (fetchPatch {url = "<url>"; sha256 = "<patch sha256sum>"})];})};

And then you're done.

100% truth be told, having a declarative, immutable distro has allowed me to experiment and configure my system way more than I would have otherwise. I mean, I can do anything because I have the safety net of rolling back if I mess up.

Furthermore, being declarative means I know exactly how I got to my end solution, instead of having to memorize a bunch of steps from different attempts that may or may not have been successful.

It depends on the underlying email server. But strictly speaking, the "+" is a valid identifier, and "[email protected]" is a completely different address than "[email protected]".

It just so happens that email servers tend to recognize the usage of "+" as a "tag" and route incoming mail using the tag to the root email that precedes the plus and tag.

But, as the sender, you cannot assume that this is always the behavior. You must assume that those are two different emails.