TheCaconym [any]

With the state of Javascript being what it is, you probably can chain syllables randomly and have a fair chance of the resulting word being the name of a temporarily-existing framework

These days the GNU rm specifically warns you and asks you to confirm before proceeding

One of the multiple lemmy newcomers that defederated from us; in their admins’ words, because we apparently “deny certain genocides”.

@suspended@lemmy.ml what “genocides” would those be exactly ?

What’s the browser you’re using ? and also please do:

glxinfo|egrep -i "^direct"

You’re looking for a line that says “direct rendering”; specifically whether or not it says “yes”. This will help pinpoint if you’re actually using your GPU or some onboard chipset instead.

With that being said, even assuming you use the latter, stuttering video playback in the browser is weird; if using firefox, out of curiosity: try to disable or enable hardware rendering (options > advanced > general), and try again. Switch it back to what it was when your test is done.

BIOS booting stays winning

Kraken, also by Mièville, is also somewhat of a match; as well as Neverwhere by Neil Gaiman.

Thank you !

I stand corrected, that does look close to noscript’s feature, thanks !

Though I don’t know if it has a “whitelist mode” (all JS disabled by default everywhere but content still fetched) like the default noscript has.

uBlock Origin does not block javascript execution depending on the domain. They do not serve the same purpose.

noscript is essential security-wise IMO

DVI should not control the monitor’s actual physical controls - it does include a small non-display channel but IIRC that’s used to get the display modes info from the monitor, and potentially to transmit contrast information and the like; some monitors will prevent you from adjusting contrast if DVI sends that info for example, but it certainly shouldn’t disable the power button.

My guess would be a hardware issue - in the monitor itself - which is somehow triggered by the sequence in which you do enable the displays, and your system update being unrelated. It’s a huge guess though. One thing to try is repeating both sequences (the one that locks your buttons and the one that doesn’t) using a live CD - not a “nobara 38” one if such a thing exists, another distro. Trying both monitors on another computer would be an interesting test as well, although not necessarily that helpful (because if it doesn’t occur there, it might just mean the issue is triggered by peculiarities in your graphic card).

deleted by creator

I really wanted to avoid a debate (doubly so in a thread where some dude just wanted some help), which is why I’m trying not to engage the various answers I got; though just one thing since I apparently can’t help myself: Qubes, which you cite, is indeed an example of such improved security done correctly, through an hypervisor and a solid implementation; not cgroups, some duct-tape and the same kernel, and thinking your security has improved. Thanks again, at any rate.

I disagree with most of the benefits you list (chief among them “increased security”) - not to mention half of them are already supported by traditional package managers - but I was genuinely curious so thanks for the rationale.

Can I ask why you choose to use one of those weird “immutable” distributions in the first place, out of curiosity ?

I want an openbox/fluxbox look and UI. About the only one I know of is labwc, and it’s shit (despite being proudly on your list). I’m fairly sure that a lot of these, in fact, aren’t close to usable.

Again, it’s not that relevant, for now I can still use Xorg. For now.

Previously, on Linux, your desktop environment is made out of:

• The display server (xorg), in charge of dealing with the video card (by talking with drivers in the kernel through a unified interface, DRI), and handling how to display stuff properly on your particular combination of hardware, including your physical screen and its peculiarities.
• A window manager, in charge of asking software for what they want to draw, then drawing windows, decorating them, etc. and more generally organizing what will be displayed on the screen and how it will be displayed.
• A protocol allowing both to communicate between each other.

That protocol is old, shitty, and insecure. Those are rightful criticisms of it, and it could be argued there is a need for an alternative. This is the often touted justification for wayland.

Note that the way windows and the general desktop environment is handled in the model above is completely distinct from the actual display server; this has a nice advantage: one can write a WM relatively easily, and as such there are hundreds available for linux users to choose from - including some that traditional Windows and Mac users would consider visually exotic and different, such as tiling WMs. This has long been considered a distinct superiority of Linux over, for example, Windows, where all of this is a monolithic block.

Now the dudes that introduced wayland didn’t just decide to secure the protocol; they decided to do away with that separation. Now a “compositor” handles all the stuff both xorg and the WM used to do. This means that almost none of the existing window managers work on this thing (actually the truth is none of them do, but Gnome and a few others for example created whole new compositors - today, you can run “gnome” either with that shit or with Xorg, for example), and that there will be far less of them to pick from in the future. The people implementing wayland didn’t even consider this an issue at first (everyone uses gnome or KDE, right ? imbeciles), so IIRC third party devs eventually tried to implement a library to restore some degree of separation (wlroots). This still requires reimplementing a WM though, and ultimately is extremely limited anyway due to the very “security” concepts the wayland protocol introduces. Some stuff that was trivial on Xorg will not be possible at all.

You might be considering why we’re talking about security in the context of a display server.

Well, the Wayland people noticed that more and more, people were installing software on Linux not through the official repositories of their distributions (which are high quality, somewhat audited, etc.) but from a galaxy of alternatives proposed by a variety of actors: flatpak, AppImage, snap, etc. The reason for this is the quality of software in general has taken a dive, and so has the quality of developers in the open source community; the usual process for someone wanting to be published on, say, debian, would normally have been to follow a few simple rules and to publish your package, accepting it’ll be audited and you may have a few points to work on before it’ll get up on the repos. Many devs these days are not interested, and deploy their software through the alternatives I mentioned above (which are basically all container or chroot based approaches to produce a “minisystem” with a set of defined libraries, meaning only your kernel will differ from the person having published that package).

As a result, a lot of clueless people are now installing shady software like monkeys on their system, coming from anywhere, just like on Windows. As such, the Wayland creators consider stuff such as an application discreetly capable of capturing the screen, or copying the clipboard from another app, to be potential “security issues”. You may be interested to now such “security measures” do not exist on, for example, Windows (but the “security issue” do).

I’m not even trying to argue whether or not they’re wrong here. I think mostly they are - the amount of issues and use cases they didn’t consider is incredibly large, and it’s been biting them in the ass ever since - but it’s irrelevant; in theory this would not be much of a problem because, you can just keep using Xorg and your WM, right ? the fear is that maintainers and support for these will dry up (I doubt that, personally), but also and more cruciallly that as Wayland becomes more and more omnipresent for many users, various features from various critical software - such as the browser - will eventually become problematic for Xorg users.

I cannot try it, as my window manager (and in fact almost the entirety of small lightweight window managers) is not compatible with it, and never will be given the insanely higher requirements to implement a compositor compared to a WM. Wayland supporters say that’ll change; I don’t see how.

I was about to say “no it doesn’t” (having installed bookworm a few weeks ago, and most definitely not having wayland), but actually it seems you’re right, and “by default” just means “if you choose one of the compatible desktop environments”, one of which appears to be the default selection.

If that’s all they plan on doing: awesome, actually, this way anyone can pick what they prefer. I was afraid they were going to pull something like systemd (though ultimately it makes sense, as maintaining sysvinit stuff for all services would have been unfeasible; not so, at least for now, with X11/Wayland).

Thanks !

I pray Debian will never include that wayland shit as the default but sadly, I suspect they will.