This ignores the first part of my response - if I, as a legitimate user, might get caught up in one of these trees, either by mistakenly approving a bot, or approving a user who approves a bot, and I risk losing my account if this happens, what is my incentive to approve anyone?

Additionally, let's assume I'm a really dumb bot creator, and I keep all of my bots in the same tree. I don't bother to maintain a few legitimate accounts, and I don't bother to have random users approve some of the bots. If my entire tree gets nuked, it's still only a few weeks until I'm back at full force.

With a very slightly smarter bot creator, you also won't have a nice tree:

As a new user looking for an approver, how do I know I'm not requesting (or otherwise getting) approved by a bot? To appear legitimate, they would be incentivized to approve legitimate users, in addition to bots.

A reasonably intelligent bot creator would have several accounts they directly control and use legitimately (this keeps their foot in the door), would mix reaching out to random users for approval with having bots approve bots, and would approve legitimate users in addition to bots. The tree ends up as much more of a tangled graph.

This ignores the first part of my response - if I, as a legitimate user, might get caught up in one of these trees, either by mistakenly approving a bot, or approving a user who approves a bot, and I risk losing my account if this happens, what is my incentive to approve anyone?

Additionally, let's assume I'm a really dumb bot creator, and I keep all of my bots in the same tree. I don't bother to maintain a few legitimate accounts, and I don't bother to have random users approve some of the bots. If my entire tree gets nuked, it's still only a few weeks until I'm back at full force.

With a very slightly smarter bot creator, you also won't have a nice tree:

As a new user looking for an approver, how do I know I'm not requesting (or otherwise getting) approved by a bot? To appear legitimate, they would be incentivized to approve legitimate users, in addition to bots.

A reasonably intelligent bot creator would have several accounts they directly control and use legitimately (this keeps their foot in the door), would mix reaching out to random users for approval with having bots approve bots, and would approve legitimate users in addition to bots. The tree ends up as much more of a tangled graph.

I think this would be too limiting for humans, and not effective for bots.

As a human, unless you know the person in real life, what's the incentive to approve them, if there's a chance you could be banned for their bad behavior?

As a bot creator, you can still achieve exponential growth - every time you create a new bot, you have a new approver, so you go from 1 -> 2 -> 4 -> 8. Even if, on average, you had to wait a week between approvals, in 25 weeks (less that half a year), you could have over 33 million accounts. Even if you play it safe, and don't generate/approve the maximal accounts every week, you'd still have hundreds of thousands to millions in a matter of weeks.

If someone is consistently falling for phishing emails (real, or from the IT department), shouldn't that person eventually be fired? Isn't that a punishment?

If there is neither a punishment nor a reward, what is the incentive to learn? Some people may not need one. Many others do.

I agree that a single failure resulting in the loss of significant income might be harsh, but I think there needs to be a way to convince people to take the issue seriously, and a punishment of some kind is therefore always warranted (e.g. eventual firing).

You can balance out the issue by creating a reward system as well, e.g. if you report all of the test emails sent to you in a year (i.e. not just ignore them), your bonus is increased by X% or something. Similarly, if you report an actual phishing email, your bonus is increased by some percent, even if you initially fell for it. I think it is possible to foster a consciousness and honest culture, with a system that includes punishments.

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.

Are they Bluetooth headphones? If so, check the protocols supported by your phone, and by the headphones, e.g. aptX vs LDAC vs SBC. It's possible that it's not a "downgrade" on the new phone, but rather an upgrade to a better protocol, but unfortunately not one compatible with your headphones, so you end up using a low quality fallback.

You may also want to check your settings, and see if you can select a specific protocol. Sometimes a lesser protocol is chosen by default, if the better protocol uses more battery. This may be available to you in the phone settings, or as an option in an app for the headphones (e.g. my Anker Soundcore app allows choosing between two protocols).

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?

If your computer is compromised to the point someone can read the key, read words 2-5 again.

This is FUD. Even if Signal encrypted the local data, at the point someone can run a process on your system, there's nothing to stop the attacker from adding a modified version of the Signal app, updating your path, shortcuts, etc to point to the malicious version, and waiting for you to supply the pin/password. They can siphon the data off then.

Anyone with actual need for concern should probably only be using their phone anyway, because it cuts your attack surface by half (more than half if you have multiple computers), and you can expect to be in possession/control of your phone at all times, vs a computer that is often left unattended.

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.

From http://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages#desktop_restore:

Signal Desktop does not support transferring message history to or from any device.

I think this conflates "ecosystem" with "closed ecosystem" or "walled garden."

