Confiks

I bought Qty 10* of HC520 (12TB) SAS drives for $1000 about 3 weeks ago, avg age is about 2.5 years, still well within its rated lifetime.

That's cheap indeed. Enough headroom for some failing disks too. How is the noise and power usage? I didn't look at SAS drives at all, because my impression was that they're very noisy. I can place my NAS in a closed off room, but it's not too far away and I was afraid SAS drives would be audible through the wall. At the same time, the shucked drive I'm using presents itself as an WD Ultrastar, which comes very close to a SAS drive, and isn't very noisy.

Yes, indeed. ECC RAM is better than non-ECC RAM, also for ZFS.

The myth, popularized by a notorious thread on the TrueNAS forums [1], is specifically that ZFS requires ECC RAM, and will do worse than other filesystems without it, because scrubbing will multiply a single bitflip into a failed pool.

A ZFS core developer says that that isn't the case [2]. Here's some more reasoning [3], also about many other myths.

[1] https://www.truenas.com/community/threads/ecc-vs-non-ecc-ram...

[2] https://news.ycombinator.com/item?id=18480016

[3] https://kldload.com/zfs-wiki/myths

I’m running an 8-drive ZFS RAIDZ2 pool. I’m wondering if you know — are the free space recommendations around ZFS cargo or real?

I'm not entirely sure, but it seems to me that free space (and the 20% reservation) is mostly a proxy for fragmentation, and you can therefore better look at fragmentation directly. That would mean that if you mostly store large files, there shouldn't be a lot of fragmentation even at high utilization. The whole "ZFS changes allocation algorithm from 80% usage on" is something of 10+ years distant past, and lots of things around the allocator have been improved. It's also something that probably isn't too different from the performance of other filesystems at high utilization, so it shouldn't be exaggerated.

It was €329 per hard drive (through a reputable store), and I chose the ASRock B650M-HDV/M.2 mATX motherboard combined with a Ryzen 5 8500G. Stock CPU cooler, replaced the Jonsbo case fans with Arctic P12 Pro PST LN. I only slightly regret the PSU (MSI MAG A650GL), which could be quieter. Not that it's very noisy, and it's a great PSU otherwise, but I should've chosen one that just shuts the fan down at low power usage.

Not a great time price-wise to be building a NAS, but I have been doing so for the last two weeks. Inside a Jonsbo N6 case, which is pretty nice with an 8x SATA backplane and drive bays (unlike the earlier Jonsbo variants).

I ended up on shucking 4x the 14 TB WD Elements Desktop. They contain helium drives, the WD140EDGZ in my case, and are about a third cheaper than 4x the 12 TB WD Red Plus drives (which are air-filled). The shucking was easier than I expected too, and the performance seems very comparable. The warranty is a definite downside (European, so no Magnuson-Moss), but I think I can even get them back in their enclosure should they fail during the 2-year warranty period.

I've put some second hand 256 GB M.2 SSDs in there as boot drives. It was a bit of a struggle to get it to work in a way that failure of one of the drives doesn't hold up booting, combined with LUKS, TPM keys and ZFS on root. Learned a lot about systemd-boot which I have never used before, but feels a lot saner to me than grub ever was. So now I have a large script which debootstraps a Debian based NAS into being.

I noticed that there are a lot of ZFS myths and cargo culting. For example TFA mentions ECC RAM, which in some circles is a must-have because ZFS would wreck your pool during a scrub otherwise, which is a myth. It's also very expensive, especially this year. You also don't need much RAM for ZFS, L2ARC doesn't use much RAM at all, to name a few others.

Still doubting about setting `dnodesize=auto` (which is the default), because there are some horror stories about that [1]. And it seems impossible to find a cloud storage provider with reasonable prices that supports `zfs send`. Rsync.net upped their minimum order to 10 TiB recently, which is far too much for my use case.

[1] https://github.com/openzfs/zfs/issues/11353

[2] https://www.rsync.net/products/zfsintro.html

For writing and languange learning it's very decent, especially Mistral Large. The pricing is very good too. I really like the consistently low time to first token and good token per second. Claude, especially in the past, would be very inconsistent, often with outages. Mistral mostly just always works and is very fast.

Technical questions are unfortunately hit or miss. I'm lately pretty much always using a system prompt that emphasizes short answers [1], and Opus regularly one-shots it while Mistral needs a follow up. I use big-AGI as a model router [2] (dumb name, great software), which makes switching midway very easy though. For coding I'm still using Claude Code mostly out of inertia (although I really want to move to an OSS harness) and the one time I tried their `vibe` tool months ago it was a bit rough.

