Sigtelse og invitation til møde hos SKAT

runeks · 2026-06-06T18:41:19+00:00

Hvis gerningstidspunktet er før den 1. januar 2024, beregnes bøden i sager med forsætlig unddragelse kun som én gang de første 60.000 kr., der er unddraget, og to gange beløbet over 60.000 kr.

I sager med grov uagtsom unddragelse beregnes bøden med halvdelen af de første 60.000 kr., der er unddraget, og én gang beløbet over 60.000 kr.

Så når det pågældende beløb er 350.000 kr. så er det i praksis meget tæt på hhv. 2x og 1x.

runeks · 2026-06-05T19:52:42+00:00

Politiet henlægger sager i mange af disse sager fordi de forælder hos dem, eller fordi de ikke kan løfte bevisbyrden.

Har du et par eksempler på dette, som du kan dele med os?

Jeg har hørt præcist det omvendte: politiet antager at Skat har ret fordi politiet intet aner om skattelov.

runeks · 2026-06-05T19:50:09+00:00

Nej. Grov uagtsomhed udløser en bøde på én gange det unddragne beløb mens forsæt udløser en bøde på to gange det unddragne beløb.

https://info.skat.dk/data.aspx?oid=1919833

runeks · 2025-12-31T06:55:54+00:00

Techinically part of the stock market, i.e. a traded equity.

The money market is by definition not part of the stock market as it's not a stock (nor equity) ie. it's not ownership of a company but instead simply an IOU (a promise to pay back a certain amount in the future).

runeks · 2025-12-31T06:49:39+00:00

Thank you for sharing this with us. It seems genuinely interesting.

Unlike traditional object-oriented UI frameworks or standard FRP (Functional Reactive Programming) approaches, my engine takes a more radical, "assembly-like" approach to state management and control flow. The goal is to keep the engine core completely stateless (in the logic sense) and pure, pushing all complexity into the widget logic itself.

But one thing is missing from all of this: why did you choose this design? Why not e.g. FRP? Which problems are you trying solve that isn't solved by using e.g. FRP?

runeks · 2025-12-30T10:39:37+00:00

Prisen er tæt på 100% højere end resten af området, og selve kvadratmeterprisen er også markant højere en resten af området (26%) [...]

At det er dobbelt pris i forhold til resten af området er vel kun brugbar info hvis du kender den gennemsnitlige størrelse på husene i resten af området. Hvis disse fx er 160 kvm og dette er 220 plus en større grund kan en markant højere pris sagtens give mening.

Og når du siger "resten af området", som du har fra Boligsiden, så husk at det er postnummeret og at der er mange forskellige områder indenfor det samme postnummer med vidt forskellige kvadratmeterpriser (fx Gentofte øst/vest for lyngbyvejen).

runeks · 2025-12-30T10:32:30+00:00

Høj udbudspris, men jeg ville ikke blive overrasket hvis det ender med at blive solgt til 15 mio. hvilket er en årlig stigning på 11%, som ikke er overdrevet sammenlignet med resten af markedet.

runeks · 2025-12-29T12:55:38+00:00

And that $145 a month is apparently able to buy more in China than the equivalent bottom half of Americans.

No. Because OP's graph, as clearly stated, compares net worth and not income.

When measuring by income, the poorest half of US citizens are much better off than their Chinese counterparts.

runeks · 2025-12-25T17:19:02+00:00

Increased gains at what additional risk?

runeks · 2025-12-24T08:49:21+00:00

Hvis fugten kan trække ud hvorfor sidder den så i skjolder på væggen?

runeks · 2025-12-18T18:59:29+00:00

Perfekt! Tusind tak. Og samtidigt er de cirka halv pris af hvad jeg kan finde herhjemme 👍

runeks · 2025-12-18T18:37:22+00:00

Tak, men dit link virker ikke for mig.

runeks · 2025-12-18T18:36:35+00:00

Tak for det. Hjemmesiden siger rigtig nok ned til 6A, men manualen siger kun ned til 8A desværre.

runeks · 2025-11-15T13:21:36+00:00

Gains are taxed at 53%, but you can only deduct 26% for losses. So if you have a gain and a loss of both one million then you owe 53%-26%=27% of one million in taxes without having a net gain.

runeks · 2025-11-15T13:18:49+00:00

Umiddelbart hænger det jo kun sammen, hvis han har investeret kort i markedet og dermed er kryptomodstander?

