she/they
This is probably the main reason every mainboard has TPMs now, since all common operating systems (Android, iOS/MacOS and Windows) do it.
From what I heard the Ubuntu installer offers a version that doesn’t suck (if secure boot is enabled at install time) so using that is probably fine, but I would beware of trying to DIY it since it’s easy to do incorrectly, most guides are wrong, and you will likely end up with easily bypassable encryption.
If your privileged user doesn’t have a password, in some cases this could lead to any program being able to elevate their privilege quietly, unlike UAC.
I think this is the most important part. There really isn’t any protection against random processes trying to do some version of exec sudo $0 except for the fact that it requires a password.
The FSF says this is the case but the actual legal situation is less clear, especially in the EU. Linking does not necessarily constitute a derivative work. Even decompilation of a (proprietary) library in order to link to it might be acceptable depending on the circumstance.
This isn’t something that can be fixed with a license, it’s a direct result of EU copyright law. Historically companies have tended to err on the side of the FSF interpretation, but it is on somewhat shaky grounds.
Sure it’s a problem when that happens. It’s not the only problem, and honestly in the case of coreutils it’s not really the most relevant one.
Do you think it’s likely that corporations will take over UNIX-likes with proprietary coreutils extensions forked from uutils? Because that’s the one thing that is legal to do with an MIT/BSD licensed coreutils but not with GPL licensed ones.
GPL has been battle tested in court
Well… parts of it have been. Others have not. Notably the FSFs view on whether or not linking to a GPL-licensed library constitutes a derivative work (and triggers the GPLs virality) is not universally shared by legal scholars. In the EU in particular linking does not necessarily create derivative works, despite what the FSF says. This has not been tested in court.
Some other parts like the v3 anti-tivoization hasn’t gone to court either, but that has lesser ramifications (assuming you’re not TiVo).
THAT’S how we have corporations profiting from GPL. Not because GPL allows anyone to use it.
What distinction are you trying to draw here exactly? They can do it precisely because the GPL (v2) allows it. The GPLv3 has some extra restrictions but doesn’t do anything about closed source drivers (beyond the linking thing) or the Google Play Services type of proprietary extensions.
Funny you say that because OS X shipped (and probably still ships) plenty of copyleft licensed software such as Bash. The Linux kernel is used in Android and ChromeOS.
If you want to stop corporations from profiting off your work, putting a GPL on it isn’t gonna do it. In fact no free software license will do it, because by definition they allow anyone to use and ship your software.
All of the 5 people who use (non-ESR) Firefox on their 2002 Pentium 4s will certainly be very unhappy about this.
The term used is “Solução final”, and it’s a pretty literal translation. It’s absolutely possible to make the connection between the terms, but it does require bot ha somewhat in-depth education on the Holocaust and some linguistic sense. Now it’s entirely possible that LGFaé’s history teachers really dropped the ball on the first part, but it’s not clear to me that this is what must’ve happened here.
Speaking for myself I would be embarrassed but not especially surprised if some phrase that I use frequently has a similarly unfortunate meaning, especially regarding an African or Asian genocide. As bad as all genocides are, you just can’t be well educated on all of them, especially with just a regular K-12/A-level/equivalent history education which also has to do things like teaching people how to read (something most of the world is currently failing at).
I don’t have deep knowledge on the topic but you might want to look into EDID, which is how your system knows what resolutions the monitor supports. Incorrect detection of maximum resolutions and refresh rates is a semi-common problem on Linux and the fix for that is a custom modeline; setting one will be compositor dependent on Wayland (on X11 xrandr will do).
However it’s also possible that all the cables you have are bad and/or don’t support 8K.
In defense of the author and their education… They’re Brazilian so English probably isn’t their native language, and their history education was almost certainly in Portuguese. I don’t think it’s necessarily an indictment of their education that they weren’t taught about the English translation of a German phrase, and I don’t think it’s reasonable to apply the same standards of subtext awareness to native and non-native speakers either.
That’s true from a technical perspective. But in reality devs (especially ones who aren’t making “Linux apps” but are doing things like porting a previously Windows-only game to Linux) will occasionally ship a broken Wayland client. The compositor could then still give that a basic titlebar with window buttons like KDE and Cosmic do, or alternatively it can refuse to do it and make the novice user annoyed at the system as a whole.
I’m not really convinced that requiring all Wayland clients to draw their own decorations was the correct decision in the first place, but even if we accept it, I think there’s still a convincing case for fallback SSDs.
Now if there was just an official API from all window managers that can check this configuration
This actually does exist. Reasonable Wayland Compositors will negotiate with their clients on whether they should use CSDs or SSDs. To an extent Qt does this: It prefers SSDs but it can draw CSDs if the compositor can’t draw SSDs (or signals that it doesn’t want to), which is why proper Qt apps are perfectly usable on GNOME Wayland despite missing SSDs.
It would be possible to go even further and make apps that display menu and tool bars on compositors that prefer SSDs (like Plasma/KWin) and nice GTK-style decorations on others. It just happens that most apps either really want to draw their CSDs (mostly because they’re made for GNOME, a.k.a. anything using Libadwaita) or they don’t really have a use for them (like regular Qt apps).
The biggest drawback of not providing any SSDs even as a fallback is obviously… what if the app just doesn’t draw CSDs? ~~There are many new Linux users who try to get something like DaVinci Resolve running and then can’t maximize it because it doesn’t have CSDs. For these users it just makes using Linux feel broken for basically no reason.~~¹
This is also a burden for application developers. Maybe the DaVinci Resolve devs should just fix their app (from what I heard it’s a massive PITA in all aspects imaginable), but is it really reasonable to also expect e.g game devs to add dependencies on libdecor or whatever solely to unbreak window mode on GNOME Wayland?
¹ Edit: I have since learned that Resolve actually does draw CSDs, it just doesn’t draw the window buttons. That’s certainly a choice… I think the overall point isn’t too affected but this specific app isn’t a good example since it would still be broken if GNOME had fallback SSDs.
That’s a largely unrelated topic… You can have theming without SSDs (as seen in most standalone compositors and also kind of Cosmic) and you can have SSDs without theming (at least in theory, I’m not aware of a project actually taking this stance).
There’s apparently a ZSH plugin for this with a quite a few stars, though I haven’t used it and can’t speak for how well it works. In other shells what you want just doesn’t exist to my knowledge, though it should be possible to script it with enough effort.
The problem is that in the terminal you always have at least two layers of input handling in the terminal emulator and the shell. And these layers talk to each other by emulating a 70s VT100. This leads to some issues, in no particular order:
All of these problems gets worse if you add multiplexers like tmux by the way.
Now it would be possible to write a bespoke terminal emulator and shell combination that unifies selection and makes all the reasonable keybindings actually work. There are attempts at this, such as the Emacs Eshell. Unfortunately Emacs people don’t quite share your idea of what reasonable keybindings look like (and it’s also a little bit broken, though for mostly unrelated reason).
Ultimately though the main reason this is an unsolved problem is that most Linux users just get used to the regular Readline line editor that all commonly used shells ship with. Complex edits can always be done in your $EDITOR (via C-X C-E in Bash).
I’m not a btrfs expert but AFAIK high unreachable space usage is usually a result of fragmentation. You might want to defragment the filesystem and see if that helps.
I will note that btrfs makes estimations of used/available space very difficult by design, and you especially can not trust what standard UNIX tools like df and du tell you about btrfs volumes. Scripting around du or using ncdu will not help here in any way. You might want to read this kernel.org wiki article as well as the man pages for the btrfs tools (btrfs(8) and particularly btrfs-filesystem(8)), which among other things provide versions of df and du that actually work, or at least they do most of the time instead of never.
There’s an argument to be made that system software like filesystems and kernels shouldn’t get too smart about validating or transforming strings, because once you start caring about a strings meaning, you can no longer treat it as just a byte sequence and instead need to worry about all the complexities of Unicode code points. “Is this character printable” seems like a simple question but it really isn’t.
Now if I were to develop a filesystem from scratch, would I go for the 80% solution of just banning the ASCII newline specifically? Honestly yes, I don’t see a downside. But regardless of how much effort is put into it, there will always be edge cases – either filenames that break stuff, or filenames that aren’t allowed even though they should be.
The usual problems with parsing ls don’t happen here because Nu’s ls builtin returns properly typed data. You can work with it in pretty much the same way you would work with it in Python, except that Nu has a composition operator that doesn’t suck ass (|), so you don’t have to write as much imperative boilerplate.
I have a number of reservations regarding Nu (the stability of the scripting language, unintuitive syntax rules, a disappointing standard library) but this particular argument just doesn’t apply.
Pano perhaps? It doesn’t show up at the cursor but you can search in it, the keyboard works the way you would expect and it auto inserts on selection.
The GNU utils vs BSD utils issue should be easy to work around with a bit of symlinking and
PATHmodification:or in script form:
/usr/local/opt/...is probably not the best place to put this but you get the idea, you can make it work with POSIX tools. I don’t know that much about Chimera Linux but I’d be very surprised if nobody has thought of doing this systematically, e.g. as part of a distributable package.