• 0 Posts
  • 30 Comments
Joined 1 year ago
cake
Cake day: July 29th, 2023

help-circle










  • agent_flounder@lemmy.worldtoComic Strips@lemmy.worldXXX
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    2
    ·
    edit-2
    8 months ago

    Not op and I don’t think they forfeit that right at all.

    What I have wrestled with is: where is the line between taking precautions against known threats and victim blaming?

    Maybe the line is temporal.

    After someone is victimized, we can acknowledge that and maybe keep our mouths shut with victim blaming nonsense like, “you should have done XYZ”. Because that doesn’t help, further hurts the victim, and saying it makes you an asshole.

    Prior to being victimized isn’t it up to each of us to evaluate and manage personal risks given all the threats we face every day? I think so and I think each of us is responsible for learning about and managing risk and deciding what precautions to take.

    That isn’t to say we must take every precaution no matter how impractical or outrageous (like not walking on the sidewalk or never taking nude selfies).

    It is never acceptable to tell someone else what their risk tolerance is or to dictate to them what precautions to take.

    Doing that is being an asshole.

    And I now believe that is where the line is drawn.

    It is shitty to tell others how to live their life. It is good, however, to be willing to help people be aware of and understand the risks they face and offer advice if asked, on mitigating those risks. Provided your goal is to help and you don’t act like a sanctimonious ass.

    Whatever we do, we may still be victimized and the blame always rests squarely on the shoulders of the perpetrator. They took the action that victimized us.

    If you couldn’t tell I do cybersecurity as a living. My job isn’t to manage risk, it’s to help others achieve their objectives while understanding and managing risks they face.


  • Hopefully my sarcasm was obvious.

    I swear people are just gladly diving headfirst into total despair. Any hint of good news? Shit all over it with a one liner as the guy above, trying to point out the hypocrisy as if the vacationer should just not fly back from the trip lol. Like jfc, would it kill you take the small W??

    People who see the effects of climate change (on the reef or whatever) with their own eyes are going to be a lot more likely to take climate change seriously and maybe take some real action – there’s a massive list of things we could be trying rather than being a doomer on social media. It’s not that hard to find activist groups, write govt representatives, etc. And fuck this idea that millions of people doing something won’t make a change lol. More learned helplessness.

    Not that we aren’t fucked… but how fucked we will be depends on what we do. Dooming on social media is guaranteed to not get it done.

    All it does is drains you of any motivation (or will to live) you might have had to do something, even if small.

    I’m just fucking sick of the constant despair-aganda and kind of want to tell people spreading it to shove it up their asses.







  • I can totally relate. Been there many times. Kind of there now to a lesser degree (i.e. not having meltdowns but still so overwhelmed I am battling depression for the umpteenth billionth time and am really discouraged).

    Things that help me:


    Regular exercise even if light exercise, like walking around the block for 10-30 min. The more I do this per week the better off I am.


    Regular sleep; I’m way more mentally tough when rested. I’m a fragile mess if I am too tired plus stressed.


    Writing a list. The pile usually looks and feels infinite in my head but finite and thus smaller on paper.

    Still, list can be overwhelming. When things are really bad, make three lists:

    • “OMG MUST DO NOW OR I AM SO FUCKED”
    • “Need to get this done soon but not fucked yet”
    • “In the big scheme of things, not that urgent, not that necessary”

    And prune any unnecessary items.

    E.g. “I really want to finish that one project… But you know what? If I throw in the towel, officially quit, toss it in the bin and never think about it again it is a burden lifted so… fuck it, bye project!”

    I tend to overcommit, too, so sometimes it is better to call the friend and just be honest and say it probably won’t get done ever. I get really stressed and guilty when I have favors hanging over my head that I know I won’t have time for.

    I’ve got two of those hanging over my head now.

    If can help to have a friend help prioritize your list. They can help you be brutal in pruning, and objectively determine what is most urgent.

    Then… focus on one super urgent thing at a time.


    Helps me to think through the first most basic steps to get started on a scary thing that I want to put off. Instead of trying to climb a mountain, it helps to think of the first steps on the trail, the first obstacle. I mean basic as in, “ok first I need a pencil, then paper” – that level of basic. Once I get started i can keep rolling. It’s all about getting over the emotional hurdle associated with starting…


    Also helps to not expect too much of myself.

    One accomplishment is all I can muster, most days.

    Other days just doing basic hygiene and some days just getting out of bed is an accomplishment.

    Occasionally when stars align or I’m not stressed and overwhelmed I can knock out several things.

    Of course right now I feel like giving up… So that’s probably not expecting enough lol.

    Maybe it would help to have a mutual accountability buddy, where you encourage each other and report progress. That can be motivating in a good way.


  • Good question about filesystem. Let me think… yeah, probably think about it as a kind of database, but more like an API for a database that keeps track of file names, file sizes, where the files are stored on the storage device.

    It’s a collection of functions to do useful things like create, read, write, rename files, and list files available.

    It is an abstraction layer on top of the storage device functions.

    If we created tape storage, like on a Commodore 64, we wouldn’t have a filesystem. Our functions would just write or read a sequence of bytes from wherever the tape was, currently.

    With no filesystem, the user has to remember where on the tape the programs are stored (using the tape counter), what the program was (jupiter lander or tic tac toe or whatever), and keep track of what sections of the tape are free. Back in the day I kept this written down in a notebook. It was a pain.

    A filesystem would do this for us. But instead of a sequential storage device like tape, we need to create a random access, block storage device. We’ll make a floppy drive.

    We will divide the storage capacity (100KB, say) into blocks–sets of bytes–of 1KB each. So each disk will have 100 blocks.The drive will read or write to any specified block on command. We can say “read block 7; read block 73; write block 2”. Any order. Doesn’t matter.

    Let’s call our filesystem SimpleFS (SFS). SFS will keep track of the list of files, the names of each file, where those files are stored, how long the files are, what blocks are free on the disk, etc.

    Keeping this dead simple, SFS reserves Block 0 for the list of files (aka file catalog) and for maintaining a list of free blocks. We can use the first 100 bytes to represent the free/used status of the corresponding 100 blocks on disk where 0 represents free and non-zero means used. So if byte 5 is 1 then block 5 has been filled with data.

    The remaining bytes contain the file catalog. Each catalog entry contains a 10 character file name, the file size (16-bit) in 2 bytes, and the starting block # of the file. SFS will only store files in contiguous blocks.

    So now we can write our SFS functions.

    • FORMAT will initialize the storage by writing 110000…0 to the block map to show it is empty and formatted with only block 0 and occupied. And it writes 0’s to the catalog, block 1, to zero it out.
    • DELETE will clear out the catalog entry corresponding to the specified file name, by setting the starting block to zero.
    • LIST sequentially reads the list of files out of the catalog displaying name and size, skipping over directory entries with a 0 starting block.
    • RENAME would change the name of the specified file in the catalog to the new specified name.
    • LOAD would read the specified file from disk into the specified memory location. So LOAD(“myfile”,$1200) would go to disk, find the catalog entry for “myfile”, find out how many bytes to read in, the starting block #, and then read from those blocks into memory.
    • SAVE writes a sequence of N bytes from RAM to the disk, creating a file with the specified filename. So, you’d call SAVE(“myfile”, 73, $1200) to save 73 bytes starting at hex addr $1200 to a file called “myfile”. You can imagine that this function would have to find a free directory entry, find a series of 73 free blocks on disk, copy data to said blocks, then update the block map and the catalog entry.

    You can imagine some flaws with this simplistic design. For example, requiring all the file blocks to be contiguous is rather limiting. Imagine if you want to append to a file but there’s no space available after the last block?

    So you might want to eventually redesign SFS to be able to keep a list of non-contiguous blocks. There are various ways to do it. Since the directory is fixed, maybe you create a new data structure that contains a 0-terminated list of blocks. You refactor your functions to be able to use a non-contiguous set of blocks with this new data structure. And maybe you need a DEFRAGMENT function to reduce fragmentation that will result.

    Having only a flat directory kind of sucks too, so you could redesign it so that you could have subdirectories, each with their own file catalog. Then add functions to deal with path names, change directories, etc.

    Also, it kind of sucks having to know ahead of time how many bytes your program occupies. So instead, lets make it look more like unix. We use an OPEN and CLOSE function. Open can be used to write or read or append to a file. We don’t have to know the file size, just write bytes one at a time.

    We can then revise our editor to read our program a byte at a time from the filesystem and save it a byte at a time to the filesystem. And we can revise our assembler to read the assembly file, bytewise, and output the machine code directly to disk one byte at a time. The SFS can figure out how to update the size data in the catalog and manage which blocks get used.

    Another flaw is that if any of these save operations are interrupted before they’re done, we’re going to lose data and have a mess. So we probably need to figure out a way to reduce the potential damage and a way to repair the filesystem.

    Anyway, hopefully this gives you some ideas of how this stuff can be done.

    I’m vaguely familiar with how some of the classic filesystems work, like DOS FAT, Apple II’s DOS (I forget what it was called), C64’s disk OS (which if I’m not mistaken was actually programmed on the very intelligent but expensive 1541 disk drives), Minix/Linux-sorta-kinda as taught in some of my CompE classes.


  • I don’t know the details of the history of the first compiler or the first os or how various others were created. But here are some thoughts on how it could be done.

    Let’s start with a simple computer based on, say, a Motorola 6809 since I’m sorta kinda familiar with that since it is the CPU in my Hero Jr vintage robot. Let’s call our computer the Orange.

    First how does it run a program at all? Well, on reset, the first thing it does is loads a 16 bit address from the two highest bytes in memory ($FFFE - $FFFF) into the Program Counter. It will then execute the machine instruction at that new address.

    So if you could somehow load a program into memory, starting at some address ($D000, say), and also load the address value into $fffe-$ffff the computer will run your program on reset.

    One way to do that is to design your new computer with a PROM chip (a “read only memory” that is easy to write to, once) which occupies memory from address $d000-$ffff. That is, when the CPU reads from $fffe-ffff it is reading from the PROM rather than from RAM.

    To write your program, you would write it in assembly language and use an assembler to convert to machine code (just a sequence of data bytes). Except we don’t have an assembler yet. So let’s do it by hand on paper. CPU manufacturers provide info needed to do it by hand.

    By the way, we don’t have something to program the PROM yet. Let’s start with building a machine whose sole purpose is to burn an EEPROM. We need it to have switches on the front (like a PDP8e). You use the switches to enter data 8 bits at a time into any 16 bit address. Let’s say it has an 8 switch data input, and 16 switch address input. Also it has Store and Program switches. You can design the hardware with digital logic chips that will do as follows:

    • When Store is pressed copy the specified data into the specified RAM address
    • When Program is pressed, copy your program from RAM into the eeprom.
    • When Run is pressed, run the program starting at the specified address.

    I’m leaving out some implementation details for simplicity.

    Eventually we want to use our Orange to write, save, and load files, assemble programs, and run machine code generated by assembled programs.

    So we need devices for storage (floppy? Tape drive?) and serial UART. Skipping over hardware details, we need software to use the devices. We need to read commands from the terminal, display stuff to the terminal. The commands might include SAVE, LOAD, STORE and RUN. Each command is implemented in software. All this software can go into the PROM and offer these capabilities on reset, similar to 80s home computers like the Commodore 64.

    Once we have written, assembled and programmed our PROM to do that, now we have a rudimentary operating system that handles simple input and output. Maybe also add some useful functions that users can call from their own program.

    We could make life easier on ourselves and write an assembler and a simple file editor that we can use to write assembly language files. Then we can save the assembly file and run the assembler to create a file of machine code. We can save these new programs to storage. And now we can use those to more quickly write more complex things.

    We can add a PROM burner to our list of devices and add the capability to burn programs from memory to a new PROM. We can use that to more conveniently update the PROM on our Orange computer.

    It will be easier to write a BASIC interpreter now. Or a compiler. Now you can develop more complex programs quickly. You can rewrite parts of your assembly code in a higher level language so it is easier to maintain.

    Maybe you outgrow your computer and want to make an Orange II with a new CPU, more power, memory, etc. well, you already have the first computer so you can develop the ROM code for the new computer using the first computer. You can make a cross assembler and cross compiler. Wire software on the Orange that spits out machine code specific to the Orange II CPU.