Are you building something for fun, or something meant to last? If you want it to last, I’d be looking at old frameworks - obviously React, and Vue has also been around a long time. Angular is also old, but Google maintains it, so they could kill it at any moment (and personally I hated it when I had to use it).

I’ve never used Svelte, and don’t know much about it. From a quick look online, primarily what it does differently than other frameworks is use a compiler. I’d be a little concerned here, because what it compiles to is JS, as that’s what runs in your browser. This can make debugging more challenging, because when you pull up the debugger in the browser, it’s not your code, it’s the compiled code. They may have solved this problem, they may have browser extensions and IDE plugins to help with this, but find out before you start. If you can’t use a debugger, use a different framework.

But you (almost certainly) started using those backend frameworks after you had experience. You learned the basics first, and then incorporated frameworks when you got to larger projects.

I came here to say the same thing as the original reply in this thread, albeit with slightly different justification:

If you don’t know the basics, and can’t build a functional site with just HTML/CSS/JavaScript, all of the frameworks will be a nightmare. You should really learn those first, even if it means building a practice site, or completely rebuilding your frontend when you decide to use a framework.

The frameworks can make your life easier, but there’s a learning curve, and a huge cognitive burden especially when you are just starting. You’ll fight them more than work with them at the start.

That all said, never use what’s “hip” on the frontend. JS frameworks typically have the lifespan of a house fly. React is one of very, very few that has remained popular, and continued to get updates for a long time (at least in JS framework terms). It’s a solid choice with a huge community, good docs, good tooling, etc. There may be other valid choices, but seriously - avoid anything new and flashy, because that usually just means its deficiencies haven’t been found yet, and as soon as they are, there will be a new framework.

I don’t have as much experience with HASS, but I did use Mycroft for quite a while (stopped only because I had multiple big moves, and ended up in a place small enough voice control didn’t really make sense any more). There were a few intent parsers used with/made for that:

https://github.com/MycroftAI/adapt https://github.com/MycroftAI/padatious https://github.com/MycroftAI/padaos

In my experience, Adapt was far and away the most reliable. If you go the route of rolling your own solution, I’d recommend checking that out, and using the absolute minimum number of words to design your intents. E.g. require “off” and an entity, and nothing else, so that “AC off,” “turn off the AC,” and “turn the AC off” all work. This reduces the number of words your STT has to transcribe correctly, and allows flexibility in command phrasing.

If you borrow a little more from Mycroft, they had “fallback” skills that were triggered when an intent couldn’t be matched. You could use the same idea, and use https://github.com/seatgeek/thefuzz to fuzzy match entities and keywords, to try to handle remaining cases where STT fails. I believe that is what this community made skill attempted to do: https://github.com/MycroftAI/skill-homeassistant (I think there were more than one HASS skill implementations, so I could be conflating this with another).

Another comment mentioned OVOS/Neon - those forked off of Mycroft, so you may see overlap if you investigate those as well.

Fediverse… Fed… Federated. Unifying it would defeat the purpose. Yes, there could be a single platform, with federated hosting, but multiple platforms working with a single protocol is a good thing.

Consider the web - in the old days, it was an open platform. Then Internet Explorer got a stranglehold, and to use the web practically required using IE on Windows (many sites did not work in other browsers). Eventually we righted the ship, but now Chromium browsers are taking over, and we’re heading in a similar direction.

For the fediverse to remain open and effective, we should embrace extra platforms*. It prevents anyone getting too much control over the protocol, prevents lock-in, prevents centralization, etc.

*We should generally encourage use/development of the same protocol, though.

I used Windows growing up, switched to Linux in highschool on my personal machines, and was forced to use Mac for nearly 10 years at work. In my experience, they all have problems, and the worst part is always early on. After you’ve used them for a while and have gotten familiar/comfortable, the problems get easier to deal with, and switching back (or on to something new) becomes more daunting/uncomfortable than dealing with what you have. So in that sense, yes, it will get easier.

Also, as hardware ages, you often see better support (though laptops can be tricky, as they are not standardized).

Keep in mind, when you use Windows or Mac, you’re using a machine built for that OS and (presumably) supported by the manufacturer for that OS (especially with custom drivers). If you give Linux the same advantage (buy a machine with Linux pre-installed, or with Linux “officially supported”), you’re much more likely to have a similar, stable experience.

Also, I’ve had better stability with stock Ubuntu than its derivatives (Pop!_OS and Mint). It might be worth trying an upstream distro, to see if you have better stability.

Go see a show at The Comedy Cellar. Book it in advance if you can. If it’s “sold out,” you can still show up and wait before showtime - I think they only sell about half the seats online, so if you show up 30-60 minutes before the show, you can probably get in.

Having daily driven Windows (~6 years growing up), MacOS (8+ years for work), Linux (~18 years on personal and (some) work machines), and ChromeOS (~2 years, on a cheap Chromebook used while I was traveling places I didn’t want to take an expensive machine), if my options were Windows, MacOS, or ChromeOS, I would 100% take ChromeOS. Even on cheap hardware, it was a better user experience than the others… Though I will caveat that with: when I had to do work that required heavy lifting, I remoted into my Linux desktop. But that was a hardware limitation, rather than a software limitation.

For people who know what they’re doing, I recommend traditional Linux. For those who don’t, I recommend ChromeOS. Mac and Windows are both also run by mega corps, they’re all spying on users… at least ChromeOS is performant and stable.

Do you know if this means desktop Linux apps in general will no longer be supported?

Malcolm Jamal Warner also died within the past few days.

Raster images do not need to be rendered - see Rendering:

Rendering is the process of generating a photorealistic or non-photorealistic image from input data such as 3D models…Today, to “render” commonly means to generate an image or video from a precise description (often created by an artist) using a computer program.

Note that “render” is a fairly generic term, and it is sometimes used like “render to the screen,” to just mean to display something. Rasterisation may be a better term to use here, since it only applies to vector graphics, and is the part of the process I am referring to.

In any case, except for possibly reading fewer bytes from disk, the vector case includes all the same compute and memory cost as the raster image - it just has added overhead to compute the bitmap. On modern hardware, this doesn’t take terribly long, but it does mean we’re using more compute just to launch/load things.

It’s also worth noting apps have to ship higher resolution assets now, due to higher resolution displays. This can include video, audio, images, etc. Videos and images may be included at multiple resolutions, to account for different sized displays.

For images, many might assume vectors are the answer, but vectors have to be rendered at runtime, which increases startup time in the best case scenario, and isn’t even always supported on all platforms, meaning they have to be shipped alongside raster assets of a few different sizes, further increasing package bloat. And of course the code grows to add the logic to properly handle all the different asset types and sizes.

All this (packaging dependencies, plus assets/asset handling) to say it isn’t always malware, ads, electron, etc. Sometimes it’s just trying to make something that looks nice and runs well (enough) on any machine.

Many apps ship both vectors and raster images. It is worth nothing that vectors save space, but increase compute (the image now has to be rendered at runtime), contributing to slower startup times.

I’ve had the same problem with HeliBoard learning garbage. I just changed my settings though, and I think it should help:

1. Open HeliBoard settings
2. Open Text correction settings
3. Scroll all the way to the bottom, and turn off “Add words to personal dictionary”

If you scroll all the way to the top again, you can manually manage the personal dictionary, including adding words you do want, and deleting any junk that was added by mistake, before switching that setting off.

In a scientific context, a hypothesis is a guess, based on current knowledge, including existing laws and theories. It explicitly leaves room to be wrong, and is intended to be tested to determine correctness (to be a valid hypothesis, it must be testable). The results of testing the hypothesis (i.e. running an experiment) may support or disprove existing laws/theories.

A theorem is something that is/can be proven from axioms (accepted/known truths). These are pretty well relegated to math and similar disciplines (e.g. computer science), that aren’t dealing with “reality,” so much as “ideas.” In the real world, a perfect right triangle can’t exist, so there’s no way to look at the representation of a triangle and prove anything about the lengths of its sides and their relations to each other, and certainly no way to extract truth that applies to all other right triangles. But in the conceptual world of math, it’s trivial to describe a perfect right triangle, and prove from simple axioms that the length of the hypotenuse is equal to the square root of the sum of the squares of the remaining two sides (the Pythagorean Theorem).

