Sure, but I’m just playing around with small quantized models on my laptop with integrated graphics and the RAM was insanely cheap. It just interests me what LLMs are capable of that can be run on such hardware. For example, llama 3.2 3B only needs about 3.5 GB of RAM, runs at about 10 tokens per second and while it’s in no way comparable to the LLMs that I use for my day to day tasks, it doesn’t seem to be that bad. Llama 3.1 8B runs at about half that speed, which is a bit slow, but still bearable. Anything bigger than that is too slow to be useful, but still interesting to try for comparison.

I’ve got an old desktop with a pretty decent GPU in it with 24 GB of VRAM, but it’s collecting dust. It’s noisy and power hungry (older generation dual socket Intel Xeon) and still incapable of running large LLMs without additional GPUs. Even if it were capable, I wouldn’t want it to be turned on all the time due to the noise and heat in my home office, so I’ve not even tried running anything on it yet.

The only time I can remember 16 GB not being sufficient for me is when I tried to run an LLM that required a tad more than 11 GB and I had just under 11 GB of memory available due to the other applications that were running.

I guess my usage is relatively lightweight. A browser with a maximum of about 100 open tabs, a terminal, a couple of other applications (some of them electron based) and sometimes a VM that I allocate maybe 4 GB to or something. And the occasional Age of Empires II DE, which even runs fine on my other laptop from 2016 with 16 GB of RAM in it. I still ordered 32 GB so I can play around with local LLMs a bit more.

I would look into how Matrix handles this, for example. It involves unique device keys, device verification from a trusted device, and cross-signing. It’s not just some private key that’s spread around to random new devices where you lose track of.

They’ve implemented it in such a way that you only have access to an encrypted chat on a single device, so no syncing between devices. Syncing E2EE chats across devices is more difficult to pull off, but it’s definitely possible and other services do that by default.

I don’t understand the relevance of what you’re saying. Do you mean that the platform should have the right to allow biological females only (following the definitions of your law system)? Do you think that that’s implied when a platform is female only and defensible in court? Not a snarky remark, just genuinely curious what you mean. This case was all about gender identity discrimination and I don’t see how biological sex fits into the picture.

She had sued the platform and its founder Sally Grover in 2022 for unlawful gender identity discrimination in its services, and claimed Ms Grover revoked her account after seeing her photo and “considered her to be male”.

Judge Robert Bromwich said in his ruling that while Ms Tickle was not directly discriminated against, her claim of indirect discrimination was successful as using the Giggle App required her “to have the appearance of a cisgender woman”.

Judge Bromwich said the evidence did not establish Ms Tickle was excluded from Giggle directly “by reason of her gender identity although it remains possible that this was the real but unproven reason”.

A false positive is when it incorrectly determines that a human written text is written by AI. While a detection rate of 99.9% sounds impressive, it’s not very reliable if it comes with a false positive rate of 20%.

“Our analysis shows that the two voices are similar but likely not identical,” Berisha said.

They also point out the main differences between the two voices in the paragraphs below this quote. I do believe that they hired a voice actress and that they didn’t train on SJ’s voice, or at least not entirely. However, I wouldn’t be surprised if there was big push for finding a voice similar to SJ’s voice in Her, no matter how much they deny this.

For me they only work in relatively quiet environments, or with earplugs. As soon as a car drives by it completely drowns out the sound. With music that might not be an issue, but with podcasts or calls it’s very annoying. I’ve bought earplugs especially for this, as my other earbuds have issues with wind while running, but it does feel like it’s defeating the purpose a bit. I guess turning them all the way up would also work, but that doesn’t feel healthy. Other than that I like them and the mic quality is also good according to people I’ve spoken with over the phone.

It is, though. Safari has native support for 3rd party adblockers, it’s just that many people don’t know. AdGuard is one of the good options. Safari is doing the actual blocking for the most part (the extension just hands over the filterlists), but nowadays some of the adblockers include an optional extension that applies some rules for complex ads that are not supported by the Apple API, such as on YouTube. As an end user you just have to install and enable the adblocker.

Then there are also other browsers available with built-in adblockers. Admittedly those are all limited in some ways because they’re forced to use the same browser engine (outside of the EU), but they are very effective at blocking ads.

Note, however, that the mere fact that all those apps exist for iOS adds a lot of value for Apple too. Apple wouldn’t sell nearly as many iPhones if the most important apps weren’t available on their platform. They spin it as if they are only creating value for the app developers without asking for much in return, while the App Store is an enormous cash cow, which they’ve been able to build due to the lack of restrictions (pre DMA). A good API is not just a service for app developers, it’s a way to enhance the user experience and sell more phones, because of all the work that app developers do to turn it into useful and exciting features.

If my calculations are right, at that speed with the numbers from the graph, that would put the energy requirement at about 10 kWh/km. That means that with your motor delivering half of that, the human output actually matches up pretty well with the graph. I’m saying output, because I’m convinced that the graph doesn’t take the calories being burned into account and only shows the work being done to move the bicycle.

I think many people peddle just as hard on an electric bike, so the 5.5 kWh/km is a given, the rest is the energy required to go faster. Since air resistance increases with the square of the speed, it might very well be the case that 14 kWh/km at 25 km/h is more efficient than what the human alone would need to deliver for the same speed.

Edit: I failed to take into account that for the human at the same level of effort the power remains constant, not the energy per kilometer. Going faster at the same power output would reduce the energy expenditure per kilometer for the human to about 4 kWh/km, which would indicate that 10 kWh/km is being delivered by the motor to go faster.

