kazinator

These kinds of incidents always remind me of https://wiki.c2.com/?KornShellStory

And so it thinks it is fairly new, then, and doesn't require any tubes replaced. Should that change, it will let you know.

In my neck of the woods, Vancouver, Canada, nothing happened to radio. It was shit in the 1980s and it's the same today.

Wait! Except for one major improvement. There is a station CJNY ("The Journey") at 106.3 FM, which is run by Indigenous people:

https://www.cjnyfm.ca/about/

In practice, ld.so is a piece of glibc. If you want to build ld.so from scratch, you have to clone glibc or get a tarball of glibc, and configure and build glibc.

You could make the argument that the glibc developers should split ld.so into its own subprojects. What for? That would just bring the extra responsibility of making sure that variations in glibc version work with variations in ld.so version for whatever reason.

What would happen in practice is that they would keep their version numbers in lock step, and systems integrators would use the same version. While the upstream glibc has to go through a dance of pretending that someone cares about their independence.

ld.so is a component of glibc!

  $ /lib64/ld-linux-x86-64.so.2
  /lib64/ld-linux-x86-64.so.2: missing program name
  Try '/lib64/ld-linux-x86-64.so.2 --help' for more information.
  !1!
  $ /lib64/ld-linux-x86-64.so.2 --version
  ld.so (GNU libc) stable release version 2.34.
  ^^^^^^^^^^^^^^^^
  Copyright (C) 2021 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.

If I had to choose between 16 dockers, or 16 processes with different ld.so, guess what I'm choosing ...

Open technologies can be used permissionlessly

For years I've had dental work done without freezing, but I think I need laughing gas and novocaine for writing like this.

I don't understand some of the pedestrian passages between the levels. They are way too steep to be escalators or stairs, yet Shinjuku does not have elevators with slanted shafts, does it?!

I think this is more of a schematic in the sense that the vertical dimension is not to scale; the levels are farther apart than actually, which exaggerates the slopes. Also, some of the passages may be indicating elevators with opposite exits. I see one which has two rectangular prisms that are directly above each other, but connected by a slanted line which may be indicating that pedestrians enter/exit on one side of the elevator at the vestibule level, and the opposite level at the platform level.

It would be cool for there to be a slider which controls the vertical scaling. Similar to how that guy did the mechanical watch animation where you can control how exploded the view is, from fully integrated to widely spread.

It works like this in some languages; e.g. Japanese technical terminology is linked word formation originating from Chinese.

Atom: 原子: (genshi) "primitive progeny".

Element: 原素: (genso) "primitive element".

Hydrogen: 水素: (suiso) "water element".

Oxygen: 酸素: (sanso) "acid element".

Carbon: 炭素: (tanso) "charcoal element".

Chlorine: 塩素: (enso) "salt element".

Coal: 石炭: (sekitan) "stone charcoal".

Carbon dioxide: 二酸化炭素 (nisan-ka tanso): "two acid/'oxid' -ized carbon".

Line, ray: 線: line, ray.

Ultraviolet ray: 紫外線 (shigaisen): "purple outside-of ray".

Infrared ray: 赤外線 (sekigaisen): "red outside-of ray".

Deep infrared: 遠赤外線 (ensekigaisen): "far red outside-of ray".

Yamanote train line: 山手線 (yamanotesen). :)

Amplification: 増幅 (zōfuku) "increase width".

Instrument: 器 (ki).

Amplifier: 増幅機 (zōfuku ki) "increase width instrument".

Difference: 差 (sa)

Differential amplifier: 差動増幅器 (sadō zōfukuki) "difference movement increase width instrument"

If titanium is germanstuff, whose stuff is germanium? :)

I regularly see this in chats about a subject area where I'm not the expert. The AI writes something that seems implausible, so I raise a tentative objection. "Oh, you are right, sorry" and then reverses the position on the matter. At that point, I have no idea what is right.

If I had trust in the first place, that trust would be gone. Or maybe it wouldn't, because if I had trust in the fist place, I would be gullible enough to maintain it.

The worst are areas that are dominated by layman online discussions, like say audio electronics. The AI training is full of that nonsense, and so whether your AI chatbot is a crackpot or an engineer depends entirely on what sort of language or angle you use in discussing the subject matter. It's all just a churning toilet bowl of tokens; it has no idea that the audiophile crackpot tokens and electronics engineer tokens are related and one beats the other.

