<klange>
It randomly selects from a handful of prompts.
<klange>
"You can help support ToaruOS by donating:", "Your donation helps us continue developing ToaruOS:", "You can sponsor ToaruOS development on Github:", and... "Please give me money:"
* gog
pleads for money
<gog>
give money. money now
<pony>
klange: that looks a lot like new zealand on your front page
<geist>
gosh this whole using ctrl-alt-2 to get to the console in qemu VNC changes everything
<geist>
i have no idea why i never thought to try it before, i always assumed the console was just lost in a VNC situation, unless i had redirected it to stduout
<geist>
i had lamented the fact that i couldn't do online snapshots with qemu when using it as a real VM host
kingoffrance has joined #osdev
gioyik_ has quit [Ping timeout: 244 seconds]
gioyik_ has joined #osdev
gog has quit [Quit: bye]
Amanieu has quit [Quit: No Ping reply in 180 seconds.]
Amanieu has joined #osdev
mrlemke has joined #osdev
<clever>
geist: thats a thing!? :O
<geist>
the ctrl-alt-2 or the snapshot thign?
<clever>
the ctrl+alt+2 in vnc
<geist>
yah, i had no idea till sortie mentioned it a while ago
<klange>
Note that if you have the monitor going somewhere else it won't show up there.
<geist>
and sure enough it just works. i have a scheme to start a bunch of qemu instaces under screen and set each of them to a different -vnc :N
<geist>
but since they're all started with & i dont have their serial or whatnot routed anywhere
mrlemke_ has quit [Ping timeout: 240 seconds]
<clever>
its also possible to route both serial and monitor to unix sockets
<clever>
so if your launching them from something like python, you can create a socket for each and still control them all
<geist>
yah but i like VNC because i can get to it from any machine on the network
<clever>
yeah
<geist>
but yeah that's also possible
<clever>
depends on if you want automatic or manual
<geist>
could route them to tcp probably
<klange>
I usually just do multiplexed serial and monitor on stdio...
<geist>
klange: that's usually what i do here, but i didn't want to have to create aseparate screen shells for each of the VMs
<geist>
so i have a script that basically does a for i in <list of vms>; $i/start; done and the start script runs them with &
<geist>
so can't route crap to stdout
<geist>
dunno if it's possible to script screen such that i tell it automatically to create 10 separate shells and run each thing in them separately
<geist>
but AFAIK you can't
<geist>
and i wanted it to be a one shot script
<kingoffrance>
? isnt that just part of the config file
<geist>
config file of what?
<kingoffrance>
screen
<geist>
i dunno! does screen have a config file?
<kingoffrance>
i used to have many sessions, that would "source" a common thing, then add more
* kingoffrance
facepalm
<kingoffrance>
gnu screen?
<geist>
hey dont facepalm me, why would i give a shit about a config file if i haven't needed it
<kingoffrance>
:)
<geist>
`screen -l -S some name` is generally what i use it for
<kingoffrance>
yeah i dont use it anymore i just vim tabs but i use to have many sessions
<geist>
create a session do some shit in it
<geist>
disconnect, reconnect, sometimes create a sub shell
<geist>
haven't needed a config file
<kingoffrance>
i tihnk most ppl moved to tmux now though
<geist>
possibly yeah
<geist>
i looked itno tmux and it seems alright too
<geist>
anyway, what you're saying is you can create a config file to among other things tell screen what to do when it starts up? like 'make 5 sub shells and run this script in it?'
<bslsk05>
www.freshports.org: FreshPorts -- sysutils/screenie: Small and lightweight screen(1) wrapper
<kingoffrance>
script would generate some "sessions" for me
<kingoffrance>
i.e. generate a config file
* geist
nods
<kingoffrance>
i never learned all the command line options i mean
<kingoffrance>
*i wrote a script that
<geist>
and obviously a bunch of this is what libvirt and whatnot is supposed to do
<geist>
i screwed with that a while but never really liked it that much. obviously powerful stuff i guess, but seems like a big wall of config files and whatnot just to do one thing
<kingoffrance>
of course screen has config file, how else you gonna make nethack messages default
<geist>
hmm?
<doug16k>
the `screen` command line interface is awful
iorem has joined #osdev
<doug16k>
how many ways to attach do you need?
<klange>
I basically only ever use `screen -dr` and tend to have only one session.
<doug16k>
where's -dRRics for when you are doing it left-hand-only and have ice cream sandwich
<clever>
when you ssh into my gentoo system like that, the .bash_profile? file is skipped, causing utf-8 to break
<clever>
but if you add -U, it forces it on
<clever>
and utf8 support is per-client, so you can `screen -x` in one tty and it works, but then `screen -x` with the wrong vars in another tty, and the same session is broken
<clever>
then -RR will auto-create a session if one isnt found
<doug16k>
what if it needs to detach it first?
<doug16k>
don't you need d and ten more flags?
<kingoffrance>
whatever i did would hang sometimes, is another reason i abandoned it. i think i bumped up some limits in source too lol. anyways, you can totally make a config file and make some of the "windows" call command instead of whatever shell, etc. then, you can destroy/create it will launch that, etc. can use for stuff like top and similar, some command to "monitor" stuff
<klange>
I have never needed -U and wasn't even aware it existed, I get UTF-8 support just fine?
<doug16k>
yeah I never used U on ubuntu, just works
<klange>
Maybe it's in my config...
<klange>
> defutf8 on
<klange>
ah yeah that'd be why
silverballz has joined #osdev
silverwhitefish has quit [Ping timeout: 272 seconds]
<clever>
doug16k: i prefer to never boot other clients, so `-xRRU` will create multiple concurrent attachments
<doug16k>
clever, I just run `screen -dRR` every time and go from there with ctrl-a commands
<clever>
i have several connections open, both locally and remotely
<clever>
and use that in place of a tiling window manager
<doug16k>
lots of web pages say instructions that supposedly create a new window in a session with a command, and detach immediately. never works for me
<doug16k>
you can make one session per command like that, detached, easy
<clever>
i prefer one session per system, so i can use ^a to move that command between windows easily
<clever>
this is also where screen and tmux vary majorly
<clever>
screen lets each "client" do a different thing within one session
<clever>
so i can easily view 2 commands in seperate terminals, and trivially swap them, or merge them into one terminal
<clever>
tmux forces every client to view the same sub-window
<doug16k>
this is one of those weird things that I feel like would be one of my main scenarios (adding a new window to a session with a command and detach), and it feels like an afterthought in the implementation
<doug16k>
the thing I expect to be the one job, often isn't
<clever>
for me, i just ^a:screen 9 top<enter>
<clever>
to run top in the 9th window\
<doug16k>
how did you mindread 9?
<clever>
i always run top in 9
<doug16k>
what if the window exists
<clever>
you can also omit the number, to auto-detect one
<doug16k>
ah!
CryptoDavid has quit [Quit: Connection closed for inactivity]
<doug16k>
screen is a command in screen command line?
<clever>
if the number is in use, it will silently pick an unused number
<bslsk05>
stackoverflow.com: linux - Attach to 'screen' session with creating a new screen window - Stack Overflow
<doug16k>
is that two nested screen processes?
<doug16k>
wtf is that 2nd screen in the command line?
<clever>
i think -S is for giving a session name, so you can manage multiple servers
<doug16k>
yes
<clever>
but one client cant deal with 2 servers, and i dont like having to deal with that, so i just enforce a rule of 1 server per machine
<geist>
boo. i got a 13w3 to vga adaptor but i guess none of my LCD monitors do sync-on-green
<clever>
and -X takes a screen command, the same one as ^a:
<geist>
i can't get any display at all on my old sparcstation
<geist>
*possible* it wont sync up if it doesn't see a keyboard
<doug16k>
clever, "screen" means make new window?
<geist>
but not sure i want to buy an entire type 5 just to find out
<clever>
doug16k: yep
<doug16k>
omg
<clever>
doug16k: also, all key bindings, are just mapping a key to a command
<doug16k>
geist, well there's your answer isn't it?
<clever>
so ^an is just bound to `screen` with no args
<geist>
well i read that if you type 'screen output' into OF (over serial) it should try to sync up the screen
<doug16k>
don't need config file, just run a screen command to launch things
<geist>
but i haven't seen anything
<geist>
i guess i should take a scope to it and settle it once and for wall
<clever>
$ cat ~/.screenrc
<clever>
bind - select -
<kingoffrance>
well i dont blame geist, all these little details is time away from being productive. cool to have a custom setup, but theres a tradeoff between getting stuff done and constantly tweaking things
<geist>
word.
<clever>
doug16k: this binds ^a- to `select -`, which will select a null window
<geist>
also i for better or worse switch between 3 or 4 different OSes constantly
<clever>
doug16k: i use that to make a client inactive
<kingoffrance>
vim recovers files if i crash, so thats where i place importance
<geist>
so i tend to favor things i can reproduce on each of them easily. stuff that involves setting global config files i avoid, all else held equal
<doug16k>
geist, did I understand that you wanted to spawn windows in screen for each vm?
<geist>
automatically, yes
<kingoffrance>
yep, used to be screen sort of worked on cygwin i think
<kingoffrance>
so i wouldnt have it on windows anyways
<doug16k>
yes, the stackoverflow I linked says how
<geist>
like 'create 10 windows, and run this script in each of them'
<geist>
ah. makes sense
<geist>
yah makes sense that you can do that
<clever>
oh yeah, you can also give screen a script file
<clever>
and that script can say things like `screen qemu-arm ...` on 20 lines
<clever>
and it will then spawn 20 VM's, one per window
<geist>
yep. only fragile thing there is you'd have to make sure you name the initial screen something consistent
<geist>
or... inside screen there's a way to read what the session name is
<clever>
[clever@amd-nixos:~]$ echo $STY
<clever>
9015.pts-1.amd-nixos
<geist>
or even 'run this as a new window within my own session'
<clever>
this env var is set in every child of the screen session
<geist>
that may be a variant of the switches
<clever>
and screen will know when you recursively run it inside itself
<geist>
that almsot certainlyu exists i bet
<clever>
[clever@amd-nixos:~]$ screen -x
<clever>
Attaching from inside of screen?
<clever>
it just refuses to attach to itself
<nsmb>
@geist I've found better luck importing weird Japanese LCD screens than looking for one in the states for my weird VGA format needs. That's what I use with my sparcstation.
<kingoffrance>
i used to have some kvm like adapter from mac -> pc and dont recall if it was a separate adapter or a toggle switch, to do sparc -> pc but i couldnt tell you the details, but it/they did keyboard + monitor at least i think it was called "guardian" something or other https://www.kvm-switches-online.com/apssun.htmlhttps://www.kvm-switches-online.com/apsmac.html i believe those were them, just nabbed off ebay, i didnt pay $150
<kingoffrance>
maybe hard to find now, or they will ask a lot
<geist>
nsmb: yeah i definitely used to have some VGA panels that would sync on green, but it's probably a crap shoot with modern LCDs if the controller does it or not
<geist>
at least that's what i remember the general issue was
gioyik_ is now known as gioyik
sts-q has quit [Ping timeout: 265 seconds]
aquijoule_ has joined #osdev
richbridger has quit [Ping timeout: 246 seconds]
smeso has quit [Quit: smeso]
nyah has quit [Ping timeout: 252 seconds]
smeso has joined #osdev
srjek|home has quit [Ping timeout: 252 seconds]
ElectronApps has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: Life beckons]
vdamewood has joined #osdev
<ZetItUp>
The expression word n or bit n shall be interpreted as indicating the content of word n or bit n.
<ZetItUp>
IDENTIFY DEVICE bit 10 word 83 indicates support for 48-bit addressing
<ZetItUp>
does that mean the 10th bit of the 83 word?
<kazinsal>
most likely
<ZetItUp>
or am i reading it wrong?
<Mutabah>
I'd assume so
<ZetItUp>
good, then im not overthinking it hehe
<kazinsal>
ATA, right?
<ZetItUp>
yeah
<kazinsal>
probably ought to write a disk driver at some point...
<kazinsal>
you'd think I'd have done that sooner but eh
<kazinsal>
probably should come*before* "high bit rate packet switching"
<ZetItUp>
im not really sure in what order i should do next stuff, i see some people have implemented graphics, some have done networking etc, before hdd support
<ZetItUp>
but i feel like i want to do hdd support (to some extent atleast)
<kazinsal>
I guess the real answer to that is a question: what's your next big goal
<ZetItUp>
my goal (in total) is to make it run doom haha
<kazinsal>
perfect, sounds like disk access is pretty important than
<kazinsal>
then*
<ZetItUp>
yeah
<moon-child>
nah you can just bundle everything in your binary
<moon-child>
vfs all the way
<ZetItUp>
true, but that feels like cheating :D
<moon-child>
:)
<klange>
I have completely perged the SDF renderer, it's all TrueType now. It's performing reasonably well though there's virtually no optimization so plenty of room for improvement.
<kazinsal>
:toot:
<ZetItUp>
thats cool
<klange>
The API isn't great, but this whole thing was a prereq to investing more time in a new rich text renderer.
<pyzozord>
Hey, I'm trying to figure out how to do a game with variable duration game tick. Meaning when there are animation it goes up to 30 ticks per second but when nothing moves it go as slow as 1 tick per minute
<pyzozord>
so far I figured out that I can do while(1) { sleep(tick(input_queue) } each tick will know when should the next tick happen so can sleep for that long
<pyzozord>
except that keyboard input should be interrupting. If we are in a long sleep and user presses a key, that key should be registered to input_queue and normal execution should be resumed
<pyzozord>
I though that maybe I can find a linux signal that happens on each key press, that would work perfectly because signals stop the sleep(), but I can't seem to find one
<Mutabah>
You'd want to use `select` or `epoll` or similar instead
<Mutabah>
these support a timeout, so you can wait on an event channel (keyboard/mouse/...) with a timeout
<pyzozord>
oh cool!
<pyzozord>
how is that usually working under the hood in laymen terms?
<pyzozord>
I'm mostly concerned abot CPU usage when waiting
<Mutabah>
It's a syscall - the kernel puts your thread to sleep until something happens
<pyzozord>
perfect!
<pyzozord>
Mutabah: normal poll won't do?
<pyzozord>
I'm not sure what's the difference between poll and epoll
<Mutabah>
it might do, iirc the difference is that `poll` only takes one FD?
<Mutabah>
nearly all of those functions will put the thread to sleep (very few things do a busy wait on a modern system)
<klange>
NieDzejkob: no, that's OpenType and relies on OpenType-specific features like ligature tables; this is just a barebones TrueType implementation thus far
<NieDzejkob>
ah, I see
pony has joined #osdev
<NieDzejkob>
uh, what's the story with syscall and sysenter and compatibility between Intel and AMD? am I reading this right that each is only available on processors of one of the vendors? I find that hard to believe...
<doug16k>
what? sysenter is a 32 bit thing. amd doesn't implement sysenter in long mode. not that big a deal
kanton has quit [Ping timeout: 252 seconds]
<doug16k>
amd won't let you be lazy and just throw your sysenter code at it
<doug16k>
must use syscall for long mode userspace
<moon-child>
or straight int
<doug16k>
NieDzejkob, amd invented long mode
<doug16k>
any deviation from how amd does it is someone making up new stuff
gog has joined #osdev
<moon-child>
doug16k: intel invented x86
<moon-child>
any deviation from how intel does it is someone making up new stuff
<doug16k>
it's a new mode
<doug16k>
it's supposed to be different
<doug16k>
if intel comes out with insecure mode, then amd would need to follow their spec
<doug16k>
intel has years of research into insecurity. it would be hard to keep up with it
<moon-child>
haha
<gog>
as an expert in insecurity, i can attest to this
<doug16k>
NieDzejkob, you don't want sysenter anyway
<doug16k>
syscall allows the syscall trampoline to be executed far out of order
<doug16k>
syscall doesn't even do a single memory access
<doug16k>
just teleports you to the syscall entry point in kernel mode
<doug16k>
puts return address in rcx
<doug16k>
who wouldn't want that
<doug16k>
and puts flags in r11 and masks flags
<doug16k>
you already need fast cpu-local storage, so you just fetch the new stack pointer overlapped with looking up the syscall handler function and the indirect call