crosser

> LLMs are now fantastic at imitating mediocre art.

As well as writing mediocre code. (Merge requests look like they are produced by a bootcamp graduate.)

C standard _may_ eventually have a feature semantically equivalent, but very different syntactically:

https://thephd.dev/_vendor/future_cxx/technical%20specificat...

Discussion:

https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Improve...

I once worked for an organization known for providing good documentation.

This is how it worked:

They had a documentation-writing branch. And you (developer) knew that if you don't write documentation, they will. And then if will cost you _more_ time and frustration to review and correct what they wrote than to write it yourself and give to them.

So you did write it (and they proofread it, corrected grammar etc.).

It does not listen on IPv6 address!

Such a shame susam.net still has not adopted IPv6 in 2025 :-Q

Small company in Netherlands? My guess: management realized that they don't have money, and axed the position. They cannot say it openly, so had no choice but to ghost the interviewee. Which is of course still very frustrating!

This will make mozillateam's repo preferred over default "snapified":

   $ cat /etc/apt/preferences.d/firefox-ppa-pin-400 
   Package: \*
   Pin: release o=LP-PPA-mozillateam
   Pin-Priority: 900

Why not? You could use "certificate usage" value 1 and (if the implementation does not neglect it) immediately notice that validation by CA disagrees with validation by DNS. That should be good enough, no?

Could you please elaborate the reasons to implement this outside of DANE (RFC-7671) framework?

> DNSSEC operators can be strong-armed the same way. You will also lose out on transparency logs.

Kepping DNS registry, CA, and hosting in different jurisdictions could be a noticeable improvement...

Having mypy in the pre-commit hook helps a lot! (But I agree that difference between mypy versions is a pain.)

That was fascinating reading, thank you!

I take an issue though with this assertion:

> The order [...] is quite different to english but very similar to functional programming.

The most widely accepted (imo) order of function composition is right to left:

  send(makeUrl("http://..."))

just like in English "blue fish": transformation stands to the left to the object that is being transformed (*). Whereas "transformation follows the object" is an OO tradition, as shown in your examples. "Take object, apply transformation (method) yielding another object, apply transformation to that new object, etc."

(*) In quintessentially functional Haskell, you can compose functions both ways, but right-to-left is more traditional:

  {-
   - Find numeric value of the first figure of the decimal representation
   - of a number:
   - 1. convert it to a string of decimal characters (show)
   - 2. take the first character of the string (head)
   - 3. convert the character to a string containing one charcter (:[])
   - 4. convert the string of one decimal character into an integer (read :: Int)
   -}
  
  main = do
    let
      firstfigure1 :: Int
      firstfigure1 = read . (:[]) . head . show $ 413
    print firstfigure1
  
    {-
     - Reverse the order of composition. Define "right-pointing" versions for
     - (.) and ($)
     -}
  
    let
      (.>) = flip (.)  -- it will become infixl 9 by default
      ($>) = flip ($)
      infixr 0 $>      -- We need value lower than the above. Use the same as $
  
      firstfigure2 :: Int
      firstfigure2 = 413 $> show .> head .> (:[]) .> read :: Int
    print firstfigure2

Heh that may be true sometimes. Though in my perception, "writing secure code" is more about sanitizing input and preventing buffer overflows than about enforcing secure practices on the user...

Because of delayed gratification.

People are mostly motivated by gratification. You've written _functioning_ code - you can instantly see how it solves the problem at hand. You've written _beautiful_ code - you can stare in satisfaction at the negative total in `git diff --stat`.

You've written secure code - you reward comes in the form of nobody talking about your code for the next twenty years ;)

That article starts with too many inaccuracies to recommend it to anybody: - Teletypes were designed about a century before the era of mainframes. - Mechanical teletype did not have an "I/O driver" in it. - OS on Mainframe computers did not have a "Kernel", and neither "I/O driver", "Line discipline" or "TTY driver". This model was introduced with UNIX, the OS that ran on minicomputers. - Was ChatGPT used to write this article? ;)

I've recently stumbled upon an article on the same topic, but containing competent and accurate information, I have a link because I recommended it to a friend: https://thevaluable.dev/guide-terminal-shell-console/

> Coin generation and distribution, particularly when coins can be traded for fiat currency or goods, creates an incentive mechanism to keep the P2P system running.

Ability to trade for fiat currency proved to be a mixed blessing at best, and a downfall at worst, of this approach. When a system is so lucrative as a vehicle for ponzi schemes, it inevitably gets hijacked, and becomes unable to serve its declared purpose.

I would be very happy if such service worked (or if I could run it myself). It's my long term goal to break out of dependency on the Borg.

But the results are not even promising, let alone useful, which is very sad.

(I tried "haskell gloss terminate animation normally". That was my real search a couple of days ago.)

Would the following be functionally equivalent?:

- on each platform, include your pgp key id in the "bio"/"about" of your profile

- in your pgp key, include your profile URLs on each platform as an identity.

(In DNS, CERT RR exists for this purpose already.)

private.sh is not saying if the client's key pair is rotated, and if so, how often. If it is not rotated, search provider can correlate requests coming from the same user and learn a lot about them.

Non-linear optic explanation from quantum standpoint (classical explanation is quite clear).

> There just isn't enough radio spectrum available.

That is why my bet is on Musk. With lots of low orbit transmitters each covering a small area you have "space division" like in a cellular network. I.e. less endpoints competing for the bandwidth to the same transmitter.