Sauron

yes

What do you expect me to give you? A full list of every service that comes preinstalled in Ubuntu and what they do? systemctl list-units --type=service just compare the two and look up what the extra services do. And it's certainly not the google account integration that is slowing down your boot, if it really is slow. I haven't used Ubuntu in a while but I don't remember it ever being particularly slow. i3 is a window manager, not a desktop environment. It doesn't ship with applets, icon sets, animations, themes, settings menus, a login screen, launchers or anything of the sort, plus some preinstalled utilities and variety programs. DEs come with all of those and some extras for user choice, because they have to account for most users. Try pulling down the entire plasma metapackage and see if your system doesn't become just as "heavy" as manjaro.

There's no such thing as a "higher level distro", what you're referring to are derivatives. The point of them varies but generally they spawn when a group of people like a given distribution, but want to change a few things. For example manjaro is for people who generally like using Arch, but prefer a less involved installation process and having some sensible defaults out of the box. Artix is mostly Arch but without systemd. And so on. Ubuntu has almost nothing to do with Debian anymore, it's not just Debian with a nice installer. Mint is an effort to have either of those distros with an out of the box light and convenient desktop... maybe it's not to your taste but saying it has no reason to exist seems a little much. Linus was trying to run non-native software through a compatibility layer, using a distribution that is not that widely used (mainly because it's designed by a manufacturers specifically for their hardware) and expecting it to magically work without a hitch. He said at the time that this just indicates Linux wasn't ready for mainstream gaming, and you know what? I agree - if you want to run windows games without issues then just use windows, duh. But I wouldn't blame that on Linux or pop_os... it's just an unrealistic expectation. Personally I wouldn't recommend pop_os over Ubuntu if you don't have a system76 system for a variety of reasons, but it doesn't mean pop_os has no reason to exist. On system76 hardware it's probably a very smooth experience. Perception isn't objective so it's never really right or wrong... but I will say you tend to have strong opinions about things you don't necessarily understand very well. You also have to add the extra repository, and either way if the driver isn't present in the installer you might be stuck with a black screen before you even get started. That's increasingly rare because the foss drivers have gotten better, but it does happen at times. Yeah, there's more to these distributions than just taking debian or arch and adding a graphical installer... lots of preinstalled services that are enabled by default, for example. If you use arch, try counting how many systemd services you have enabled since first installation just to get a usable desktop...

I'm against copyright as a concept so I don't really care in that sense. For much the same reason I don't think this is targeting the right thing; make the models be public, not the training data.

I doubt that's the issue, but it can't hurt to try. You can also check to see if there's a newer beta driver available from nvidia.

Impossible The only situation where I could see the GPU being the problem would be a driver bug or a defective vram block. Usually the latter wouldn't cause a full game crash though, just artifacting.

If anyone here is putting words in people's mouths it's you - I never said AI accelerators don't or can't exist, or that they aren't faster than non custom hardware. Your argument from the start, however, was that Apple "will just figure it out" because they have "a track record": so excuse me if I don't take your backtracking from this position particularly seriously. How about you show me any indication that a purpose built NN accelerator can run a network like the one in the article at a sufficient speed for interactive tasks while using an amount of energy that is reasonable for a phone? If you have expertise in the field maybe you could have lead with that, rather than handwaving away the concern with a "they'll figure it out because Apple"

I'm using the graph for comparisons with itself and other stats from the same source. I'm not interested in specific numbers because of course these stats depend on the type of workload. All I'm talking about is relative performance; whatever these tests were, the X had worse performance in them than the 6/s and vastly lower than, say, a 13 or 14. Anecdote, irrelevant. The point being argued is whether iphone battery life is consistent (it isn't) and consistently better than competitors (it also isn't). I don't care if you personally thought it was enough. ...no it's not...? 1800 minutes is 30 hours... It's the same source so... why would you assume that? Are you just so invested in iphones having a better battery life that you'll ignore data to the contrary? Yeah, it is just your personal anecdotal impression, so I'll just ignore it. Maybe you don't do that but a lot of people, myself included, keep their phones under charge while at their desk even when they're not low on battery - because why not? Not to mention, it's not like all android phones have equally amazing battery life, and I never argued as much. The android market is vast and diverse, offering models across all price ranges and of varying quality. All I'm saying is that compared to some of the most popular competitors, iphone battery life is not especially impressive and is really bad in some models. I'm saying your usage of the word "engineering" is interchangeable with magic, because you throw it out as a thought terminating clichè. You can't just say "engineering" will solve a problem without explaining how it might do that. If you say a bridge can't hold because the beams are too thin, I can't just say "engineering" will make it work and expect you to believe me. I'd at least have to show you how the beams might be made stronger, or how adding cables would make them sufficient, or something like that. The same goes here. I'm not even saying it's impossible to make hardware that can run this in a way that doesn't significantly impact battery life, but you haven't really made an argument for the opposite.

It may not even be currently possible to make it that efficient, engineering is not magic as you said. Maybe they can do it, maybe not - I only take issue with people just assuming they can as if by magic. I Here you go, I don't have a subscription so I'm not sure what's going on on your end. I referred to models as recent as the Xs and 12... Less than half the battery life as competitors and even other models from the same company is abysmal in my eyes. I'm sure it's fine for many use cases, but comparatively it's terrible and Apple seems to agree, as evidenced by the camel case. Again you're acting as though optimization is magic. If the phone is doing things then it will consume battery charge, this is just physics; you can make it a bit more efficient by not running pointless operations but it's not like android phones don't do that... aside from poorly made apps, which are not platform specific, there's only so much you can do in software if you want the device to carry out a given task. You can clearly see just across iphones how much of a difference simply having a larger battery makes. Unless you're about to argue that the software on the Xs was just particularly unoptimized, despite running many of the same iOS versions as other models that came out shortly before and after.

The hardware is kind of beside the point since we're comparing software processes on the same device. Obviously more efficient hardware will draw comparatively less battery power, but it will still be proportionally constrained by the capacity of the battery itself. The question here is whether running an LLM like this won't draw significantly more power (on the same device of course) compared to a more constrained, but arguably more than adequate, assistant chatbot. And my impression is that no amount of "engineering" will significantly change that ratio, because there just isn't much you can do in terms of software optimization to reduce that workload. Maybe with specialized hardware acceleration the difference won't be that large, but it remains to be seen and it's certainly not a given as you seem to imply. Here, have a graph of battery life by generation: https://www.statista.com/statistics/1308110/iphone-battery-life-comparison-by-model/ you'll notice that while overall the trend has been increasing (mainly due to the batteries just getting larger, once apple got over the obsession with hyperthin phones and tiny screens) it varies year by year, with the 12 for example having a significantly shorter battery life than the 11, and notably abysmal performances from SE models and some top end ones even long after the example I gave - in fact, the 8, X and Xs had even worse battery lives than the 6 and 6s, which spawned the camel back battery cover.

doesn't work for interactive tasks afaik that's not really a thing you can do... if there's retraining involved it can be done asynchronously but the meat of the operation would still be the inference of a response, which you can't get from just cutting down the model (if we knew which specific parts of the network are needed to answer specific types of question this would be a whole lot easier...). To be fair I'm not specialized in neural networks so maybe it's possible and I just don't know about it.

iOS was not the problem, the insufficient battery size was. Apple hardware and software is not magic, if the battery is too small you'll get bad battery life and, if you overuse the hardware by running heavy LLMs, that battery life will be shortened further.

patents run out eventually

there was a patent a while back about a tv that would require you to say the company name out loud to skip advertisements. that never materialized.

Uhhh... not really. Battery life has been largely hit-or-miss on iDevices, as exemplified by this utter monstrosity: