patrakov

This will also catch a SIM card in roaming, which is not a VPN.

We need strict liability on this front. Companies behind websites that embed ads that they didn't verify (and don't control) are complicit.

Try https://www.aorus.com/monitors/AORUS-FO48U/Key-Features - yes, it's a bit too small for you.

And that's a good wake-up call. The next thing "escaping" might be a sufficiently advanced model in a country already historically involved in manual cyberattacks.

RapidRaw is too much AI-focused, with the typical drawback that you cannot tell the AI that it is wrong. You want to remove something from the photo by inpainting something else over it, and the only way to do it in RapidRaw is to brush over what you want to remove and pray that the object is removed cleanly by AI. But often, the AI leaves even worse artifacts, and the low-tech solution, that is, manually selecting what you want to copy over, is not available.

Another issue is that the overblown highlight reconstruction is much worse than in DarkTable.

Even though I am not a Debian project member, let me express my dissatisfaction with Proposal A. The proposed addition to the Social Contract (i.e., the LLM contribution ban), by itself, is well-worded and acceptable, but the rationale quoted to justify it is not OK.

1. The copyright argument, even if true, is inconsistent with the permission to package third-party LLM-assisted software into Debian.

2. It is no longer the case that LLMs merely produce syntactically likely combinations of the training data. The best practice is to give LLMs access to a knowledge base (i.e., implement RAG) and instruct them to use that knowledge base.

3. The failure of the new packager to understand the best practices should be attributed to the lack of proper mentorship, not to their use of LLMs. A phrase "you can do better than this LLM" is expected to work better than a formal LLM ban.

4. I am not qualified to comment on LLM ethics and the load caused by collecting datasets for their training, so I will refrain from accepting or dismissing this piece of the rationale.

Try a gaming monitor, Gigabyte AORUS FV43U.

I was one of those initiators of a rewrite. And I was facing a real problem: the codebase was in C, all C developers except me left, I was going to leave too, and both our HR department and an external consulting firm failed to find a competent C developer to replace me.

So I said: screw performance, we are rewriting this thing into Go, as that's what our existing developers were willing to work with - with the intention of leaving when this would be done.

And the day I finally submitted my resignation letter, a competent C developer was found, and later I heard that the Go rewrite was scrapped.

I do have a DNS server in my LAN, with some records served to internal clients only. But the _acme-challenge record needs to be public for the DNS-01 validation to succeed.

The point was that you can obtain a certificate for a domain name without creating any records other than the _acme-challenge TXT record. I.e., that the domain might be completely empty all the time except for this record.

My preferred procedure is to use DNS-01 validation and have no publicly accessible "A" or "AAAA" record for internal services.

Or even a more extreme example: https://crt.sh/?id=27555237869 (sorry for any possible crt.sh downtime) - the domain name in question never existed in public or private DNS by itself. It is used only for a WPA3-Enterprise network, as the CN that WiFi clients expect to be present in the RADIUS server certificate, but never resolve. In the public DNS, only the "_acme-challenge" TXT record exists.

I am not a lawyer, but, as a Russian citizen, let me warn you. The very fact that your comment criticizing the EU regime, that you yourself admit could send you to jail, is online and not deleted by Thursday, makes it a "lasting crime". For lasting crimes, it does not matter that the regulation criminalizing the action or state of affairs was not in force when they started. What matters is that the condition defined as illegal (comment existing) is true when the regulation outlawing it is in force - i.e., that you did not cease and desist. Yes, this is a creative way authorities circumvent the ban on ex post facto laws - they say "it is not ex post facto".

Commented on Tuesday, deleted the comment on Wednesday, the regulation is enacted on Thursday => OK.

