• 1 Post
  • 32 Comments
Joined 2 years ago
cake
Cake day: June 12th, 2023

help-circle
  • waigl@lemmy.worldtolinuxmemes@lemmy.worldThe good old days
    link
    fedilink
    arrow-up
    213
    ·
    edit-2
    1 month ago

    This is x86 assembler. (Actually, looking at the register names, it’s probably x86_64. On old school x86, they were named something like al, ah (8 bit), ax (16 bit), or eax (32 bit).) Back in the old days, when you pressed a key on the keyboard, the keyboard controller would generate a hardware interrupt, which, unless masked, would immediately make the CPU jump to a registered interrupt handler, interrupting whatever else it was doing at the point. That interrupt handler would then usually save all registers on the stack, communicate with the keyboard controller to figure out what exactly happened, react to that, restore the old registers again and then jump back to where the CPU was before.

    In modern times, USB keyboards are periodically actively polled instead.


  • waigl@lemmy.worldtomemes@lemmy.worldI mean...
    link
    fedilink
    arrow-up
    119
    arrow-down
    3
    ·
    1 month ago

    Non-murder solution:

    Place and hold the apples precisely on top of one another. (Make sure your fingers are not in the way.) From one side of the apple tower, go horizontally exactly two thirds of the way to the other side. At that position, cut vertically through both apples from top to bottom. You now have two pieces that are two thirds of an apple each, and two pieces that are one third each. The kid you like best will receive the end slices without the apple core in it.

    More realistically, disregard the stupid premise and make as many cuts as you need.







  • I’ve gotten used to this. The posts where I write several paragraphs and go kinda in-depth on a topic, and even do some research in the background on to make sure I don’t talk complete nonsese routinely get no upvotes at all. The ones that rise to the top are snippy one-liner remarks that get a cheap laugh out of people, but honestly don’t add anything of substance to the discussion.


  • IMHO, it was a mistake to make USB block storage use the same line of names also used for local hard disks. Sure, the block device drivers for USB mass storage internally hook into the SCSI subsystem to provide block level access, and that’s why the drives are called sd[something], but why should I as an end user have to care about that? A USB drive is very much not the same thing for me as a SCSI harddisk. A NVMe drive on the other hand, kinda sorta is, at least from a practical purpose point of view, yet NVMe drives get a completely different naming scheme.

    That aside, suggest you use lsblk before dd.





  • Imagine the following:

    You actually can stop the time by snapping you fingers, but it stops time for the entire universe, including yourself, with the exception of one single observer on some unimportant planet in the Andromeda galaxy. After 100 years from the POV of that observer, time resumes again.

    Would you even be able to tell?




  • waigl@lemmy.worldtomemes@lemmy.worldSmugly
    link
    fedilink
    English
    arrow-up
    11
    ·
    1 year ago

    After googling around for a bit, and then switching to duckduckgo instead (Google becomes aggressively unhelpful as soon as you have words like “ejaculated” in your query. Duckduckgo does the same thing, just not quite so much.), it seems the book in question might be “The tenant of Wildfell Hall” by Emily Brontë.





  • Writing good comments is an art form, and beginner programmers often struggle with it. They know comments mostly from their text books, where the comments explain what is happening to someone who doesn’t yet know programming, and nobody has told them yet that that is not at all a useful commenting style outside of education. So that’s how they use them. It usually ends up making the code harder to read, not easier.

    Later on, programmers will need to learn a few rules about comments, like:

    • Assume that whoever reads your code knows the programming language, the platform and the problem domain at least in general terms. You are not writing a teaching aid, you are writing presumably useful software.
    • Don’t comment the obvious. (Aside from documentation comments for function/method/class signatures)
    • Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments. Reserve the “what” style comments for where that just isn’t possible.
    • Do comment the why. Tell the reader about your intentions and about big-picture issues. If an if-statement is hard to parse, write a corresponding if clause in plain English on top of it.
    • In some cases, comment the “why not”, to keep maintenance programmers from falling in the same trap you already found.