You know what I mean? On the one hand, it offers to help you design the parameters for a Sallen-Key filter, asking you questions like do you want Butterworth or Chebyshev? Next minute it says nonsense like that the capacitor in a low-pass filter "bleeds high frequencies to the ground", or that a bigger filter cap in the plate supply of a tube will tighten up the bottom end for a more aggressive metal sound.

It's basically like a bar hostess who has heard enough political and economic discussions that she can catch a sentence out of a conversation and throw in a clever sounding remark. It's like that, but done at such a scale that it fools some people you used to think had their shit together.

It's just a search engine that finds garden paths through a vast amount of text, biased by the text you put in as a key. Sometimes those garden paths align with reality. The better you are able to verify whether the results are good, and/or the lower the risk if they are not, the better you are able to make use of it.

In mathematics (including information science, CS) there are all sorts of problems that are essentially searches for a solution, and many have the property that the search is computationally difficult, but verifying the solution is relatively cheap. E.g. finding integers such that a^2 + b^2 = c^2 isn't easy, but given a claim that some proposed <a, b, c> satisfies this equation is easy to check. The LLM is like that: it solves a search problem that can be fairly hard. It does so unreliably, but if you can cheaply verify the solution, there is a win there.

The remaining problems of AI are actually people problems; people causing you problems, using AI as a tool or excuse. If you get a garbage security report against your FOSS project, which wastes your time, there is an idiot person behind it, using AI for leverage. Blaming the AI, or just the AI, is a bit misplaced.

I'm skeptical that they not missing at least a week's or so worth of land title registry transactions, if the only thing they have left is offline, because offline backups are not made after every single transaction.

If the hacker was targeting the erasure of a particular recent transaction, they may well have succeeded. And by deleting numerous others, they have plausible deniability in the subsequent dispute over the property. If you just wipe a record that is related to you, and the manipulation is discovered (which it will be, one way or another), you are part of a narrow circle of suspects.

There are no dynamically scoped function bindings in Common Lisp.

Pascal Costanza somehow implemented such a thing. See 2003 paper "Dynamically Scoped Functions as the Essence of AOP", a precursor to work on AspectL and ContextL.

https://dl.acm.org/doi/pdf/10.1145/944579.944587

Dynamically scoped functions are wrappers which indirect to lambdas bound to a special variable; i.e. this is boostrapped out of dynamic variable scope.

Without any consequences, it will just go on as before.

And he only seems to be calling for disclosure, which isn't worth a damn, and can be put into some nearly unreadable print.

