Jump to content

Sauron

Member
  • Posts

    28,091
  • Joined

  • Last visited

Awards

Profile Information

  • Gender
    Male
  • Location
    Mordor
  • Interests
    Rings. And elaborate, painful ways to kill hobbits.
  • Biography
    Read The Silmarillion
  • Occupation
    Lord of Barad-dûr, Gorvernor of Mordor until Morgoth returns
  • Member title
    Lord Of The Rigs

System

  • CPU
    AMD Ryzen 3900X
  • Motherboard
    Asus STRIX B550-F wifi
  • RAM
    2x16GB G-Skill Trident Z 3600MHz CL16
  • GPU
    Asus Dual RX 6700XT (OC)
  • Case
    Corsair Obsidian 800D
  • Storage
    Sabrent Rocket Q 1TB + Samsung 850 EVO 500GB + WD black 1TB 7200rpm + random seagate 1TB 7200rpm
  • PSU
    EVGA Supernova G2 850 Watt
  • Display(s)
    LG 27UL650 + Philips 23IE + LaCie 324 (frankenstein surround)
  • Cooling
    Gelid Phantom Black
  • Keyboard
    CMstorm quickfire XT - MX brown switches
  • Mouse
    Logitech G400s
  • Sound
    Asus ROG Orion headset + cheap logitech stereo speakers (hey, they work fine!)
  • Operating System
    Arch Linux, MSX Pro

Recent Profile Visitors

38,751 profile views
  1. Yes! https://xdaforums.com/t/multirom-beryllium-miui-custom-roms-gsi-06-12-2020.3868734/
  2. The lens is "just" the glass part that focuses light onto the sensor. The sensor is what actually captures the image. Not all sensors are the same, especially between phones, and therefore they can't just be swapped around like lego bricks. Now, if the industry were more standardized and phones were designed to be more repairable, this may not be the case... but that's not the world we live in right now. @wanderingfool2 data scrapes from refurbs can be solved by 1) having the drive be encrypted, which I think is already the case on iphones, and 2) diligently writing it over with random data. The latter isn't something you can easily do if you're a third party, but it could be done by Apple if they really wanted to. Though as I mentioned, with the way iphones are made there are many reasons why trying to resell them all would probably be a fruitless endeavor.
  3. I don't think it's that easy, you'd have to design said phone (and its camera sensor) with those lenses in mind. Almost every iphone generation uses a different lens, too, which makes this even harder. And I doubt Apple is eager to share their designs and specs with a third party. Again, you'd have to rethink the whole production process with a greater focus on durability, repairability and reusability for these changes to work.
  4. Apple is far from being alone in doing this. To some extent, demanding all iphones turned in to Apple be refurbished and resold no matter how outdated they are is probably unreasonable - however proper and environmentally friendly (when possible) disposal should be legally mandated. There's also the fact that these devices (not just from Apple) are designed to be hard to repair and to be obsolete within a few years, which worsens the ewaste problem at the root. A lot of people should probably be more mindful of their devices and try to make them last, but there's only so much you can do when, by design, they aren't built to last.
  5. Likely because it expects your system to have old packages. This, by the way, is the reason Arch Linux officially discourages partial upgrades or downgrades. What are you even trying to do that requires an old unsupported kernel? Will 4.19 LTS do? https://aur.archlinux.org/packages/linux-lts419 https://aur.archlinux.org/packages/linux-lts419-headers If you MUST have 4.20 I would recommend taking the 4.19 PKGBUILD from the aur package and changing it to pull 4.20 instead, the required steps are likely the same. It's worth noting that your system may have packages installed that OP's does not. Also you may have different versions of various packages.
  6. 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.
  7. 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...
  8. 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.
  9. 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.
  10. 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.
  11. 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"
  12. 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.
  13. 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.
  14. 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.
×