Wake me when they bother to define consciousness in a non trivial way.

>If a machine has to learn to understand humans to complete text, then that is what it has to do.

A language model completes text based on the overlapping patterns of the training data.

There absolutely was thinking involved… in the training data. Same as when you read a book, you engage with the thinking behind the text. The book isn’t thinking, and the author may be dead and gone, but there’s absolutely the traces of thinking in the text.

Language models produce mashups of texts they were trained on, and there’s absolutely the traces of thoughts behind those mashups.

Wow, such a great text only page with news reporting, I thought these were extinct!

AI investment and spending is frequently cited as one of the few bright spots in the economy, I wonder if the continued over-optimism is mostly about keeping the bubble inflated. If you are a tech CEO, would it be a disservice to your shareholders to express skepticism about AI?

I think this cuts to the point about democracy but if all the people somehow want something negative for themselves short term or long term, if you are the leader should you do what the public is saying or not?

I think there's more nuance to it but replace people with shareholder and leader with CEO.

I think that for a company to exist and thrive long term, it might need a culture which doesn't jump on every trend but it still evaluates them from time for time for a certain time and treat them as such (like tools) and if the tool is ineffective, then to not use the tool.

Unfortunately, I feel like this requires a deeper discourse and CTO's might be better suited for it or the fact that I feel like perhaps some shareholders might not be interested in the technical details so much.

I don't know but If I were a leader I would hopefully wish to make a pragmatic solution/suggestion while taking finances, current reality in mind and currently IMO AI aren't the end all, be all, that some people (with shrewd/double incentives) intend on suggesting.

A big reason there are so few bright spots is AI sucking all the air out of anything else. Both funding and attention-wise.

Not quite lines of code.

The person who takes a business problem and proposes an expansive solution that requires a big team that they lead to victory, that person climbs the ranks.

The person that takes the same business problem and carefully simplifies both the problem and the solution, and delivers it themselves, is rewarded but not at all like the team leader.

And there was a definite shift from sharing toward evangelism.

For example C was shared, C++ was evangelized. The difference is the effort put into convincing people to adopt your stuff.

Java for instance was mega evangelized, Sun thought it might reverse their fortunes.

Linux was initially “here you go, hope it works for you” but then it attracted many people who decided to create an ecosystem around it.

They have something in common, which is an endless need to chase hype cycles to lure investors.

Search on “diy radio telescope”, that gave me lots of projects and videos

Oh, you mean somewhere it is tracking the statistical likelihood of the output. Yeah I buy that, although I think it just tends towards the most likely output given the context that it is dragging along. I mean it wouldn’t deliberately choose something really statistically unlikely, that’s like a non sequitur.

Well, it's not tracking. As it predicts each token it is sampling from a probability distribution -- that's what the matrix multiplies are for. It gets a distribution over all tokens and then picks randomly according to that distribution. How flat or how spiky that distribution is tells you how confident it is in its answer.

But it then throws that distribution away / consumes it in the next token calculation. So it's not really tracking it per se.

From its point of view what does it mean "to know".

Is it the token (or set of tokens) that are strictly > 50% probable or is it just the highest probability in a set of probabilities?

While generating bullshit is not ideal for a lot of use cases you don't want your premier chat bot to say "I don't know" to the general public half the time. The investment in these things requires wide adoption so they are always going to favour the "guesses".

Going all the way back to the earliest C compilers on DOS. There was a decision made to make “\n” just work on DOS for portability of Unix programs, and to make the examples from the C programming book just work.

But in Unix “\n” is a single byte, and in DOS it is 2. So they introduced text and binary modes for files on DOS. Behind the scenes the library will handle the extra byte. This is not necessary in Unix.

I used to have to be careful about importing files to DOS. Did the file come from Unix?

Linefeed (\n) is a single byte in DOS as well.

I think you are talking about carriage return linefeed pair (CRLF or \r\n),

These control codes go back to line printers. Linefeed advances the paper one line and carriage return moves the print head to the left.

>Linefeed (\n) is a single byte in DOS as well.

In binary mode. In text mode if you printf(“Hello World\n”) you get CRLF because that’s how text works on DOS. Unix had the convention of only requiring the LF for text. And Unix didn’t have text/binary modes. That’s the compatibility hack on DOS.