Did you know CL allows keywords to be function names?

  [1]> (setf (symbol-function :add) (function +))
  #<SYSTEM-FUNCTION +>
  [2]> (setf (symbol-function :subtract) (function -))
  #<SYSTEM-FUNCTION ->
  [3]> (setf (symbol-function :multiply) (function *))
  #<SYSTEM-FUNCTION *>
  [4]> (setf (symbol-function :divide) (function /))
  #<SYSTEM-FUNCTION />
  [5]> (reduce (lambda (x y) (funcall (car y) x (cadr y))) '((:add 5) (:multiply 3) (:subtract 4)) :initial-value 0)
  11

No, if you build it, they won't come. Most such projects never see adoption by users.

Kind of. Many dynamic set data structures do not require the set elements to be in some layout inside an array; the storage is abstracted.

When we put the binary tree nodes into an array and move from the parent to children using indexing calculations, rather following pointers that could go anywhere, then it's an explicit part of the data structure.

The top of the rail is already white!!!

It's just polished, so that it is reflective.

If you sanded it with your 180 grit paper, you would get the scattering which appears white.

Union Pacific Is Tackling Rail Heat to Keep America’s Freight on Track

Someone talked to an LLM which convinced them they had a brilliant idea.

Just a guess ...

Lisp-1 has the wart that it models special operators as bindings in a variable name space. So a form like (print let) actually resolves let to a binding to a special operator, and then has to be somehow pronounced as nonsense. And you can block let from working by binding that as a variable name. Allowing variables to shadow the basic operators of the language is quirky.

Would you want to use a weird POSIX shell in which "for x in *.jpg; ..." stopped working because you assigned "for=42"?

Yet Lisp-1 has a notational advantage for programs that work with functional values; programs that indirect upon functions are more succinct, free of "shim" operators for lifting values out of the function binding space, or requesting application of a function value.

In the TXR Lisp dialect, I worked out a way to have the notational convenience, without bringing in the Lisp-1 issue.

1. The substrate, including macro-expansion logic, is thoroughly Lisp-2.

2. When a compound form is written in square brackets, it indicates that immediate elements (those constituents that are symbols) are to be looked up in a single namespace that is a merger of the function and variable namespaces according to precisely documented rules. This is not recursively applied to the form; its arguments that are compound forms are not treated this way unless they use square brackets.

3. Macros are not affected. In a form [a b c ...], the element a is neither recognized as a special operator or as an operator macro. If it is a symbol, it is either a variable, or a symbol macro.

4. [ ... ] is a surface syntax with a straightforward representation: the (dwim ...) operator. The above semantics is thoroughly baked into the macro expander and correctly treated at all necessary levels of the language: the handling of lexical scopes at expansion time and compilation/evaluation.

This system leaves mainly just one small infelicity. The merged 1+2 namespace is not available in certain contexts when it would be handy. Like say we are writing a function that takes a functional argument, that we would like to default:

   (defun my-sort (sequence : (test-fn equal)) ...)   ;; nope!

   (defun my-sort (sequence : [test-fn equal]) ...)   ;; nope!

   (defun my-sort (sequence : (test-fn (fun equal))) ...) 

1. Languages that have all the Lisp features are in the Lisp family. Thus languages that are not in the Lisp familly are ones that don't have all the Lisp features. Once a langauge disappears behind the event horizon of the Lisp family, outsiders no longer distinguish it from any other member of the Lisp family; it's just Lisp.

2. Having some features of Lisp is not the same thing as having those features in that form and integrated in that way.

It's not just the roster of features, but how they blend!

If two features have to speak with each other through some interpretation layer, that spoils everything.

the techniques in the Dragon Book for writing compilers are the real magic.

Can confirm; got a few hints from the 1988 edition when working on the TXR Lisp compiler.

Oh, and also when implementing regexes, not to forget!

However, the Lisp compiler has its own magics that are not exactly covered in the Dragon Book. Some really nice way of doing things.

If four out of seven digits were blurred out, then they would really see how sophisticated we are: we have the concept of privacy!

Donald Trump's ego would show up as just one pixel.

A really powerful magnetic field could help, also.

Without our field, we would be in trouble, too.

So basically this whole thing is a ploy to get rid of porn: basically, censorship that vaguely tries not to look like censorship.

1. Instigate a completely impractical, rights-violating scheme for age verification that nobody in their right mind wants to implement.

2. Then, enforce it against whatever porn sites land in your jurisdiction at all, knowing that they, like everyone else, don't do the verification.

Am I close?

Suppose the porn site tries to implement it. How many people are going to hand over their personal info to a shady porn site? Most visitors are there anonymously for whatever free stuff they can watch.

Either way, the porn site is ... screwed. Implement age verification: 99% visitors now back-button out and find another porn site. Don't implement it: blocked or shut down.

The main benefit of the Eytzinger layout is that all values needed for the first steps of the binary search are close together, so they can be cached efficiently: we put the root at index 1 and the two children of the node at index i are at 2i and 2i + 1.

This is exactly what is done in good old binary heaps; though binary heaps do not maintain a balanced binary tree, only the property that key(parent) < key(left_child) and key(parent) < key(right_child). Binary heaps don't support efficient search for a particular key.

I don't remember ever reading a description of binary heaps which mentioned Eytzinger. This is because the layout for binary heaps was discovered without knowledge of Eytzinger. It may have been Knuth who discovered Eytzinger and made the connection?

It's quite obvious that this layout is good for caching. The first few layers of the tree will all fit into a single VM page, the nodes closest to the root into one cache line. Then the subsequent layers are similarly packed in order.

Let's say that k layers of the tree fit into page. If the search path from root to leaf is 3k, it should touch only three pages, right?

But "undefined ops" are not part of the "8080 instruction set"; supporting those would be "binary compatible with the 8080 silicon".

The parity flag is a breaker though; "binary compatible for code only relying on the 8080 instruction set, other than values of the parity flag".

I just got six Schottkys this very morning, 1N5819 40V/1A, to replace the main board rectifier diodes in my Z80-powered ADA MP-1 pre-amp.

It would not make sense for even a 1200 baud dial-up BBS from 1985 to charge by the byte.

In 2026, the gigabyte should probably be the default/minimum unit for something like AWS.