wonderingwanderer

joined 4 months ago
[–] wonderingwanderer@sopuli.xyz 1 points 3 hours ago

That was Afghanistan, but that's exactly what happened. If I remember correctly trump committed to the pullout after the election. Literally causing incalculable suffering just to spite his opponent

[–] wonderingwanderer@sopuli.xyz 1 points 3 hours ago

Oh god, it still exists! Now we just need four head shave cut and the ultimate showdown of ultimate destiny to complete the chronicle!

[–] wonderingwanderer@sopuli.xyz 2 points 17 hours ago

No, he described socialists 🙄

(Jesus was a socialist)

[–] wonderingwanderer@sopuli.xyz 1 points 17 hours ago* (last edited 17 hours ago) (1 children)

That's true too, I guess. I suppose the only way to prevent that would be to disable USB boot, which would also make recovery impossible?

[–] wonderingwanderer@sopuli.xyz 2 points 17 hours ago (2 children)

Even in Genesis, God supposedly preferred the sheep herder over the agrarian

[–] wonderingwanderer@sopuli.xyz 0 points 17 hours ago

Netanyahu's whim isn't about fixing things, more like breaking everything in Gaza, Iran, and southern Lebanon.

If you really think Gaza can be rebuilt as fast as it's been destroyed, you're going to have some unpleasant surprises whenever the world can pull itself out of this death spiral and start caring about humanity again...

[–] wonderingwanderer@sopuli.xyz 0 points 17 hours ago

The current government in the US is anti-vax.

You really need to take off whatever goggles you're wearing that cause you to perceive everything as whatever highly specific wedge issue you want to feel outraged about.

[–] wonderingwanderer@sopuli.xyz 1 points 17 hours ago

Let's not forget that it was trump who pulled out of the Iran nuclear deal in the first place...

C'est ne pas un sock

[–] wonderingwanderer@sopuli.xyz 5 points 1 day ago (5 children)

I think Abraham was originally from Ur, which was near Sumer...

But then again, nothing was written down until the time of Moses, so it really depends on how much you want to trust oral tradition.

The early Hebrew script was directly related to the Phoenician alphabet and Egyptian hieroglyphs though, so it does seem they at least had more than cursory contact with those civilizations

[–] wonderingwanderer@sopuli.xyz -1 points 1 day ago (6 children)

Have you ever broken an arm? A window? A car? A heart?

Fixing things takes time.

That doesn't excuse not starting when given a chance. The focus should be on establishment Dems' failures to start fixing things, not on setting some unrealistic expectation that all it would take is a snap of the fingers and bippity boppity boo.

 

cross-posted from: https://sopuli.xyz/post/45002077

If this isn't the right community for this post, let me know and I'll move it somewhere else.

I'm working my way through nandgame, and I'm stuck on the "call" macro in the function calls section of the stack machine unit. These are the instructions:

I was stuck on it for a while, so I looked up the solution and am going off the one given here (it's the only one I could find).

So far, I haven't gotten it to work. At first, it was giving me syntax errors because the labels weren't defined, so I replaced A = [LABEL] with label [LABEL] followed by A = [CONST], according to the specified calling convention. It also gave me a similar syntax error for TEMP_ADDR, which is never specified in the instructions, so I assigned it 0x7f00. So here is what I end up with (all in Assembly):

(note: the stack pointer, SP, is defined by a shared constant SP = 0)

Test code:

init.stack
call functionName 0
stop

function FunctionName 0
push.value x42
return

Macro: call

# Assembler code
## Push the current ARGS and LOCALS on the stack
push.static ARGS
push.static LOCALS

## Push the return address.
push.value after

## Set ARGS to point to the start of the arguments
A = SP
D = *A
A = argumentCount
D = D - A
A = 3
D = D - A
label ARGS
A = 1
*A = D

## Jump to functionName.
goto functionName

## Set return address:
label after

## Restore ARGS and LOCALS from the stack
A = ARGS
D = *A
label TEMP_ADDR
A = 0x7f00
*A = D
pop.D
label LOCALS
A = 2
*A = D
pop.D
A = ARGS
*A = D

## Push RETVAL.
label RETVAL
A = 6
D = *A
push.D

Macro: function

# Assembler code
## Define a label functionName
label functionName

## Set LOCALS to the current SP
A = SP
D = *A
label LOCALS
A = 2
*A = D

## Advance SP by localsCount
A = localsCount
D = A
A = SP
D = D + *A
*A = D

Macro: return

# Assembler Code
## Pop the top value into RETVAL
pop.D
label RETVAL
A = 6
*A = D

## Set SP to LOCALS
label LOCALS
A = 2
D = *A
A = SP
*A = D

# Pop the return address and jump to it
pop.D
A = D
JMP

Note: functionName, argumentsCount, and localsCount are all listed as placeholders above the relevant macro, but it doesn't describe how to define these. I'm guessing that comes in a later unit. The code block for the call macro gives me a red bar for each line with a placeholder, but this doesn't happen for the function macro which also includes placeholders. In any case, this doesn't seem to get in the way of the program as it still runs smoothly.

So as it is, when I run it, everything seems to work as intended. This is the result when it reaches the stop macro (infinite loop):

Which looks like it's doing everything it's supposed to do. But when I click "Check solution", this is what it says:

("Expected SP (RAM address 0) to be hex 101. (Was 104)")

Which is strange, because in the computer section you can clearly see that the SP content is hex 0101. So I don't know what's going wrong.

I stepped through the program tick by tick, and the only place SP ever reaches 104 is after the function macro, when it runs push.value x42, after which it runs the return macro which begins with pop.D, reducing SP back to 103.

Could it be the evaluator is assessing the value of SP at the end of the code block, instead of where it runs the stop macro? So perhaps I could try replacing stop with a jump to the end, followed by stop... Now that I think of that, I think it might work. I'm still going to post this though, because I already went through all the trouble. And in case it doesn't work, if anyone else has any ideas please share them!

I can expand the rest of the macros if need be, but they already passed the evaluation so they're all working according to specs.

Thanks in advance!

Edit:

I thought for sure that would work. I changed the test code block to this:

init.stack
call functionName 0
A = end
JMP

function FunctionName 0
push.value x42
return
label end
stop

The program runs exactly as it's supposed to, except now the stop loop is at the end of the code. The computer output still looks the same, except now the program counter loops between 60 and 61 at the end (as expected). But the evaluator is still giving me the same error! I'm stumped...

Edit 2: added annotations to code blocks to make it easier to read

 

cross-posted from: https://sopuli.xyz/post/45002077

If this isn't the right community for this post, let me know and I'll move it somewhere else.

I'm working my way through nandgame, and I'm stuck on the "call" macro in the function calls section of the stack machine unit. These are the instructions:

I was stuck on it for a while, so I looked up the solution and am going off the one given here (it's the only one I could find).

So far, I haven't gotten it to work. At first, it was giving me syntax errors because the labels weren't defined, so I replaced A = [LABEL] with label [LABEL] followed by A = [CONST], according to the specified calling convention. It also gave me a similar syntax error for TEMP_ADDR, which is never specified in the instructions, so I assigned it 0x7f00. So here is what I end up with (all in Assembly):

(note: the stack pointer, SP, is defined by a shared constant SP = 0)

Test code:

init.stack
call functionName 0
stop

function FunctionName 0
push.value x42
return

Macro: call

# Assembler code
## Push the current ARGS and LOCALS on the stack
push.static ARGS
push.static LOCALS

## Push the return address.
push.value after

## Set ARGS to point to the start of the arguments
A = SP
D = *A
A = argumentCount
D = D - A
A = 3
D = D - A
label ARGS
A = 1
*A = D

## Jump to functionName.
goto functionName

## Set return address:
label after

## Restore ARGS and LOCALS from the stack
A = ARGS
D = *A
label TEMP_ADDR
A = 0x7f00
*A = D
pop.D
label LOCALS
A = 2
*A = D
pop.D
A = ARGS
*A = D

## Push RETVAL.
label RETVAL
A = 6
D = *A
push.D

Macro: function

# Assembler code
## Define a label functionName
label functionName

## Set LOCALS to the current SP
A = SP
D = *A
label LOCALS
A = 2
*A = D

## Advance SP by localsCount
A = localsCount
D = A
A = SP
D = D + *A
*A = D

Macro: return

# Assembler Code
## Pop the top value into RETVAL
pop.D
label RETVAL
A = 6
*A = D

## Set SP to LOCALS
label LOCALS
A = 2
D = *A
A = SP
*A = D

# Pop the return address and jump to it
pop.D
A = D
JMP

Note: functionName, argumentsCount, and localsCount are all listed as placeholders above the relevant macro, but it doesn't describe how to define these. I'm guessing that comes in a later unit. The code block for the call macro gives me a red bar for each line with a placeholder, but this doesn't happen for the function macro which also includes placeholders. In any case, this doesn't seem to get in the way of the program as it still runs smoothly.

So as it is, when I run it, everything seems to work as intended. This is the result when it reaches the stop macro (infinite loop):

Which looks like it's doing everything it's supposed to do. But when I click "Check solution", this is what it says:

("Expected SP (RAM address 0) to be hex 101. (Was 104)")

Which is strange, because in the computer section you can clearly see that the SP content is hex 0101. So I don't know what's going wrong.

I stepped through the program tick by tick, and the only place SP ever reaches 104 is after the function macro, when it runs push.value x42, after which it runs the return macro which begins with pop.D, reducing SP back to 103.

Could it be the evaluator is assessing the value of SP at the end of the code block, instead of where it runs the stop macro? So perhaps I could try replacing stop with a jump to the end, followed by stop... Now that I think of that, I think it might work. I'm still going to post this though, because I already went through all the trouble. And in case it doesn't work, if anyone else has any ideas please share them!

I can expand the rest of the macros if need be, but they already passed the evaluation so they're all working according to specs.

Thanks in advance!

Edit:

I thought for sure that would work. I changed the test code block to this:

init.stack
call functionName 0
A = end
JMP

function FunctionName 0
push.value x42
return
label end
stop

The program runs exactly as it's supposed to, except now the stop loop is at the end of the code. The computer output still looks the same, except now the program counter loops between 60 and 61 at the end (as expected). But the evaluator is still giving me the same error! I'm stumped...

Edit 2: added annotations to code blocks to make it easier to read

 

If this isn't the right community for this post, let me know and I'll move it somewhere else.

I'm working my way through nandgame, and I'm stuck on the "call" macro in the function calls section of the stack machine unit. These are the instructions:

I was stuck on it for a while, so I looked up the solution and am going off the one given here (it's the only one I could find).

So far, I haven't gotten it to work. At first, it was giving me syntax errors because the labels weren't defined, so I replaced A = [LABEL] with label [LABEL] followed by A = [CONST], according to the specified calling convention. It also gave me a similar syntax error for TEMP_ADDR, which is never specified in the instructions, so I assigned it 0x7f00. So here is what I end up with (all in Assembly):

(note: the stack pointer, SP, is defined by a shared constant SP = 0)

Test code:

init.stack
call functionName 0
stop

function FunctionName 0
push.value x42
return

Macro: call

# Assembler code
## Push the current ARGS and LOCALS on the stack
push.static ARGS
push.static LOCALS

## Push the return address.
push.value after

## Set ARGS to point to the start of the arguments
A = SP
D = *A
A = argumentCount
D = D - A
A = 3
D = D - A
label ARGS
A = 1
*A = D

## Jump to functionName.
goto functionName

## Set return address:
label after

## Restore ARGS and LOCALS from the stack
A = ARGS
D = *A
label TEMP_ADDR
A = 0x7f00
*A = D
pop.D
label LOCALS
A = 2
*A = D
pop.D
A = ARGS
*A = D

## Push RETVAL.
label RETVAL
A = 6
D = *A
push.D

Macro: function

# Assembler code
## Define a label functionName
label functionName

## Set LOCALS to the current SP
A = SP
D = *A
label LOCALS
A = 2
*A = D

## Advance SP by localsCount
A = localsCount
D = A
A = SP
D = D + *A
*A = D

Macro: return

# Assembler Code
## Pop the top value into RETVAL
pop.D
label RETVAL
A = 6
*A = D

## Set SP to LOCALS
label LOCALS
A = 2
D = *A
A = SP
*A = D

# Pop the return address and jump to it
pop.D
A = D
JMP

Note: functionName, argumentsCount, and localsCount are all listed as placeholders above the relevant macro, but it doesn't describe how to define these. I'm guessing that comes in a later unit. The code block for the call macro gives me a red bar for each line with a placeholder, but this doesn't happen for the function macro which also includes placeholders. In any case, this doesn't seem to get in the way of the program as it still runs smoothly.

So as it is, when I run it, everything seems to work as intended. This is the result when it reaches the stop macro (infinite loop):

Which looks like it's doing everything it's supposed to do. But when I click "Check solution", this is what it says:

("Expected SP (RAM address 0) to be hex 101. (Was 104)")

Which is strange, because in the computer section you can clearly see that the SP content is hex 0101. So I don't know what's going wrong.

I stepped through the program tick by tick, and the only place SP ever reaches 104 is after the function macro, when it runs push.value x42, after which it runs the return macro which begins with pop.D, reducing SP back to 103.

Could it be the evaluator is assessing the value of SP at the end of the code block, instead of where it runs the stop macro? So perhaps I could try replacing stop with a jump to the end, followed by stop... Now that I think of that, I think it might work. I'm still going to post this though, because I already went through all the trouble. And in case it doesn't work, if anyone else has any ideas please share them!

I can expand the rest of the macros if need be, but they already passed the evaluation so they're all working according to specs.

Thanks in advance!

Edit:

I thought for sure that would work. I changed the test code block to this:

init.stack
call functionName 0
A = end
JMP

function FunctionName 0
push.value x42
return
label end
stop

The program runs exactly as it's supposed to, except now the stop loop is at the end of the code. The computer output still looks the same, except now the program counter loops between 60 and 61 at the end (as expected). But the evaluator is still giving me the same error! I'm stumped...

Edit 2: added annotations to code blocks to make it easier to read

 

I wasn't gonna make a post today, because nothing broke and it wasn't that exciting. But what the hell.

Anyway, there's still a couple things wonky, probably from the mishaps yesterday and the day before. The main thing is just a "failed to delete autoinstaller.sh" error on the script that runs when I do a "switch user", so I wonder if I broke something non-essential when I killed the PIDs yesterday...

It was also prompting me for a password whenever I tried to make it go to sleep, which would wake it up and basically make it impossible to put in sleep mode. But it think I fixed that somehow. Or maybe it only works when I press the sleep button. I have to test if it still happens when I simply close the laptop, which is what I had been doing after a switch user. So yes, that means I would come back to it later and it wouldn't be asleep, and would prompt me for a password after signing back in and loading the desktop.

I didn't even get to doing the security stuff today. I started off this morning by making a list of all the configurations that I've tweaked manually. It's a small list, but it will probably grow, and that will help me if I ever break something but also it'll help me keep track of all my changes so that I can easily undo them later if I want to, or remember what to do if I ever need to manually rebuild my system.

Then I played around in System Monitor, got a page exactly how I liked it, saved it as an export file for backup, and set it as my default page to open to. I learned about some of the metrics I was unfamiliar with, like PSI for instance. Now I want to get a vertical second display and just have System Monitor up on it all the time 😩

After that I went through my notes from yesterday and typed up a document with all the steps I took for the configurations, in case I ever have to do them again. That took up most of the day, honestly. Some of the commands are starting to feel more familiar. Ones that come up a lot at least, like journalctl, systemctl, cat, ps aux, grep, and nano. Some still look like gibberish to me though.

I spent most of the evening trying to figure out those two problems I mentioned, and made another document for more troubleshooting commands.

And then I finally got around to changing my username, which I did through the GUI because sudo usermod didn't work. So it didn't update the /home directory, which saves me some work updating pathways but it's kind of annoying cause that means they'll just stay under the default username, even though the ownership updated to the new one.

That's mostly all I did. Just fun boring stuff that didn't break anything and didn't seem to justify making a third post. But I'm making one anyway.

Now, tomorrow for sure I'll get to the security stuff!

So far that list includes setting up secure boot, locking the bootloader if it's not already, password protecting UEFI, encrypting the swap space (if it's not already and if I can do so without wiping my drive), configuring my firewall, setting up dnscrypt-proxy, and TPM! And then after that there's some software stuff like AppArmor, ClamAV, LMP, a rootkit hunter, an NGFW, and a locally-hosted password manager.

I'm not sure if any of that's redundant but if so I'll find out while I'm reading about it. It seems like a lot, though. It would be overwhelming if I wasn't excited about it. Maybe I should adjust my expectations though, cause it might take me a week just to set it all up. I still need to set up borg too, for backing up /home/ so I can exclude it from rsync...

And then after that there's more to do, but I'll be able to start shifting away from initial setup to exploring different kinds of software and actually using my system.

 

Spoiler: I fixed it again.

So basically, when I woke up this morning my intention was to harden my system's security a bit. I was gonna spend some time reading about a few different things until I felt like I could understand them and the process of setting them up.

After my experience yesterday, I thought it would be a good idea to create a backup first before getting into any of that, so I spent the first part of my day reading about that.

I read around on some forums and determined I needed to do three things: use rsync to create a system snapshot of everything but /home/, use borg to backup everything in /home/, and do something involving "pacman -Q" to backup all the packages I have installed.

Sounds simple, right? Well...

I spent some more time reading about how to do each of these things, until I finally felt ready to give it a go. The first thing I did was create the pacman lists of all my installed packages (one list for explicit installs, and one that includes all dependencies). Easy enough. The reason I did this first was so it would be included in my rsync backup, which is what I decided to do next.

Before even worrying about backing up to my external drive, I wanted to test it out first locally, so I made a "backups" folder in /home/, and used that as the destination for rsync.

Since I didn't have Borg set up yet, and I wanted to harden my system's security before connecting to the internet to download outside packages, I decided not to exclude /home/ from this first rsync backup. Are you starting to see where this is going?

When I ran the command in Bash, of course I didn't know what to expect. At first I was a bit startled at all the outputs zooming by, but I decided this was probably normal, so I pulled up System Monitor and just watched for a while. I was somewhat surprised to see so many flatpaks, since I'm on Endeavour, but I guess that's normal too.

I didn't realize something was wrong until I noticed the pathways in the outputs kept cycling through the folder under "backups" that I titled specifically for the rsync. And every couple of minutes, the pathways got slightly longer, as if they expanded an extra layer. It dawned on me that I had created an endless loop when I put my destination folder in /home/, though I didn't make an exclusion for it.

So I panicked a bit, as one does, and since I didn't know that I could simply abort the process with ctl+c, I closed Bash. Not a great idea, but I didn't know what else to do.

Anyway, so I checked the backup that I had created and it was quite large. About 27 GiB. Not enormous, but definitely larger than it had to be. I tried deleting it but it wouldn't let me.

So I sought a solution and tried a fuser command, and got a big long list of leftover PIDs that I was apparently supposed to kill to conclude the processes that got cut off when I closed Bash in the middle of a script. That seemed a little overwhelming though and I didn't feel quite comfortable with it, so I decided to try rebooting instead...

...and the result was that it got stuck on some sort of dracut initqueue hook with no time limit while attempting to boot. So, once again despairing, I walked away for a while and tried searching for a fix on my phone. Fortunately by the time I came back it had miraculously booted up.

Assuming this had cleared the stuck processes preventing me from deleting the rogue backup file, I tried deleting it again and it still wouldn't let me. So I reran the fuser command and killed all the leftover PIDs and my screen immediately went black. I shut it down from the power button, and turned it back on, and thankfully it booted up fine (better than the previous time, at least).

So long story short, I ended up doing a sudo -rm -rf on the rogue backup and that worked like a charm. Then I reran rsync with an exclusion for the folder the destination was in, and it went much better. Still a big rush of outputs, which makes total sense, but it concluded on its own after a couple minutes and the total size was only about 18GiB (talk about bloat on a fresh install!!!). Not bad, though.

I poked around a little trying to optimize it with more exclusions, or alternatively with a white list inclusion command, but I used a du command to see what folders were taking up the most space and ultimately I really could've only saved a few GiB by excluding some var/cache/ folders, but it wouldn't really have been worth the added inconvenience if I ever have to do a complete system restore. A big chunk of it was the /home/ folder anyway, and that won't be included in future backups once I get borg set up.

So that's mostly it. It was already evening at this point, and I had mostly forgotten to eat during the thick of it, so I ate some dinner and then got out my external hard drive to try to make a real backup.

My first attempt failed, of course, because it wasn't formatted (as I soon learned). I noticed a lot of errors in the outputs so I did a ctl+c this time, which ended the process much more neatly than before.

So then I learned how to format a hard drive as a btrfs, and then I decided while I was at it that I might as well learn how to encrypt it, so I did that too. And then I had to format it again, so I did. And then I reran the rsync and it worked perfectly!

Then I unmounted the drive and closed the encrypted container before unplugging it, and that concludes my first real external backup on linux! I did not expect it to take all day, but next time will be much smoother.

Tomorrow I will finally get to harden my system security, and if that doesn't take all day then I'll install borg and back up my /home/ folder. After that, I'll be ready to install some more software and start playing around to see what my system can do!

 

Well I guess I didn't really break it. A KDE update broke it. After updating I rebooted, and then when I tried to log in, the screen went black and got stuck like that.

Anyway, I read on the forums that the fixed involved adding a parameter to some line in the kernel options, which I had no clue how to do. I also didn't know I could enter the terminal from a frozen screen. So I tried the grub menu. But I didn't know what I was doing and was scared to mess things up, and for some reason I thought the answer was in the UEFI screen.

Now I knew that I was treading in dangerous waters, so I was trying not to touch anything while poking around the menus trying to figure out where I needed to go. But apparently I touched something I wasn't supposed to, cause my computer tried booting from the spare SSD, which isn't mounted yet and don't know how to decrypt it. So I got stuck for a while, tried the grub rescue in the command line because it was the only option I seemed to have, didn't understand it, panicked for a while, and eventually found out I could press f2 on startup to go straight to the UEFI screen. So then I went back to the menu where I messed things up and made sure to click on the correct disk.

So I was quite relieved when I was able to decrypt it and it brought me back to the Endeavour grub menu (the purple screen), and then booted up as it was supposed to. I tried logging in again and it still froze, but at this point I had learned I could press some hotkeys to get to the terminal. So I went in there and followed some instructions I found, ultimately only really learning what the problem wasn't. It turns out the parameter I was supposed to add to fix the issue was already there!

So I found out how to revert kde desktop and workspace to a previous version from the cache, and I did that, but when I rebooted and tried logging in again it still froze.

Luckily I had previously made a guest account so I logged in there and it worked. So then I learned that that means the issue was in the user-level configurations.

So I followed some more instructions to back up my KDE configs, moved the existing ones to somewhere else, then killed and restarted plasmashell to create new default config files.

And then I tried logging in, and it worked! This was an hours-long process, so it definitely felt good to have a working system again.

Luckily most of my settings and my favorited items in the app launcher were still intact. I hadn't moved my global shortcuts config file either, so my keybindings were preserved. The only things missing were my pinned icons on the app manager toolbar at the bottom of the screen.

So I went into my backup file for the plasma appletsrc configs, and I found the line that listed the apps I had pinned, and I copied it and used nano to paste into the current version in same place it would have been.

So even though it was tragic and frustrating and a bit gut-wrenching at times, I learned a LOT today. I gained some familiarity with grub, UEFI, terminal, basic shell commands, restoring previous versions of software from the cache, logging and troubleshooting, backups, configurations, and the basic system architectures, and the anatomy of the KDE environment.

I'm still no power user, and I still have a lot to learn, but I came a long way in just one day. Now, I'm tired.

There's lots more to set up tomorrow, but at least walking into it I won't feel so lost!

 

So I was researching different distros, and I stumbled upon one called Poseidon (based on Ubuntu) which was intended primarily for scientific modeling. However, it hasn't been active since 2018; also, after Poseidon 4, they shifted to focus primarily on oceanography.

So my question is, firstly, is there an active distro that has a similar intended purpose, and comes with all the relevant software? Barring that, is it easy enough to replicate just by downloading the relevant packages?

If the answer to both is no, my question is, how could one best go about resurrecting it as a fork? Would it be better to start from either Poseidon 9 (the latest) or Poseidon 4 (before they shifted direction), and then try to update all the core components? Or to start with the latest Ubuntu (or better yet Debian), and then simply install all the software needed to make it functionally identical to Poseidon?

Bonus question: if you start with an OS, and gradually replace one component at a time until all components have been replaced, is it still the same OS? (Theseus was a son of Poseidon, but unfortunately the name is already taken)

view more: next ›