Are you sure it's not a 686? Because apparently the Pentium Pro from 1995 is already a 686, by 2001 the Pentium 4 was already out.
Are you sure it's not a 686? Because apparently the Pentium Pro from 1995 is already a 686, by 2001 the Pentium 4 was already out.
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.
I don't expect anybody is trying to jailbreak phones that have an official way to unlock them, even if it is very annoying.
This looks good.
I don't know how to figure out on vlc what sort of output method, codec, or hardware acceleration it's currently using, so I second the other person who recommended mpv.
Can you check what video driver you are using? You might be on some kind of software renderer.
What does
glxinfo | grep renderer
say?
Input/output error is very weird, maybe you got file corruption?
Does dmesg
show any errors with the disk or file system?
If you run
sudo strace -e t=read -e status=failed --decode-fds apt-get update
you might be able to figure which file it is that cannot be read.
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'
More expensive business-class laptops, like the T-series, is I think what RedHat and others give to their employees, thus they are usually better supported than cheaper consumer models.
Radio War Nerd did an interview with Georgian labor organizer Sopo Japaridze last year about that.
Episode 369, Interview starts at 34 minutes.
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:
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.
Oh I wanted to say, "Do not use if you're
not writing bash-only scripts". I think I reformulated that sentence and forgot to remove the not. Sorry about the confusion. You're exactly right of course. I have run into scripts that don't work on Debian, because the author used bashisms but still specified /bin/sh as the interpreter.
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.