Commented on Tuesday, did not delete before Thursday => jail (and it does not matter that you can't delete it anymore because it has a reply).

Sarcasm of course, as Russian laws do not apply here.

And the worst part is, I have seen computer repair shops that refuse to work with a laptop if it has an encrypted system drive, under the guise of "how would we then validate the fix?"

It's Sectigo under the hood.

Yes. Darktable courses go as far as saying "ignore all modules and sliders not mentioned in this course" - which of course works until you get an assignment that is best solved with one of the non-reviewed modules or sliders, and in my case it was as simple as "a professionally looking high-key photo".

And here is another problem: very weak default look. This is a problem because the default unedited look is the basis of further editing decisions, and the photographer is lured into thinking that the photo is supposed to look desaturated and with open shadows. I repeatedly got the same critique, "why did you decide to kill the contrast and color saturation that was present in your RAW file?" I didn't kill them. I didn't even know they existed. And now I made a change to my workflow (a preset) to compensate, but this should not have been necessary.

I think you missed the point. Darktable, effectively, has a parametric curve (implemented by the tone mapper) at the end of its processing chain. And this "curve" will, by default, compress contrast at the bright end in a way undesirable for high-key photos (infinitely smooth rolloff instead of sharp clipping). Adding another curve below that will not help, as the contrast compression factor by the tone mapper is gradually approaching infinity. The fight with this default, which is inappropriate for high-key photos, was the topic of my previous comment.

Curves (in the form of Tone Equalizer and the old display-oriented Curve) do exist in Darktable, as well as parametric, drawn, external, and, since 5.6, AI masks.

I have a different problem with Lightroom being an industrial standard. If you avoid Lightroom, you cannot find a photography teacher.

You can find a Darktable teacher, and I did. He is a professional photographer, but I disagree with that particular teacher's style in photography - especially the rejection of strong edits even if they do work as creative reinterpretations of the scene.

You can find a photography teacher with good taste in composition, with recognition that both ultra-constrained and creative edits have their place (and I did find such a teacher), but that teacher will inevitably use Lightroom. That teacher recognizes what needs to be edited, recognizes that Darktable has the right to exist, but will explain the needed changes using Lightroom tool names.

It's now your job to translate - and, importantly, translate the visual effect achieved, not the slider name. This requires seeing the intended effect. This requires doing it in Lightroom first and then trying to make Darktable output look the same.

For example, the teacher asked for a high-key edit and told me to raise the whites. In Lightroom, this keeps contrast high near the top of the tonal range, right until it abruptly becomes zero because of clipping. That "high contrast followed by clipping" behavior is exactly what the requested high-key edit needed.

But your teacher will never describe it in those contrast-related terms. Before translating the instruction into Darktable, you first have to discover the visual pattern yourself that the Lightroom slider is producing.

And the correct translation, if you use the "sigmoid" tonemapper, is the "target white" control, which the official documentation marks as "don’t touch". You need to set it to 130% via right-clicking to override the soft limit of 100%. Very non-obvious, not mentioned in the Darktable course that I went through, but the photography teacher then accepted the edit.

In summary, the requirement to learn Lightroom in advance just to understand the photography teacher is the real trap here.

I suggest that you try https://artraweditor.github.io/ as an alternative.

Darktable 5.6 will have AI masks.

Anyway, I tried them, and found that, after you master the "a few rough brush strokes + adjust feathering and mask opacity until it snaps" and "overzealous brush + parametric mask" techniques taught in any Darktable course, for wildlife photo editing, AI doesn't bring much. And yes, this does require a course to break the "perfect mask is required" mindset.

Yes, Lightroom courses will brainwash you that AI "select subject, select sky, select object" workflow is the only modern way to do selective editing, but this is the Lightroom workflow. For Lightroom, it is a natural workflow, because it is, in Lightroom, the best strategy that can create a mask that aligns well with the object edges - until it doesn't. Other editors (such as ART and Darktable) have other idiomatic workflows for masking, and they work, because they have other tools than Lightroom for snapping the mask or refining it.

Bird feathers spread out on the tips of their wings are one particularly bad example where AI struggles, but non-AI tools don't.

Except if your country is under sanctions.

I confirm the same experience. I tried to port the Dynamic Range Optimization code in OpenCamera from Java to mathematical formulas (i.e., the spec), with the intention to translate that into Python with NumPy, so that I could run it on my own images not coming from my phone camera sensor. Tool used: just a chat with ChatGPT with the relevant files uploaded, research activated, and questions asked where I did not understand or doubted something in the response.

Result: ChatGPT faithfully and correctly reverse-engineered the initial highlight pre-compression step and then said that the rest (the real thing!) is too complex and not important anyway. I did not pursue it further.

Using multi-level grayscale instead of just two pixel states, on and off, can produce readable text at even smaller font sizes. The catch is that I have to say "text", not "letters", i.e., rely on humans inferring the too-blurry letters from their context. And I do not even need a specially designed font for that.

Example: https://imgur.com/a/text-80-characters-per-line-240-pixels-w...

That's 3 horizontal pixels per character on average, including inter-character spacing.

To give DarkTable credit, neural-network-based denoising will be in the next major release (5.6).

And even without neural networks, DarkTable denoising is better than open-source competitors, due to the database of camera sensor noise shipped with it. For each supported camera and ISO setting, it contains the measured values of Poissonian and Gaussian components of the sensor noise, so proper denoising becomes a one-click operation. That's as opposed to the much more complicated "drag the luminance and chrominance noise sliders until the noise disappears, then drag two more sliders to recover detail" workflow found, e.g., in ART.

The thing is, 127.0.0.53 is a fallback. The real default upstream is nss_resolve, which talks to systemd-resolved via non-DNS protocol on a UNIX-domain socket. Ubuntu disabled this in favor of the less-featured fallback. If you insist on sniffing DNS, you need to add instructions to disable the native nss_resolve module by not including it in /etc/nsswitch.conf.

General comments below.

The article says: "Already, it feels like there’s not much left for a human teacher to contribute, they believed". I also got a question over IM on whether it is possible to learn programming without a live teacher, using AI instead. I answered "no", and I stand by this "no". A live teacher chooses what to teach and in which order. A live teacher can insist on not skipping some boring but important topic and not advancing further until something is mastered, and AI currently can't do that.

On the other hand, avoiding AI completely is counterproductive. I do use AI, including for contributions to projects that allow this, but I do review everything that AI writes. So, in the AI era, the main skill required is code review, and there is indeed a change needed here, as existing programming courses focus mostly on writing code and then on understanding the underlying low-level mechanics.

> Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software.

No. As a user of your package, I want assurance that the package you publish does what it says it does and does not contain malware. This is different from the package having been published by you. I want protection against you going rogue, not only from you being impersonated. 2FA on your side does not protect me against you going rogue. A comaintainer does.

So the correct quote would be: Anyone that cannot find a comaintainer to review all the code and to prevent deliberate sabotage has absolutely no business writing widely depended upon FOSS software.

And even a mobile app (or, in fact, any single-person 2FA) would be unnecessary if we had a requirement for another live person to approve the release. As a bonus, a two-maintainers-required setup would also improve resilience against one of them going rogue or getting tortured.

The "nothing gets on main without two signatures" rule would not have prevented the xz story, where a comaintainer was able to smuggle malicious code past the review as "binary data for new tests" and, effectively, get it signed.

Exactly. "Doing it this way would prevent us from also doing X in the future; are we sure to permanently cross X from the roadmap, and are stakeholders aware?" is a valid and valuable objection. EDIT: and it can be trivially shot down by somebody with enough authority to define a roadmap saying, "we don't care about doing X".

The problem here is that a digest derived from the schema would just reintroduce the possibility of confusion of identically encoded but semantically distinct types.

And that's not useful at all. I asked for a long-zoom (250 mm) compact camera and only got 45 mm.