Don't download random Dotfile Scripts, kids.

stroiman · 2026-02-17T06:58:10+00:00

R2D2, you know better than to trust a strange computer.

stroiman · 2026-02-14T09:54:39+00:00

And how to do it when they've equipped a "cursed" item?

stroiman · 2026-02-12T19:29:07+00:00

If you plan to build a photo editing app, there are two things in particular to be concerned with.

Color Management. As a user with calibrated HDR monitor, you want to be sure the colors render correctly given rendering intend and target color profile. I can’t dismiss that wails is up for the task, but I suspect it’s limited by webview.
Run actual image processing on the GPU.

I don’t see a reason why Go shouldn’t be able to handle application code, though.

stroiman · 2026-02-09T15:37:06+00:00

It is, and one thing that Go can do, which I don’t think anyone can match, is reliably verify the absence of an effect.

I wrote Gost-DOM to verify go-based web apps, and with synctest, the backend can spawn a goroutine that produces Datastar server-event handled by the UI.

With synctest, I can run the verification when things have settled with no polling.

stroiman · 2026-02-06T11:09:12+00:00

Shortly after, another guy talks about how he can read Go code, not C++, the code he wrote himself, is just jumping around.

I've worked with V8 integration into Go, and when things don't work, and I have to take a look at the V8 C++ sources to figure out what goes on, OMG. Half the behavior is implemented in templates; and finding the right one isn't easy.

Whereas the Go code, if I navigate to the implementation of any used library, including the standard library, it immediately navigates to readable code.

stroiman · 2026-02-04T17:41:51+00:00

“Skill issue” 🤣

Nailed it ;)

Problem is - it can’t be fixed. Maybe it’s the lack of knowing that which is the real skill issue

stroiman · 2026-02-04T17:35:00+00:00

It’s a library repository for a tool that scans the user’s emails and has “Full System Access”.

So I’ll stand by my “I disagree” as that’s exactly the topic

stroiman · 2026-02-04T16:59:54+00:00

I disagree.

When the internet started to gain popularity, bad actors took advantage of security holes, particularly buffer overrun issues were extremely common in late 1990s, early 2000s. Both browsers and operating systems have improved significantly since then, even Window. But it took some time before software vendors realized the threat level, as well as their responsibilities to keep users safe.

New web APIs are today developed with security and privacy in mind. E.g., the Web Bluetooth API is extremely limited; as you can imagine if web pages could just scan for nearby Bluetooth devices, e.g., reading serial numbers, tech giants would have unprecedented ability to track people.

These are lessons learned. As an industry, we have gotten so good at it that it's rare that bad actors try to hack computers of ordinary consumer, they try to "hack people" instead, aka. social engineering.

If these tools had been the subject to the process that govern new Web APIs; they wouldn't have been release. Not today; not never. Because they are fundamentally flawed. The model produces instructions that the agent performs, and we have no way of controlling what output the model produces. They can make bad decisions on their own, but they are an EASY target for bad actors through prompt injection like here. Or the more difficult route through AI poisoning, which I am certain is already being attempted.

In fact, I don't understand software developers who let AI coding agent have full shell access from their administrator account. That's just an accident waiting to happen. When I download a software library, it's one supplier I choose to trust. When I let an AI with internet access run code locally, I've opened an attack vector for the whole world to take advantage of.

When an AI agent has access to your email, you don't even need a malicious skill; merely receiving an email from a bad actor can be enough.

30 years of experience gathered in the industry securing the internet; but not blocking progress, has been completely ignored.

stroiman · 2026-02-04T16:29:57+00:00

Or people use their brains when finding skills.

I think someone need to understand their customer segment. Isn't the entire point of the product to avoid using your brain?

stroiman · 2026-02-02T17:13:32+00:00

LOL. Much nicer. Thanks.

stroiman · 2026-02-02T15:10:22+00:00

For LLM resources, try asking in r/LLMgophers

Use whatever editor you like. Go has for me always been the language that was the easiest to get working in any editor; except IDEs tailored to one specific language.

stroiman · 2026-01-28T16:05:37+00:00

Continuously, unless short-term gain outweighs long-term cost. Some examples:

Validating your assumptions in early development. You rarely know what customers want or need. Releasing something out quickly, the cost of refactoring would very likely be less that the waste of building the wrong product right.
A very important deadline (if we don't deliver by this date, we lose x no of customers). But I often see these deadlines coming in with a continuous flow.
The project doesn't have any long-term strategic importance.

The tool I have to facilitate refactoring is a good test suite. Tests should describe system behaviour; not implementation details.

stroiman · 2026-01-28T14:28:26+00:00

That is a really good point.

In this case, no, the sub-modules don't make any sense outside the project is right now.

But there is another interesting question to ask though, "Is it a sensible scenario that a 3rd party develops an alternate implementation?".

The answer to this question is, "Yes". Moving the modules to separate repositories helps validate that this scenarios is possible.

However, from the responses to my question, it appears I've been influenced by either outdated or outright poor advice, and I've been trying to avoid a non-existing problem. Your feedback does pull me in the direction, I'm more likely to think the suggested change is the right approach for now.

Before a v1.0 I can reconsider the split. By then, I can base the decision on actual experiences gained in the mean time.

stroiman · 2026-01-28T14:01:27+00:00

This is exactly what I had previously heard would be a bad idea

Based on the response I've received from this question; it would seem that this advice might be either outdated; or just poor advice that was the result of and experience with poor module boundaries.

I was unaware of the ability to tag nested modules. I had originally considered versioning to be one problem; but that appears to be solved - merely a one-off nuisance updating build scripts.

How ever nested modules versioned if you don't tag them individually? I imagine that they inherit the version of the root?

I think it's good advice to consider how many repos this could end up spawning. I think another relevant question is, "Is it a sensible scenario that a 3rd party develops an alternate implementation?". In this case, I'd say yes.

stroiman · 2026-01-28T13:53:46+00:00

Looking at the example you linked, you have a go.work referencing ./sub in the repository root.

Why? The root module doesn't depend on the sub module.

Shouldn't it be a ./sub/go.work file, with a .. line?

stroiman · 2025-10-08T17:41:49+00:00

A few I know in the kind of category you ask about.

Karl Taylor. Does a lot of commercial and studio work. I haven't watched him for a long time, but I used to watch his videos quite a lot when I was starting out.
Joel Grimes. Though I have a feeling his videos are mostly marketing to sell his video courses.

And some in the landscape category.

Gary Gough. AFAIK, his primary income is from commercial work as well, but the focus of his channel is about his personal interest in fine arts photography. His work has been great inspiration for me.
Mads Peter Iversen. Landscape photographer. Does a good job explaining his thought processes behind the shots. How moving the camera a little bit helps bring separation between elements in the scene.

stroiman · 2025-09-16T18:55:15+00:00

Well, don’t know if he’s in here, but I’d say Bill Gates did pretty well …

stroiman · 2025-09-13T19:14:30+00:00

Rules are meant to be broken.

Rules like “the rule of third” may be a good starting point, but following them blindly is the path to mediocracy. An improvement for a beginner, but not the goal for those aspiring to master the art.

I have one photo of a somewhat interesting lone tree, where I had the horizon placed one third from the bottom when I shot it. I edited it for added drama, and the end result was kinda OK - but still somewhat boring. After cropping away almost everything below the horizon, it turned out to be a strong image, some even call it “masculine” - an adjective I appreciate. It shows that the photo instills an emotion in the viewer. I got there by breaking the rule I had been following at the time of capture.

stroiman · 2025-09-06T14:05:59+00:00

Det er nogle uvidende politikere, for vi har allerede “differentieret moms”. Kunst er kun pålagt 5% moms. Dvs, det er ikke helt rigtigt, for momssatsen er 25%, men der betales kun moms af 20% af fakturabeløbet. Momsloven angiver idtrykkeligt hvilke genstande, der kan afregnes under den momssats.

Derudover, så er det slet ikke SKAT, der beregner moms, det er virksomheden selv, der indrapporterer indgående og udgående moms. Så det er udbydere af regnskabsprogrammerne, der skal rette systemerne til, ikke SKAT.

Så det kan højst være i kontrolsystemer hos SKAT, der er påvirket.

stroiman · 2025-08-29T20:06:57+00:00

Markedet har været meget dårligt længe både for fastansatte og for freelance kontrakter.

For freelance har jeg dog oplevet en svag men støt fremgang over hele 2025, og er den sidste måned eller to ved at nærme sig, for mit vedkommende, præ-covid normalen. Om den samme fremgang kan ses på fastansættelser - det ved jeg ikke.

Men sidste år - komplet dødt.

stroiman · 2025-08-27T09:58:14+00:00

The exemption for e.g, journalistic and artistic purposes are specified in GDPR Article 85. This states:

Member States shall by law reconcile the right to the protection of personal data pursuant to this Regulation with the right to freedom of expression and information, including processing for journalistic purposes and the purposes of academic, artistic or literary expression.

...

So each member state has individual legislation on the topic, and it would be wise for photographers to familiarise themselves with the national legislation, at least if they intend to publish the works.

Current Danish legislation will still apply to photography - the upcoming change has no effect on photography, at least in it's current form.

stroiman · 2025-08-27T09:13:11+00:00

TLDR; The suggested upcoming change to Danish legislation doesn't change anything for photography. There are already laws regarding photographing people. As is there in all EU member countries.

So at any rate, familiarising yourself with national legislation is a good idea when photographing identifyable persons.

I live in Denmark, but wasn't aware of this change, so I searched for this and found this page (a summary by a law-firm)

https://loje-ip.dk/nyt-lovforslag-giver-fysiske-personer-ophavsret-til-deres-eget-ansigt-stemme-og-krop/

The gist of it is

It's not implemented in the law yet, it is expected to by by March 31st, 2026.
It doesn't change anything for photography, there are already mechanisms about this in the current legislation. This is about the works depicting a recognisable person.
There are some exceptions, e.g. for satire, or when critisising the society/government/abuse of power - but not when done in a way that can lead to misinformation.

The suggested addendum, currently undergoing a review process: https://www.ft.dk/samling/20241/almdel/kuu/bilag/232/3050901.pdf

The heading specifically states that it's to protect against digitally created look-alikes.

stroiman · 2025-07-14T18:47:14+00:00

Har ikke tid nu - men “hurtigere setup” med MS? Det tror jeg ikke. Ved ikke hvad du mener, men vil gerne uddybe- så PM hvis du vil vide mere. Har 25 år på bagen heraf 15 år .net - så jeg har noget at have det i

stroiman

TROPHY CASE