I think that lawsuit was BS because it went on the assumption that the LLM was acting 100% autonomously with zero human input, which is not how the vast majority of them work. Same for compilers... a human has to give it instructions on what to generate, and I think that should be considered a derivative work that is copyrightable.

If that is the case - then it becomes likely that LLMs are violating the implicit copyright of their sources.

If the prompt makes the output a derivative, then the rest is also derivative.

I would say all art is derivative, basically a sum of our influences, whether human or machine. And it's complicated, but derivative works can be copyrighted, at least in part, without inherently violating any laws related to the original work, depending on how much has changed/how obvious it is, and depending on each individual judge's subjective opinion.

https://www.legalzoom.com/articles/what-are-derivative-works...

If all art is derivative, then the argument also applies to the LLM output.

If the input has copyright, so does the output.

If the input does not, then neither does the output.

A prompt is not enough to somehow claim artistry, because the weights have a greater influence. You cannot separate the sum of the parts.

Hey thanks. Actually I do something similar already using the "task-spooler" package on Debian.

$ tsp yt-dlp <some URL>

# returns immediately, runs tasks in its own shell in the background one at a time (or can be parallel if you tell it to)

# can check status/stdout any time with tsp -t (including older/other queued commands)

# just queue a new command to run after the last one at any time

$ tsp ffmpeg -i <file that will be downloaded by yt-dlp> <other params>

etc.

Love the mouse cursor, it made me feel happy.

> innocent until proven guilty

In the US at least, for criminal cases, the burden of proof for guilt is "beyond a reasonable doubt". For civil cases they are much more lenient and use the "reasonable person" standard.

I know this article is for Windows, but if you're wondering if there's a way to do this on Linux, there is:

https://strace.io/

https://github.com/nelhage/reptyr

https://github.com/crigler/dtach

https://github.com/jerome-pouiller/reredirect

https://github.com/pasky/retty

Here's my method using GDB from many years ago: https://gist.github.com/zaius/782263

Is there a way to read from present tty?

In practice: I boot into tty and manually start the graphical session (Wayland/Sway). I occasionally get (non-Sway) warnings when I return to tty (eg close the window manager). But the output is always scuffed, so I can't read the whole log. The lines get printed on top of each other or something.

Is there a way to read everything from tty, from within the tty?

Neither of the methods below work, because the warnings/errors aren't produced by Sway itself, but some other OS module/component.

$ sway |& tee /tmp/sway.log

$ tail -f /tmp/sway.log

If things are printed on top of each other, try script?

https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0&s...

But, if you're getting console debugs from the kernel, that wouldn't be captured either... Otoh, debug output from the kernel should also go into logs or dmesg or something?

You'll capture everything and maybe be able to figure it out from there?

Thanks for the input! Sounds promising. I've to admit, 'script' doesn't say anything to me yet. I've to look into it.

About the logs, yes, I have yet to dive into that. The _everything_ part makes it very tedious, so I had hoped for another solution :)

If script doesn't work, you could maybe try starting everything from within GNU screen or tmux with logging turned on?

oh, one more thing... your pipeline is only capturing stdout; errors often get logged to stderr ... script (or screen/tmux logging) will capture both though.

It might be useful to try and figure out what's logging the messages.

However, if it was me, I'd strongly consider just starting from your shell in the tty, then running tmux, then starting sway, then attaching to tmux from a terminal emulator.

Thanks for your reply! I've thought about that as well. Haven't tried it though. Two thoughts about it:

1. Running graphical from within tmux feels unsafe (?). Introducing another layer can't be the way to go. BUT this comes from a position of limited knowledge, so I might stand corrected on this one. Also, doing it once for debugging won't do any harm.

2. I'm pretty sure the errors are not printed by Sway itself, but some other OS module. Errors that Sway cause for other modules won't be included in the Sway log. So the problem remains, no?

vxworks 6.x:

(one login session, say over serial)

  -> ioTaskStdGet 0, 1
  value = 3 = 0x3
  -> taskIdSelf
  value = 13600784 = 0xcf8810

(another session, say over telnet)

  -> ioTaskStdSet 0xcf8810, 1, 0x9
  value = 0 = 0x0