I agree that closed ecosystems are frustrating lock-in tactics. But open ecosystems exist - KDE connect actually shows a good example. It was built for the KDE ecosystem (desktop environment, apps, and services that integrate and work well with each other), but makes the protocol open, so clients can exist for Gnome, and other platforms.

I recognize this is mostly semantics, but wanted to call it out because I think the integration and interoperability afforded by an "ecosystem" is extremely user friendly in general. It only becomes a problem when it is weaponized to lock you in.

You're describing something very different - you already have the messages, and you already have them decrypted. You can transfer them without the keys. If someone gets your device, they have them, too.

Whether Signal keeps the encrypted the messages or not, a new device has no way of getting the old messages from the server.

"They" is the browser/browser maker. The browser, acting as the client, would have access to the keys and data. The browser maker could do whatever they want with it.

To be clear, I'm not saying they would, only that it defeats the purpose of an E2E chat, where your goal is to minimize/eliminate the possibility of snooping.

Using an E2E chat app in your browser necessarily makes the keys and decrypted messages available to your browser. They would have the ability to read messages, impersonate users, alter messages, etc. It would defeat the purpose of a secure messaging platform.

There is no sharing of messages between linked devices - that would break forward secrecy, which prevents a successful attacker from getting historical messages. See the first bullet of: https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices

Messages are encrypted per device, not per user (https://signal.org/docs/specifications/sesame/), and forward secrecy is preserved (https://en.m.wikipedia.org/wiki/Forward_secrecy, for the concept in general, and https://signal.org/docs/specifications/doubleratchet/ for Signal's specific approach).

Yes, as long as you set up the desktop client before sending the message.

Messages sent with Signal are encrypted per device, not per user, so if your desktop client doesn't exist when the message is sent, it is never encrypted and sent for that device.

When you set up a new client, you will only see new messages.

See https://signal.org/docs/specifications/sesame/ for details.

This is not entirely correct. Messages are stored on their servers temporarily (last I saw, for up to 30 days), so that even if your device is offline for a while, you still get all your messages.

In theory, you could have messages waiting in your queue for device A, when you add device B, but device B will still not get the messages, even though the encrypted message is still on their servers.

This is because messages are encrypted per device, rather than per user. So if you have a friend who uses a phone and computer, and you also use a phone and computer, the client sending the message encrypts it three times, and sends each encrypted copy to the server. Each client then pulls its copy, and decrypts it. If a device does not exist when the message is encrypted and sent, it is never encrypted for that device, so that new device cannot pull the message down and decrypt it.

For more details: https://signal.org/docs/specifications/sesame/

Google is certainly guilty of killing off lots of products, but:

The video demonstrates the ecosystem working now, using features that have existed for years, most of which work across hardware platforms from multiple vendors, as well as multiple operating systems (i.e. features that won't disappear on Google's whim, because they don't actually control the tech, they leverage open standards, etc).

Let's also not pretend like Apple has never killed a product, service, or feature. Ecosystems grow, shrink, and change all the time. If you prefer one offering over the other, use it. That's the entire point of the video.

I think that applies to the others as well, except in some cases when they are tuned to the same fundamental, e.g. Bb Trumpet, BBb Tuba. But tubas commonly come in C, F, and Eb as well (trumpet variants also exist, but are less common).

Because of the rotary valves and trigger? Or for some other reason?

If that's the only difference you're calling out, it's worth noting rotary valves and triggers show up on other instruments as well. In particular, tubas often have rotary valves, and it's not uncommon to see trigger valves on trombones.

Having played both piston valves and rotary, the difference is negligible.

🐈+🐢=🐂🐂🐂

"Desktop publishing" is the category of software you want. I've not used it, but I believe Scribus is the standard FOSS tool for this. If you want a simple graphical way to make your album, this is the way.

Many people have metnioned LaTex - I would not recommend it for this purpose. LaTex, while powerful, will have a steep learning curve, and isn't really made for artistic tasks - its purpose is for writing technical papers. From literally the first two sentences on the project site:

LaTeX is a high-quality typesetting system; it includes features designed for the production of technical and scientific documentation. LaTeX is the de facto standard for the communication and publication of scientific documents.

It's probably possible to make a beautiful photo album with LaTex, but without a lot of work, it's more likely to come out looking like a calculator manual.

I think it is less a question of whether the voice sounds like Scarlett Johansson, as that is subjective and arbitrary (e.g. assume you could objectively measure the similarity, what's the acceptable cut off - 80%? 90%?). The same is true for the uniqueness of her voice.

I think the real question will come down to intention. They clearly wanted her voice. Did they intentionally attempt to replicate it when they couldn't have the real thing? If so, there is precedent that would suggest they could be in a little trouble here, e.g. https://www.latimes.com/archives/la-xpm-1990-05-09-me-238-story.html

This kind of reminds me of Crispin Glover, from Back to the Future. He tried to negotiate a higher pay for the second movie, so the producers hired a different actor to play the role, but deliberately made the actor up to look like Glover. In response, Glover sued the producers and won. It set a critical precedent for Hollywood, about using someone's likeness without consent.

The article mentions they reached out to her two days before the launch - if she had said 'OK,' there's no way they could have even recorded what they needed from her, let alone trained the model in time for the presentation. So they must have had a Scarlett Johansson voice ready to go. Other than training the model on movies (really not ideal for a high quality voice model), how would they have gotten the recordings they needed?

If they hired a "random" voice actress, they might not run into issues. But if at any point they had a job listing, a discussion with a talent manager, or anything else where they mentioned wanting a "Scarlett Johansson sound-alike," they might have dug themselves a nice hole here.

Specifically regarding your question about hiring a voice actor that sounds like someone else - this is commonly done to replace people for cartoons. I don't think it's an issue if you are playing a character. But if you deliberately impersonate a person, there might be some trouble.

Kamp Krusty

Homer at the Bat, season 3.

Two Bad Neighbors

Not to justify the actions of the shooter, but ringing the doorbell before breaking in is definitely a thing. It's a means of checking if the house is occupied - if you're just trying to steal things, an unoccupied house is ideal, and if someone answers when you ring, it's easy enough to make up an excuse and walk away.

A much better solution than a gun, though, is a security door (similar to a screen door, but more kick proof).

Not sure if it's what you're looking for, but lirc has a database. Instructions for contributing files can be found here, files should adhere to the checklist here.

Considering that you are not using their software, was the laptop worth the premium you paid for it, vs buying from Clevo directly?

I figured the hardware and software coming from the same vendor would yield the best results, and wanted to support a company that supports right-to-repair, and Linux in general. But ultimately I found Pop!_OS buggy and had performance issues, so I'm not using their OS, and their firmware is causing issues with my SSD, so I'd like to be off of it as well (but was told "there's no process for reverting to the proprietary firmware“ for the specific model I have). I could have bought a Clevo directly, saving hundreds of dollars, and probably had a better working machine.

Would not recommend System76. I've had many issues with my machine (primarily software, related to their buggy custom firmware, and Pop!_OS, until I ditched that for stock Ubuntu). Their support has been terrible - rather similar to OP's, actually. I've had the laptop for about 2.5 years, and I'm checking practically daily for something to replace it.

For what it's worth, I just bought a TCL 55S450F (55 inch 4K HDR FireTV) specifically because it does not ever need an internet connection to function (expressly stated in the manual). It is currently on Amazon for $268 (they have other sizes at other prices). It's a great TV, considering the price. The only real drawback for me is the remote is Bluetooth, rather than infrared (less compatible with universal remotes).

Note that for full dumb TV effect, you'll want to go into the settings and tell it to resume the last input, rather than going to the home screen when you turn it on (without connecting it to the Internet, the home screen is basically just a big banner telling you it's not connected, and when you dismiss that, it just allows you to access inputs and manage settings).

You are falling into a common trap. LLMs do not have understanding - asking it to do things like convert dates and put them on a number line may yield correct results sometimes, but since the LLM does not understand what it's doing, it may "hallucinate" dates that look correct, but don't actually align with the source.

You might get lucky. Based on https://support.system76.com/articles/system-firmware/, it doesn't seem to be all models. Note however that the list is out-of-date; my galp5 is not listed, but does not work. Fortunately, I found this out doing a RAM check, and not a firmware upgrade.

My usb-c ports can be a little touchy, too. The SD card slot is also really bad - the card has to be positioned perfectly to slide in, or it jams. I'm also upset that the usb-c port can only be used for charging after a full boot. It cannot be used to perform firmware updates, or even to do a ram test. This means day-to-day, usb-c can be used, but I have to keep track of the barrel charger, just in case. This, of course, was not specified on the product details page (nor, I think, that only one of the two usb-c ports could be used for charging - it's possible I overlooked that, but still frustrating on an expensive laptop that lists usb-c charging as a feature).

I currently have a System76 laptop, and sincerely regret my purchase. When I purchased it, the Framework was not out yet - I wanted to support a company that supports right-to-repair, and figured since they controlled the hardware, firmware, and software (Pop!_OS), it would be a good, stable experience. It has not been, and support has generally been poor. I know other people have had better experiences than I have, but personally, I won't be buying from them again.

I haven't personally used Purism, but former co-workers spoke really poorly of them. They were trying to buy a big batch for work, and said the build quality was awful. Additionally: https://youtu.be/wKegmu0V75s