>These control codes go back to line printers.

Back to teletypes even. Believe me, I go back to line printers.

I'm pretty sure that conversion was done by the C library, just as stated in the article. Not by DOS. ASCII 0x0A '\n' is always one byte*, and C library implementations for DOS would insert an ASCII 0x0D '\r' byte before it at output time if the C FILE stream had been opened in text mode.

Note that printf(), which you use in your example, is a C library function that writes writes to a predefined text mode stream. So it follows the same rules.

I wasn't able to dig up the source code of a vintage DOS compiler's C library in a few minutes of looking, so I can't prove it right now, but this section of the C standard (7.21.2 - Streams) hints that my recollection is correct:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf#p...

*(On systems where the char type is one byte, of course, which is the case for DOS C compilers.)

I wrote a C Standard library for MS/PC/DR-DOS. Your recollection is correct.

Thanks for confirming!

Agreed, I didn’t mean that DOS somehow converted it, this was a compatibility feature put into the C library.

Yes, and the order is important.

Sending a carriage return and linefeed to a TTY 33 and then printing works fine. Doing them in the opposite order, if the carriage is to the right of the page, will result in a linefeed (platen rotation) happening quickly, then the carriage starting to move left to the beginning of the next line, and then the next printed character will print wherever the carriage happens to be at the time - not yet to the left. So you will be missing a character at the beginning of the line because it's in between the two lines in an unexpected column-ish.

I have run into (in my mind, "hipster") code where the programmer for some reason reversed the order of CR and LF.

Teletypes is what I meant to say, thank you. Line printers have no carriage return mechanism.

Annoyingly I actually think '\r\n' is the correct line ending here - advance the paper and return the carriage, but I suppose unix took the simpler implementation which makes looping over characters, words (split by ' ') and lines (split by '\n') simpler as each loop only has a single comparison

The carriage return and linefeed combo are the commands to move to the next line of a teletype. Other commands might (in theory) be used for this purpose on other devices. These are implementation details.

Text inside a computer doesn't need any of that just to signal a newline. UNIX chose to use a single line feed character as a line separator because there was no good reason to use two. MacOS chose a single carriage return for similar reasons. Anything going out to a printer or teletype would run through a device driver that would turn the newline character into whatever the device expects.

Windows copied DOS which copied CP/M which was a very basic program loader for 8-bit machines and didn't really have "drivers" like we think of them today. I'm guessing here, but I imagine they chose the teletype combo because that's what most serial printers understood and printing was a major use case for those machines. That was probably the right choice for CP/M, but I can't imagine Microsoft would choose it if they were developing Windows from scratch today.

Yep, on Unixen the translation of CRLF to LF when printing to the terminal (and from CR to CRLF when reading input from the terminal) is done in the kernel, it's called "line discipline".

And if you switch the tty from "cooked" to "raw" mode then it doesn't do the conversion, and a CR just moves the cursor back to the start of the line and a LF just moves the cursor one line down.

Which is how you do the fun spinny icons on the command line without having to invoke ncurses!

You can also just use a \r directly without a \n. For example:

    spin='/-\|'
    while true; do 
      i=$(( (i+1) % 4 ))
      printf "\r${spin:$i:1} Working..."
      sleep 0.1
    done

By the way yes, that is a subtle reference to the TOS computer, so it's best read in that voice :-)

> So they introduced text and binary modes for files on DOS

It actually long predates DOS

C stdio is descended from Mike Lesk’s “portable IO package” (original release circa 1973). Bell Labs ported their C compiler from Unix to Honeywell GCOS and IBM S/370 mainframes. Mainframes handle text files very differently from how Unix systems do-it is much more complex than simply changing the newline character. So in Lesk’s package, the mode parameter to copen() told you whether the file was text or binary. copen() was renamed to fopen(), and the character to indicate binary mode was changed from “i” to “b”, and hence stdio

stdio has always had text-vs-binary file distinction, on some platforms (such as Unix) it has always been a no-op, on others it hasn’t

https://archive.org/details/lesk-iolib

Similarly on Classic Mac OS, C compilers would map single '\n' to single '\r' which is what was the Mac OS convention.