• 0 Posts
  • 49 Comments
Joined 1 year ago
cake
Cake day: August 4th, 2023

help-circle


  • "The Open Book is my long-standing attempt to design a comprehensible and accessible e-book reader that you can build yourself (or at least have manufactured affordably). The current edition is something I’m calling the “Abridged” or “Developer Preview” edition. It’s designed to be incredibly simple: there are 7 through-hole and 14 surface mount components, nearly all in a chunky 1206 package that’s easy to hand solder. The tradeoff is that it has no LiPo charging circuit; instead it uses AAA batteries, making it a bit more chunky than previous versions of the book.

    The goal with this version is to get hardware in hands so we can start hacking on firmware."

    https://www.oddlyspecificobjects.com/projects/openbook/

    So:

    • This is a hobby / project of love
    • The current focus is on hardware

    I’m sure that the eventual plan is to support ePub.

    I’m not sure it will ever get there, because it’s not a well resourced project, but I personally don’t like criticizing one person’s efforts, which they are making freely available.






  • I tried to solve these cross-distro compatibility problems in a generic way with this “standard”, more years ago than I’d like to think about:

    https://www.supergrubdisk.org/wiki/Loopback.cfg

    If someone wants to come up with a bootloader agnostic solution rather than one tied to grub, like an extension to Bootloader spec , https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ , I’d be happy to evangelize it and add support to grub for using it.

    I’m not aware of any other bootloader that supports reading a config file that exists within an iso though, and secure boot support may add additional complications.

    Bottom line:

    I feel like we could relatively easily get to a point where every Live iso that actually supports loop booting can just be added, as a file, to your USB drive (from Windows, or your android phone even) and be detected at boot in a nice little menu, no editing of config files needed.

    I don’t have the time or spoons to get the Linux community there alone, but if people are interested in helping I’m more than happy to pick this up again.

    (Note: Please don’t blindly suggest “Just chain load the iso!” Things aren’t that easy, unfortunately).





  • Or you can recruit heavily in areas where folks are disadvantaged and have few options, dangling education in front of them in exchange for being willing to kill or die for you.

    This is absolutely what we do in the U.S. and it’s abhorrent.

    I guess what I want is for nobody to be so desperate for their basic needs that they feel compelled to kill and die in war.

    And if we had a country that cared for all of its citizens and didn’t start wars of aggression, maybe more people would want to enlist as they have real values to protect and have a reasonable expectation that they won’t be committing atrocities?

    Honestly not a criticism of you or your comment. Lot’s of people are advocating for the same thing; You just said it plainly.

    …Anyway, this is all terrible and we absolutely can do better, starting with building community locally, mutual aid, protesting, and listening to marginalized and oppressed people’s.


  • Ahh, sorry.

    For Fedora it looks like the default /etc/default/grub looks like this:

    GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true

    ( Taken from https://discussion.fedoraproject.org/t/how-to-regenerate-etc-default-grub/72677/9 )

    If you’re using LVM / LUKS you may need additional kernel parameters, like resume=… for suspend to disk to work properly.

    Please, before doing anything else, post the output of the following:

    cat /proc/cmdline

    And make a backup of your existing grub.cfg with:

    sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg-backup-$(date --iso=s)

    Also, be sure that you have a LiveUSB on hand. You don’t want to be SOL if we break something and can’t boot again without fixing it first.




  • This should get you back to defaults:

    sudo cp /usr/share/grub/default/grub /etc/default/grub && sudo update-grub

    At some point you definitely did accidentally write to /etc/default/grub when you meant to write to /boot/grub/grub.cfg.

    There’s no shame in that; Grub’s configuration process is very confusing and counter-intuitive.

    Everybody who has used Linux long enough has stories of breaking their systems in sillier ways, and this didn’t even really break your system 🙂.


  • Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.

    ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.

    And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.

    ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.

    That would kill your battery life.

    Pulseaudio’s (terribly named) “glitch free” audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.

    So, from the user’s perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.

    ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.