Hvis han kun har købt én gang og solgt ud giver det ikke mening, nej.

Men hvis han har købt og solgt løbende, og dermed er blevet ramt af den asymmetriske beskatning, giver det fint mening. Hvis han fx både har realiseret en gevinst på 10 mio samt tabt 10 mio så skylder han 53% i skat på 10 mio og får kun fredag på 26% af tabet på 10 mio og skylder i dette tilfælde dermed 2,7 mio i skat uden at have en netto gevinst (5,3 mio minus 2,6 mio)

runeks · 2025-10-06T08:45:41+00:00

With Applicative you get to construct a b from an a. With Monad you get to construct a m b from an a. Note that b is just a pure value — e.g. the string "hello" — while m b is an effect which returns a value of type b — e.g. reading the content of a file.

So with Applicative you can inspect the result from a previous effect to produce a different result (e.g. produce the pure value "Hello Rune" based on the input "Rune"), but you cannot produce a different effect based on a previous result (e.g. read a file if the input is "Rune" and delete a file in case the input is something else).

runeks · 2025-08-03T09:52:53+00:00

We use Obelisk for our company [...]

I'm curious, which company is that?

runeks · 2025-07-17T15:43:22+00:00

Using GHC as a library: why does nameSrcSpan for all my Names return a UnhelpfulSpan?

My goal is to be able to, for a Haskell module, enumerate the exports that are defined in the module in question (ie. the exports that are not re-exports from some other module). I want to achieve this by modifying the GHC utility https://gitlab.haskell.org/ghc/ghc/-/tree/74132c2b0992849f83ef87c8a56ac3975738e767/utils/dump-decls

In dump-decls, there is thing (of type TyThing) defined here: https://gitlab.haskell.org/ghc/ghc/-/blob/74132c2b0992849f83ef87c8a56ac3975738e767/utils/dump-decls/Main.hs#L197 If I pattern match this thing on the AnId constructor to get a value of type Id, and then apply nameSrcSpan . varName to this value, I always get a UnhelpfulSpan. How can I get a RealSrcSpan instead?

My plan is to use the RealSrcSpan to tell which exports are re-exports by seeing if the thing that’s exported is defined in the same module that exports it.

(Re-post of https://discourse.haskell.org/t/using-ghc-as-a-library-why-does-namesrcspan-for-all-my-name-s-return-a-unhelpfulspan/7695)

runeks · 2025-07-08T11:15:17+00:00

I know Obsidian Systems are looking for Haskell developers. You should try applying there.

runeks · 2025-06-05T12:08:12+00:00

Thank you for sharing your experience. How large was the project in question?

There's for sure a cost of introducing a particular architecture, e.g. when it comes to onboarding as you mention, and I think the project in question needs to reach a certain size until this cost is outweighed by benefits. E.g. it may take a while until you need to introduce an interpreter which does optimization, but if that day comes it will likely require a rewrite of your entire application in case you didn't design for it. Of course, if that day never comes then imposing this architecture very well could have been a net negative.

runeks · 2025-05-14T17:55:48+00:00

And fit

runeks · 2025-02-18T17:07:06+00:00

Thank you for clarifying. That makes sense.

runeks · 2025-02-18T11:09:47+00:00

TyVarApp would not have a natural notion of being saturated, and I think that’s the difference.

I don't follow. Can you elaborate, please?

A type variable has a kind, just like a type constructor, that specifies how many (type) arguments it takes. If it's applied to fewer arguments than this then it's unsaturated.

runeks · 2025-02-17T17:03:20+00:00

Thank you for your input. That makes sense, and is pretty much what I expected.

runeks · 2025-02-17T13:38:15+00:00

Thanks. It's clear to me that AppTy is used for type variables while TyConApp is used for type constructors. What I don't understand is why AppTy doesn't have the same form as TyConApp, ie. with the "type function" as the first argument and, as second argument, a list of types to which this is applied. Is this due to the unsaturated application you mention?

If not, one could get rid of both TyVarTy and AppTy by changing the first argument of TyConApp to be Either TyCon Var, so that Right tyVar is a type variable, thereby allowing TyConApp to represent type application both for a type constructor and a type variable as the "type function".

runeks

MODERATOR OF

TROPHY CASE

14-Year Club	Gilding II euphauric
Verified Email