Note that while theorems are generally accepted as truth, they are still sometimes disproved - errors in proofs are possible, and even axioms can be found to be false, shaking up any theorems that were built from them.

A law describes what happens, a theory explains why. The law of gravity says that if you drop an item, it will fall to the ground. The theory of relativity explains that the “fall” occurs due to the curvature of space time.

If your drive is the bottleneck, this will make things worse. If you want to proceed:

You’re already using ffmpeg to get the sequence of frames, correct? You can add the -ss and -t flags to give a start time and a duration. Generate a list of offsets by dividing the length of video by the number of processes you want, and feed them through gnu parallel to your ffmpeg command.

My first thought was similar - there might be some hardware acceleration happening for the jpgs that isn’t for the other formats, resulting in a CPU bottleneck. A modern harddrive over USB3.0 should be capable of hundreds of megabits to several gigabits per second. It seems unlikely that’s your bottleneck (though you can feel free to share stats and correct the assumption if this is incorrect - if your pngs are in the 40 megabyte range, your 3.5 per second would be pretty taxing).

If you are seeing only 1 CPU core at 100%, perhaps you could split the video clip, and process multiple clips in parallel?

it doesn’t unravel the underlying complexity of what it does… these alternative syntaxes tend to make some easy cases easy, but they have no idea what to do with more complicated cases

This can be said of any higher-level language, or API. There is always a cost to abstraction. Binary -> Assembly -> C -> Python. As you go up that chain, many things get easier, but some things become impossible. You always have the option to drop down, though, and these regex tools are no different. Software development, sysops, devops, etc are full of compromises like this.

You are conflating the concept and the implementation. PFS is a feature of network protocols, and they are a frequently cited example, but they are not part of the definition. From your second link, the definition is:

Perfect forward secrecy (PFS for short) refers to the property of key-exchange protocols (Key Exchange) by which the exposure of long-term keying material, used in the protocol to authenticate and negotiate session keys, does not compromise the secrecy of session keys established before the exposure.

And your third link:

Forward secrecy (FS): a key management scheme ensures forward secrecy if an adversary that corrupts (by a node compromise) a set of keys at some generations j and prior to generation i, where 1 ≤ j < i, is not able to use these keys to compute a usable key at a generation k where k ≥ i.

Neither of these mention networks, only protocols/schemes, which are concepts. Cryptography exists outside networks, and outside computer science (even if that is where it finds the most use).

Funnily enough, these two definitions (which I’ll remind you, come from the links you provided) are directly contradictory. The first describes protecting information “before the exposure” (i.e. past messages), while the second says a compromise at j cannot be used to compromise k, where k is strictly greater than j (i.e. a future message). So much for the hard and fast definition from “professional cryptographers.”

Now, what you’ve described with matrix sounds like it is having a client send old messages to the server, which are then sent to another client. The fact the content is old is irrelevant - the content is sent in new messages, using new sessions, with new keys. This is different from what I described, about a new client downloading old messages (encrypted with the original key) from the server. In any case, both of these scenarios create an attack vector through which an adversary can get all of your old messages, which, whether you believe violates PFS by your chosen definition or not, does defeat its purpose (perhaps you prefer this phrasing to “break” or “breach”).

This seems to align with what you said in your first response, that Signal’s goal is to “limit privacy leaks,” which I agree with. I’m not sure why we’ve gotten so hung up on semantics.

I wasn’t going to address this, but since you brought it up twice, running a forum is not much of a credential. Anyone can start a forum. There are forums for vaxxers and forums for antivaxxers, forums for atheists and forums for believers, forums for vegans and forums for carnivores. Not everyone running these forums is an expert, and necessarily, not all of them are “right.” This isn’t to say you don’t have any knowledge of the subject matter, only that running a forum isn’t proof you do.

If you’d like to reply, you may have the last word.

I would argue that it is not limited to network traffic, it is the general concept that historical information is not compromised, even if current (including long-term) secrets are compromised.

From my comment earlier:

There is no sharing of messages between linked devices - that would break forward secrecy

This describes devices linked to an account, where each is retrieving messages from the server - not a point-to-point transfer, which is how data is transferred from one Android device to another. If a new device could retrieve and decrypt old messages on the server, that would be a breach of the forward security concept.