I recently bought a second hand eight year old 4K LG TV. Pretty cheap too. All models running webOS 3.x and 4.x are trivially rootable as LG never provided an update against DejaVul [1]. There's a handy website to check which models are rootable [2]. You can write directly to the (old!) Wayland socket; haven't tried a libwayland yet that is compatible.
IIRC the last public exploit for all LG TVs for webOS > 5 was in the beginning of 2025 (so pretty recent), but as most sellers on the second hand market have auto-updates turned on, there's no way to know which TVs are vulnerable.
It should be doable to strip down much of webOS with root access. It's nice that webOS in general is very well documented and much is implemented around the Luna service bus. LG offers a developer mode for non-rooted TVs, and there's an active homebrew community because of it. It's a pity that you can't modify the boot partitions, as the firmware verifies their integrity. It would be nice to have an exploit for that.
Not restricted to Apple, but TIL: Double-clicking on a word an keeping the second click pressed, then dragging, allows you to select per word instead of per character.
As you have so much RAM I would suggest running Q8_0 directly. It's not slower (perhaps except for the initial model load), and might even be faster, while being almost identical in quality to the original model.
And just to be sure: you're are running the MLX version, right? The mlx-community quantization seemed to be broken when I tried it last week (it spit out garbage), so I downloaded the unsloth version instead. That too was broken in mlx-lm (it crashed), but has since been fixed on the main branch of https://github.com/ml-explore/mlx-lm.
I unfortunately only have 16 GiB of RAM on a Macbook M1, but I just tried to run the Q8_0 GGUF version on a 2023 AMD Framework 13 with 64 GiB RAM just using the CPU, and that works surprisingly well with tokens/s much faster than I can read the output. The prompt cache is also very useful to quickly insert a large system prompt or file to datamine although there are probably better ways to do that instead of manually through a script.
> That too was broken in mlx-lm (it crashed), but has since been fixed on the main branch
Unfortunately I have got zero success running gemma with mlx-lm main branch. Can you point me out what is the right way? I have zero experience with mlx-lm.
It is, as I'm running it; it has been added this week. As I said I'm running the main version from Github and doing nothing special, see: https://news.ycombinator.com/item?id=47761308
Not necessarily, but most inverters (in Europe, at least) aren't designed to function without a grid anyway.
Some models of inverter brands like Victron (which isn't very common outside its niche of self-sufficiency because they are rather expensive and sometimes complex) can form a micro-grid. They have the option of a special circuit breaker [1] that decouples the inverter from the grid if the grid is detected to be down, which allows their use during a power outage.
You say "tax money", but this project isn't a government project or using public money at all. As for contributing back to Nextcloud: there is a long list of Nextcloud partners [1] that contractually obligated themselves to contribute back to Nextcloud for every user they onboard. The company in this article has not.
This is just a Nextcloud rebrand with a confusing domain name. It claims "Core is [100%] Open Source" but no source code is provided beyond what's already available in the upstream projects, and it's unlikely that there will be (as this happens a lot). It's a one-man project without a track record or certifications based out of a shared office space [1].
And don't get me wrong: there's nothing wrong with starting a business rebranding Nextcloud and keeping your development closed source, as long as you're honest about that, which this initiative is not.
If you're looking for a Nextcloud hoster, there's a long list of partners here [2] that have contractually obligated themselves to contribute back to Nextcloud for every user they onboard.
> there's nothing wrong with starting a business rebranding Nextcloud and keeping your development closed source, as long as you're honest about that, which this initiative is not.
I thought Nextcloud was released under the AGPL, making this very much not okay by default. So either I misunderstood something or Office.eu got a permission to make non-free modifications? (Going by what you said; I have not dived into this.)
If it just says that it is partly based on Nextcloud, that does not imply they modified Nextcloud code at all. Other parts of the platform could be based on some other code, even closed one.
> That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.
You are mistaken. In the EUDI wallet project, unlinkable signature schemes are currently being discussed among cryptographers and a month ago Longfellow very basic support for Longfellow has been merged into the reference wallet.
You're making it seem that unlinkable signatures are very established and the default, while they are not. They're not yet properly defined, experimental and mostly unimplemented by member states. Linkable ECDSA signature are currently the default in the EUDI wallet project.
> This whole end-to-end attestation with play integrity is supposed to make setting up token-as-a-service things impractical.
Indeed according to some (i.e. the Commission) it's supposed to, but they should know better. And many member state wallet developers do know better.
Play Integrity can easily be bypassed unless you want to exclude a very large amount of users – especially disadvantaged people using older phones – because there are many vulnerable phones in use by those users, and you only need one to build such an age attribute faucet.
> This is the fallback mechanism. You are supposed to use bbs+ signatures that are zero knowledge, are computed on the device and so on.
You're mistaken. SD-JWT with linkable ECDSA signature is the main mechanism. An unlinkable signature scheme is being discussed on the fringes of the EUDI-project (whether it be BBS+ or Longfellow) and very bare-bones support for Longfellow has been added to the reference wallet a month ago. However the Implementing Acts have no support for such a mechanism yet, and most member states will only implement ECDSA based mechanisms (SD-JWT and ISO 18013) for the foreseeable future.
It's therefore very likely the EUDI wallet and/or a age verification solutions will launch with issuer linkable ("easily trackable") signatures.
As the DPA indeed doesn't function for these kinds of cases, it's also possible to involve the courts and get a legal remedy (i.e. sue them). In The Netherlands that's possible with a 'complaint procedure' in the case of GDPR rights, which is more forgiving on the process (it starts with a not-too-formal letter to the court instead of a summons) and allows for representing yourself. Maximum costs would be somewhere around € 2500 if you lose, € 0 if you win (disregarding all the work and effort that cannot be recouped).
Of course this really isn't something you'd want to do for these kinds of simple cases. But threatening to do so often goes pretty far. The court in the country of the data subject has jurisdiction, so any company operating from another country would need to defend themselves abroad, which can be a strong incentive to cooperate or settle the case.
I've gotten results for GPDR article 20 requests (data portability) multiple times after some strongly worded letters (Spotify [1], NLZiet, AliveCor and Albert Heijn), and have gone to court twice. Once won against Eneco (although that was only about court fees they didn't want to pay without an NDA), and once didn't lose but regrettably didn't win on a quite complicated case against ABN AMRO in which the court just didn't understand what machine readable means despite the clear guidelines by the EDPD.
IIRC the last public exploit for all LG TVs for webOS > 5 was in the beginning of 2025 (so pretty recent), but as most sellers on the second hand market have auto-updates turned on, there's no way to know which TVs are vulnerable.
It should be doable to strip down much of webOS with root access. It's nice that webOS in general is very well documented and much is implemented around the Luna service bus. LG offers a developer mode for non-rooted TVs, and there's an active homebrew community because of it. It's a pity that you can't modify the boot partitions, as the firmware verifies their integrity. It would be nice to have an exploit for that.
[1] https://github.com/throwaway96/dejavuln-autoroot
[2] https://cani.rootmy.tv
reply