Mistral TTS with diarization is also great and cheap. That's the only thing for which I use their web UI.

[1] Give a short but helpful answer to the question the user asks. When helping with a computer-related task, unless the user asks, don't give any installation or setup instructions, but just get straight to the point. When the user asks a follow up question, give a more complete and longer answer while still not overexplaining. When the user prefaces the question with "short mode off" in any question, give a full and well considered reply.

[2] https://github.com/enricoros/big-AGI

The "Lists" page, lists most of such 'hidden' functionality: https://news.ycombinator.com/lists (which itself is linked in the footer).

Indeed, this seems to be exactly the area where the Data Act could be used to regain access. Unfortunately it seems that it's not possible to directly sue (e.g.) Volkswagen to get access, unlike the GDPR where you have direct standing under article 79 [1].

There doesn't seem to be much written about enforcing the Data Act, so I looked at the regulation directly. Article 39 [2] seems to require to first lodge a complaint with the competent authority as designated by the member state of your residence. Then when that authority invariably fails to act – I have no idea which timeframe we're talking about here – you can "in accordance with national law, either have the right to an effective judicial remedy or access to review by an impartial body with the appropriate expertise". But then you are suing that authority, and not the company directly (edit: I was originally unsure about who to sue under article 39, but 39(3) does clarify that it is the authority).

I would very much like to be wrong about this. I can imagine Muñoz vs. Superior Fruiticola applies [3] ("it must be possible to enforce that obligation by means of civil proceedings"), but I'm not at all sure, and it's a much weaker route than the one which the GDPR explicitly describes.

Would anyone know or have better references on how to enforce the Data Act, preferably individually?

[1] https://gdpr-info.eu/art-79-gdpr/

[2] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:...

[3] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...

I'm not quite sure why all that swapping is necessary. I really does age your SSD quite fast considering the enormous memory bandwidth required. Gemma 4 31B at 4-bit quantization should only be around 19 GiB [1], not 28.4 GiB. I'm not feeding it images regularly, so I'm not sure how much memory it needs to get those into context, but I can't imagine it is more than 10 GiB.

The activity monitor does show all kinds of Electron apps active, on top of a presumably model-loaded Handy and a virtual machine for Claude Code, so I guess that's the real root cause for all the swapping. If your laptop starts trashing I can't imagine you have any use for those apps, which will grind to a halt.

[1] https://huggingface.co/mlx-community/gemma-4-31b-it-4bit

So you made this change completely invisible to the user, without the user being able to choose between the two behaviors, and without even documenting it in the (extremely verbose) changelog [1]? I can't find it, the Docs Assistant can't find it (well, it "I found it!" three times being fed your reply with a non-matching item).

I frequently debug issues while keeping my carefully curated but long context active for days. Losing potentially very important context while in the middle of a debugging session resulting in less optimal answers, is costing me a lot more money than the cache misses would.

In my eyes, Claude Code is mainly a context management tool. I build a foundation of apparent understanding of the problem domain, and then try to work towards a solution in a dialogue. Now you tell me Anthrophic has been silently breaking down that foundation without telling me, wasting potentially hours of my time.

It's a clear reminder that these closed-source harnesses cannot be trusted (now or in the future), and I should find proper alternatives for Claude Code as soon as possible.

[1] https://code.claude.com/docs/en/changelog

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.

[1] https://github.com/throwaway96/dejavuln-autoroot

[2] https://cani.rootmy.tv

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.

Get into a venv, and run:

pip3 install git+https://github.com/ml-explore/mlx-lm.git

./venv/bin/mlx_lm.generate --model "$MODEL" --temp 1.0 --top-p 0.95 --top-k 64 --max-tokens 128000 --prompt "Hello world"

Where $MODEL is an unsloth model like:

- unsloth/gemma-4-E4B-it-UD-MLX-4bit

- unsloth/gemma-4-26b-a4b-it-UD-MLX-4bit

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

The same Gemma 4 MoE model (Q4)

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.

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.

[1] https://www.victronenergy.com/accessories/anti-islanding-box...

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.

[1] https://nextcloud.com/partners/

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.

[1] https://blog.tomaszdunia.pl/officeeu-eng/

[2] https://nextcloud.com/partners/

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.

See also this comment: https://news.ycombinator.com/item?id=45363853

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.