(first session ie SERIAL)

  -> printf "foo\n"
  -> taskIdSelf
  -> i

(otherone eg TELNET)

  -> foo
  value = 4 = 0x4
  value = 13600784 = 0xcf8810


     NAME         ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
  ----------  ------------ -------- --- ---------- -------- -------- ------- -----
  ...

teeheeheehaw!

This prompted me to ask the crowd about a similar use-case of editing your command line as it's already running your command

https://news.ycombinator.com/item?id=46234678

I assume roughly the same caveats would apply, though? Buffering might be set wrong (and have no mechanism to be updated because the program never checks again), etc.

Thanks, links saved.

Then there is this method, but I guess that article refers to no redirection output.

If in background or via cron, I always redirect. But this is for UN*X type systems with a tail that supports '-f'

$ prog > /tmp/log.txt 2>&1 &

Then

$ tail -f /tmp/log.txt

Just so happens, I actually used this the other day for a long running process on OpenBSD :)

Can't you just read from /proc/pid/fd/0 ?

This was my first thought as well. I assume somehow I'm the dummy that doesn't understand the question.

Isn't that what tee is for? Like

$ prog | tee /tmp/log.txt

When I submit a process to bg, I mostly use cron and I do not care about seeing output during runtime.

So, tail suites my needs in the rare cases something unexpected seems to be happening.

That's if you start the process with advance knowledge that you'll want to tail the output and log it. Not if you want to view the output of an existing process

Yes, but I was replying to the above, using redirection and tail -f.

For those that prefer pure gameplay to skip through https://youtu.be/kkJWZlAjZp0

This is emulated as I'm sure the other videos are, but the PS1 back in the day had no way of running anything this crisp, so the emulator is `enhancing` it here. It's not an actual representation of what the game would have looked like.

It doesn't really work right on "normal" PS1s yet, at least when it was making the rounds a few weeks ago, so you need either an emulator or modded/dev PS1 with more RAM to prevent crashes and most people won't have the latter https://www.reddit.com/r/psx/comments/1p45hrm/comment/nqjtdp.... Probably shared a few months to early.

But yeah, on a "real" PS1 it would be blockier due to lower res. The main rendering problems should be the same though.

nah, it's not even configured to use the extra RAM, though there is a compile option for that. seems like the freeze was some sort of bug in the tessellation code, but I'm rewriting that part, so the bug is gone now. it should be working fine on hardware after I publish the changes.

Cool work man - can't wait to try it out when the fixes land!

CRT's smoothed out the image a little bit. Also, the screens were much smaller back in the day.

> Also, the screens were much smaller back in the day.

Not if you watch the video on your phone or iPad or laptop!

Actually, even most desktop pc monitors aren't bigger than people's TVs back then.

(Of course, TVs now are bigger than TVs back then. And desktop pc monitors are bigger than desktop pc monitors back then.)

The 14" Nokia TV from my old bedroom disagreed a little :)

In the end if you reescaled the emulator window down to 320x240 or 640x480 with a 25% scanline filter on LCD's or a 50% in CRT, the result would be pretty close to what teenagers saw in late 90's.

For a video, yes.

Though I suspect for interactive use, CRTs might have had better latency?

There was also just recently a Dreamcast port made, as well as Star Fox 64 for Dreamcast and also Mario Kart 64 for multiple platforms.

https://github.com/CharlotteCross1998/awesome-game-decompila...

They just finished a Star Fox 64 port as well

> LLMs all behave as if they are semi-competent

Only in the same way that all humans behave the same.

You can prompt an LLM to talk to you however you want it to, it doesn't have to be nice to you.

Compare this:

> calling his predecessor Antony Blinken's decision to adopt Calibri a "wasteful" diversity move

to

> SECRETARY BLINKEN: First, I’m called to make very weighty decisions (inaudible).

> QUESTION: Oh. Type joke.

> SECRETARY BLINKEN: And I’m always trying to be a font of wisdom, (inaudible).

Just... ugh. People voted for all of this non-stop vitriol? I'd like to have a post that added something meaningful but all I have to add is frustration with humanity.

"Do I look like I know what a jay-peg is?"