That being said, it might be the case that they just calculated the energy needed to move the bicycle without taking the energy efficiency of the digestive system into account.

I don’t doubt the fact that they take some margin to extend the lifetime of the battery, but if we take iPhones as an example, they:

• charge at a slower rate when nearing 100%
• try to postpone charging the final 20% until the last moment before disconnecting from the wall outlet
• can be software capped at 80% by the user (in newer models)

This makes me suspect that that the margin between what’s reported in software as 100% and the actual capacity of the battery is less than 20%. This also makes sense from the standpoint of the consumer expecting a long battery life on their expensive high-end device, putting pressure on the companies to make the margin smaller and the charging algorithms smarter. Just my observations, of course.

I’m pretty sure that Chrome’s alternative is designed by Google to track you in a way that’s harder to block and gives them more control over the advertising market by forcing advertisers to play along and use their method instead of collecting your data directly. Sure, it’s more private, but it’s still tracking you.

Firefox, on the other hand, is focusing on completely blocking cross-site tracking. They have no incentive to completely block 3rd party cookies as long as there is also a legitimate use case for them, but I guess they will eventually also block them if Chrome is successful in forcing websites to stop relying on them for core functionality.

But then when you’re talking about 10:00 hours without specifying anything else, it actually means something completely different in the local context, apart from it being the exact same time globally. It doesn’t tell you whether it’s night or day at the other persons location. Your default point of reference in that system is the world, while even today, time is mostly used in a local context for most people. When I’m talking to someone abroad and I say “my cat woke me up at 5:00 in the morning”, I expect the other person to get the meaning of that, because the other person understands my local context.

When planning meetings you’d have to now the offset either way, because I’m not going to meet at idiotic times if there is an overlap in working hours between the two countries, which is something that you’d have to look up regardless of the time system. And if I send out a digital invite to someone abroad, the time zone information is already encoded inside it, and it shows up correctly in the other person’s agenda without the need to use a global time. In that sense UTC already is the global time and the local context is already an offset to that in the current system. We just don’t use UTC in our daily language.

But if it helps: I do agree that in an alternative universe the time system could’ve worked like that and it would have functioned. I just don’t see it as a better alternative. It’s the same complexity repackaged and with its own unique downsides.

But with such a system in place, what are we actually solving? If we’re agreeing on offsets (which would happen in a sane world), we’re just moving the information from one place to another. In both systems there is a concept of time zones, but it’s just the notation that’s different, which adds a whole new bunch of stuff to adapt to that’s goes very much against what is ingrained into society, without offering much in return. It’s basically saying “it’s 10:00 UTC, but I’m living in EST, so the local offset is -5 hours (most people are still asleep here)” [1]. Apart from the fact that you can already use that right now (add ISO 8601 notation to the mix while you’re at it), it doesn’t really change the complexity of having time zones, you just convey it differently.

Literally the only benefit that I can come up with is that you can leave out the offset indicator (time zone) and still guarantee to be there at the agreed time. Right now you’d have to deduct the time zone from the context, which is not always possible. That doesn’t outweigh the host of new issues that we’d have to adapt to or work around in my opinion.

[1] In practice we would probably call that 10:00 EST, which would be 10:00 UTC, but indicate the local offset.

Sure, but roughly speaking you know that 14:00 local time is probably okay for a business call, whereas 2:00 local time is probably not. You can get that information in a standardized way and the minor deviations due to local preferences and culture can be looked up or learned if needed. In contrast, with the other system there is no standard way of getting that information, except for using a search engine, Wikipedia, etc. The information not encoded anymore in the time zone, because there is no timezone.

Also, consider this: every software program would have to interpret per country what “tomorrow” means. I mean, when I’m postponing something with a button until tomorrow morning, I sure want to sleep in between. I don’t want tomorrow morning to be whenever it’s 8:00 hours in my country, which can be right after dinner. That means yet again that we need to have a separate source giving us the context of what the local time means, which is already encoded in the current system with time zones.

Not to mention the fact that it’s plain weird to go to a new calendar day in the middle of the day. “Let’s meet the 2nd of January!” That date could span an afternoon, the night and the morning after. That feels just plain weird and is not compatible with how we’re used to treat time. Which country will get the luxury of having midnight when it’s actually night?

Until you’re talking with someone from another country and you have no shared concept of time. Or you’re going abroad and you have to relearn what the numbers mean to fit the schedule. In the current system the numbers mean roughly the same in any country you visit.

Because time relates to the position sun and tells us something about what period of the day it is in that timezone. Your proposal would strip off that information, which means that you would have to look up in a different system what the business hours are in another country, when it’s night, etc. That means that you’re basically reinventing timezones by putting them in a separate system, which defeats the purposes and makes it more complicated than it already is.

Sure, time differences might be a bit cumbersome, but timezones have a name and can be converted from one to another. Also, most digital calendars (for meetings, etc) have timezone support and work perfectly fine when involving people from multiple timezones. To find a good moment to meet, you will still have to keep the time difference in mind, but in the current system you can at least take it into account just by looking at the time difference.

For authentication your password doesn’t need to be stored on the server. Instead, they store a password hash, which is essentially the answer that you get when you put your password in some sort of irreversible mathematical expression. By comparing the hash derived from your password when you enter it, with the hash from the database, they can confirm that you used the correct password. The decryption of your vault uses a different method and can’t be done with the password hash that they have stored in the database.

This is my best guess based on how hashing and encryption usually work, but I have no knowledge about the specific implementation of Bitwarden.