See also this thread: https://news.ycombinator.com/item?id=45363275

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.

[1] https://news.ycombinator.com/item?id=24764371

Solvinity (now acquired by Kyndryl) owns and runs a lot of the underlying infrastructure of DigiD, but the application itself and the day-to-day operations are handled by an autonomous body of the government (Logius). DigiD is mainly about translating authentication factors into a social security number (BSN) for authentication to other public institutions.

That allows Logius to pretend it's not much of a problem, and Solvinity maintains (in an unusually sharp and on-point interview) that all data is "encrypted" [1], without mentioning who possesses the keys or whether encryption is relevant at all. They go on to say that they consider the scenario of the US shutting down DigiD "very hypothetical", that they will follow Dutch law and that they have a strong supervisory board (as if that would matter).

Logius also operates MijnOverheid, which collates very sensitive information about all citizens from most government agencies and also relies on Solvinity infrastructure.

The infrastructure that Solvinity maintains goes far beyond servers, as they've concocted themselves an unholy procurement mess with their PICARD / LPC solution (Logius Private Cloud). They were advised multiple times over multiple years by the main advisory body on IT of The Netherlands (AcICT) not to do it in this way and KISS, but then did it anyway.

The intent of structuring it in this way was that it would be easier to switch infrastructure providers, but the outcome is the exact opposite: there is now a non-standard "integration layer" that would need to be rebuilt. Which is exactly what AcICT warned about from the beginning.

You can find a diagram of the responsibilities on both the Solvinity and Logius side on the last page of [2] (in Dutch).

The wild thing is that Logius also owns and maintains "Standaard Platform" [3], which is a very neat and standard Kubernetes environment, but they declined to use this for DigiD and MijnOverheid because they didn't deem it secure enough, and instead of securing their Kubernetes deployment, they went on with PICARD / LPC.

Logius is an autonomous body of the Ministry of the Interior (BZK), but they appear to have completely lost control over setting any policy and now mainly walk from crisis to crisis because any opening on their "SAFe train" is years away.

[1] https://www.nrc.nl/nieuws/2025/12/03/baas-van-solvinity-prob...

[2] https://www.adviescollegeicttoetsing.nl/site/binaries/site-c...

[3] https://www.logius.nl/onze-dienstverlening/infrastructuur/st...

So given that the current spec is not in use, this seems incorrect.

No, that's not what they mean. They just mean that the spec (and for now only the spec, not the implementation) will be amended with an experimental feature, while the implementation will not (yet).

I understand (?) that you are interpreting this as: "we'll later document something that we've already implemented", but this is not the case. That isn't how this project operates, and I'm intimately familiar with the codebase so I'm completely certain they haven't implemented this at all. There is no beginning or even a stub for this feature to land, which is problematic, as an unlinkable signature scheme isn't just a drop-in replacement, but requires careful design. Hence privacy by design.

If you have a key with the attribute of course you can 'bypass' it, I don't think that's bug.

Anyone of age can make an anonymous age attribute faucet [1] for anyone to use. That it's not technically a bug doesn't make it any less trivial to circumvent. I wouldn't expect the public or even the Commission to make such a distinction. They'll clamor that the solution is broken and that it must be fixed, and at that point I expect the obfuscation and weakening of privacy features to start.

So as we already know that the solution will be trivial to circumvent, it shouldn't be released without at least very clearly and publicly announcing it's limitations. Only if such expectations are correctly set, we have a chance not to end up in a cycle where the open source and privacy story will be abandoned in the name of security.

[1] Because of the linkable signature scheme in principle misuse can be detected by issuers, but this would be in direct contradiction with their privacy claims (namely that the issuer pinky promises not to record any issued credentials or signatures).

The insane question here is, why would the EU mandate hardware attestation controlled by two private American companies in order to access services?

Please (kindly) ask Paolo De Rosa [1], Policy Officer at the European Commission and driver of many of the decisions behind the wallet and the ARF. His position is one of fatalism: that it's "too late"; the duopoly of Goople is entrenched, and it's therefore not a problem if the wallet project entrenches it even further. Regrettably quite a lot of member states agree, although representatives of France and Germany specifically are frequently standing up to the fatalism.

[1] https://github.com/paolo-de-rosa

a lot of people are confused about the project

This is misleading. They are merely exploring options that may allow for issuer unlinkability, but they are actually implementing a linkable solution based on standard cryptography that allows issuers (member state governments) to collude with any verifier (a website requiring age verification) to de-anonymize users. The solution is linkable because both the issuer and the verifier see the same identifiers (the SD-JWT and its signature).

