• 9 Posts
  • 74 Comments
Joined 1 year ago
cake
Cake day: June 5th, 2023

help-circle

  • I'm still skeptical. At the time of the original Pentium (the last 586 from Intel, the fastest of which was 300 MHz), the usual amount of RAM was something like 16 or 32 MB. A 586 with 1 GB of RAM is extremely weird and probably impossible unless it's some sort of high-end server. This does not check out.

    Oh and DDR is also from around the time of the Pentium 4. I don't think there exists a machine that has both DDR and an original Pentium (aka 586). Again, this does not check out and is probably impossible.

    There could be another reason it won't boot.



  • I used unstable for years (don't anymore). It broke itself in minor and major ways every couple of months. Maybe it wouldn't boot or X wouldn't start, or the package dependencies were broken and I couldn't install certain packages for a couple of days. Stuff like that.

    You will have manually to fix these things from time to time, or do a workaround (like manually downgrading certain packages), or wait a week so stuff gets sorted. Most of the time it works fine though. I imagine the experience is somewhat similar to running arch.

    You do not get security fixes, but it's not a massive problem usually, since you'll get the newest version of most software after a couple of days (occasionally longer) after it is released.

    Anyway do not recommend unless you want to be a beta tester. I did report bugs sometimes, but almost always by the time I encountered an issue, it was already reported and a fix was already in the works.






  • Yes. You can use lvresize to reduce the size of your logical volumes.

    You first need to shrink the filesystems using e.g. resize2fs (exact command depends on filesystem). See the manpage for details, but for shrinking the filesystem it needs to be unmounted, so you'll need to do this from a live usb or something.

    After that you can use lvresize to resize the logical volumes. Pro tip: You can shrink the filesystem to e.g. 20 GiB, but shrink the partition to 30 GiB, just to make sure you're not cutting off the filesystem due to some slight error or inexactness, and then afterwards run resize2fs again to resize the filesystem back to fill the whole partition, which it does by default if you don't specify any size.

    Also note, since you have LVM-on-LUKS, when you boot into a live cd, you will need to first use cryptsetup to decrypt your partition, and then run vgscan to make lvm find the unecrypted partition.


  • extension design and strong content filters make AdBlock for Firefox a solid choice for people who don’t necessarily despise all ads

    Do these people exist and if so, have they been checked for brainworms?

    The rest is also stupid, ublock origin can and does block trackers, and can be made to block more stuff if you want. It's strictly better in every way than the competition, which lets through more stuff, and/or sells your info. The article would be very short though if they just said that.


  • A lot of distros, I think, are started more due to political/social/psychological reasons, and not fundamental technical reasons, and that's why a lot of them are so similar. Those reasons can be good and legit, but sometimes they are probably wrongheaded (but understandable), like an unwillingness to engage with upstream because that's tedious and frustrating, whereas the technical work of creating another distro with oneself in charge may be more fun.

    Also, of course, once a distro is big enough, with a sizable community of developers and users, there's a strong incentive to keep it going, even if it's very similar to another distro. Maybe there used to more of difference in the past, but you're not going to convince a whole community to just shut down and join some other project. And business-run distros will keep going as long as the company is making money there is some business reason to keep doing them.


  • I use tlp.

    I also have a battery info using i3status in the status bar, and a script I named battery-check, which warns me via a dunst popup and a beep when the battery gets low:

    #!/bin/sh
    set -eu
    
    bat=/sys/class/power_supply/BAT0
    
    if [ ! -d "$bat" ]; then
        exit 1;
    fi
    
    status=$(cat "$bat/status")
    energy_now=$(cat "$bat/energy_now")
    energy_full=$(cat "$bat/energy_full")
    
    battery_percent=$(( ${energy_now}00 / ${energy_full} ))
    
    if [ "$status" != "Charging" -a "$battery_percent" -le 15 ]; then
        dunstify -t 8000 -u critical "Battery at ${battery_percent}%"
        play -q -n -c1 synth 2 sine 600
    fi
    

    I run this from my ~/.config/sway/config like so:

    exec sh -c 'while true; do sleep 180; battery-check || break; done'
    




  • As others have said, if you quote your variables, they won't get split on spaces. The Unix shell unfortunately has ton of gotchas like this, and the reason this is not changed is backwards-compatibility. Lots of shell scripts depend on this behavior, e.g. there might be something like:

    flags="-a -l"
    ls $flags
    

    If you quote this (ls "$flags"), ls will see it as one argument, instead of splitting it into two arguments. You could patch the shell to not split arguments by default, and invent some other syntax for when you want this splitting behavior, but that would break a ton of existing shell scripts, and confuse users who are already familiar with the way it works right now. It would also make the shell incompatible with other shells, and violate the POSIX standard.


  • I did it during the gcc 3 transition. I used a very new gcc 3 (maybe even pre-release), which wasn't at all recommended. A couple of (most?) C++ packages didn't compile (some change having to do with namespace scope), which meant I had to fix the source of some packages (generally pretty trivial changes, usually having to prepend namespace:: to identifiers). Overall this problem was pretty rare, like it affected less than 1% of C++ files, but with things like Qt or Phoenix (or whatever Firefox was called back then), with thousands of files, I had to fix dozens of things. I guess running into problems made it more interesting and fun actually.

    Did I learn anything? The main thing I learned is about all the different basic packages and what sort of binaries and libraries are included in them and why you need them. Also about some important config files in /etc. And a bit of shell experience, but I dare say I knew most of that stuff already. How much you learn depends a lot on how much you already know.

    Overall what I learned was not very deep knowledge, nor was it a very time-efficient way to learn. But it was a chill learning experience, goal-oriented and motivating. And it made me more comfortable and confident in my ability to figure out and fix stuff.

    Also it's obviously not practical to keep that up to date, so I switched back to a distro after a couple of months of this.




  • I’ve been in the discord and on github for a while

    Oh a real life member of the hyprland community, let's see if the rumors are true.

    has a bit of a “personality”, as many good developers have. Nothing wrong with that.

    Well, that's some first-grade bigot apologia. I guess that discord really is bigot central.

    Let’s hope this thing blows over quickly.

    Is it because your little clubhouse is drawing too much negative attention?



  • Btw, if you ever wondered why Debian uses dash as /bin/sh (the switch was a bit annoying at the time), I think the reasoning was something like this:

    • dash is a bit faster, which might have saved a second or two on boot times (this was before systemd). Same applies to compilation times, configure scripts run faster with dash.
    • A bunch of #!/bin/sh scripts in Debian did not actually work if you replaced /bin/sh with another shell, which I guess some people wanted to do. Making dash the default /bin/sh forced everyone to fix their scripts.

    Also some history on the abomination that is m4sh, famously used by GNU autoconf configure.ac scripts. Apparently when autoconf was released in 1991, there were still some Unix systems that shipped some 70s shells as the default /bin/sh. These shells do not support shell functions, which makes creating any sort of shell programming library pretty much impossible (I guess you could make a folder full of scripts instead of functions). They decided to use m4 preprocessor macros instead, as a sort of poor man's replacement for functions.

    In hindsight, it wish they had told commercial Unix sysadmins to install a proper /bin/sh or gtfo. But the GNU people thought it was important to make it as easy as possible to install free software even on commercial Unices.