The project is supposed to prove that age verification is viable so that the Commission can use it as a success story, while it completely disregards privacy by design principles in its implementation. That the project intends to perhaps at some point implement privacy enhancing technologies doesn't make it any better. Nothing is more permanent than a temporary solution.

It will also be trivial to circumvent [1], potentially leading to a cycle of obfuscation and weakening of privacy features that are present in the current issuer linkable design.

[1] https://news.ycombinator.com/item?id=44458323

And out of nowhere, after posting this comment, Otter.ai now has responded after ghosting me for 3,5 weeks. They are no longer quoting the CCPA, but now are misinterpreting the GDPR and claim that every user is their own little GDPR data controller island and they're merely a "hosting platform". It's all very convenient and creative.

Their response:

    Thank you for reaching out to Otter.ai. Under Articles 12 and 17 of the GDPR, Otter.ai is able to delete personal data that is stored in and controlled by your own account. However, Otter.ai cannot delete personal data that is stored in another user’s account. In those cases, Otter.ai acts as the processor or hosting platform, and the other user is the controller for that content. As such, only that account holder has the authority to remove the content.

    If you wish to have such data deleted, we recommend that you contact the relevant user directly and exercise your rights under the GDPR with them.

    Thank you,
    Otter.ai Privacy Team

    To whom am I speaking? Is this the Privacy Officer? Why have you been ignoring emails for 3,5 weeks since the 23rd of July, while a GDPR request was filed on the 8th of July?

    You know very well that a meeting agent of Otter.ai, the emails by Otter.ai and the website of Otter.ai fall under the direct responsibility of Otter.ai as data controller. Your privacy statement in no way supports a narrative that Otter.ai would act as a so called "hosting platform". It's preposterous to suggest that every one of your users – not being a company but a private person – would be it's own little GDPR data controller island and you're merely an accidental processor of data. Jurisprudence is very clear on this and this notion will be outright rejected.

    The deadline has long passed, I'm initiating a court procedure this week.

    Hoogachtend,

Their own privacy policy acknowledges their obligations under the GDPR.

A month ago a potential customer automatically included their Otter.ai meeting agent into a Teams call. The customer never turned up (he canceled the meeting somewhat later), but me and a colleague chatted a bit in the meeting. Then the Otter.ai meeting agent posted a link in the chat, from which it was clear that everything had been recorded, up to a complete video of the meeting with full facial imagery.

As I'm a European citizen, I filed a GDPR removal request with them to remove all images of me from their servers. The email address that they list in their privacy policy [1] for GDPR requests immediately bounces and tells you to reply from an Otter.ai account (which I don't have). I was able to fill in a contact form on their website and I did receive replies via email after that.

After a few emails back and forth, their position is that

You will need to reach out to the conversation owner directly to request to have your information deleted/removed. Audio and screenshots created by the user are under the control of the user, not Otter.

We are required by law to deny any request to delete personal information that may be contained within a recording or screenshot created by another user under the CCPA, Cal. Civil Code § 1798.145(k), which states in relevant part

“The rights afforded to consumers and the obligations imposed on the business in this title shall not adversely affect the rights and freedoms of other natural persons. A verifiable consumer request…to delete a consumer’s personal information pursuant to Section 1798.105…shall not extend to personal information about the consumer that belongs to, or the business maintains on behalf of, another natural person…[A] business is under no legal obligation under this title or any other provision of law to take any action under this title in the event of a dispute between or among persons claiming rights to personal information in the business’ possession.”

Which is a ridiculous answer towards a European user, as the CCPA doesn't apply to me at all. Furthermore, I don't think the CCPA prohibits them at all in deleting my face from their servers, as the CCPA merely stipulates that I can't compel them under the CCPA. Otter.ai can perfectly decide this for themselves or be compelled under the GDPR to delete data, and their Terms and Conditions make it clear they may delete any user or data if they wish to do so.

After these emails, and me threatening to file a lawsuit, "Andrew" from "Otter.ai Support Team" promised to escalate the matter to his manager, but I got ghosted after that: they simply stopped replying.

So I'm going to file that lawsuit (a "verzoekschriftprocedure" under Dutch law) this week. It's going to be a very short complaint.

[1] https://otter.ai/privacy-policy

Perhaps "unfathomably" was too strong, but "any undergraduate" is at least very easy to falsify.