You use Jitsi meet, their free service, to watch movies???
You can use OBS to do that, it looks like a lot but it is the best tool for that. Dont know if it has some ffplay/MPV plugin to internally play videos but I think so
Your half right. It’s not really the OS’s fault but rather the fault of the browsers and app-frameworks that use the browser in the background (electron). Because neither Firefox nor chrome have this feature implemented for Linux. The official Discord client doesn’t do it either but other ones such as Sunroof do. It’s possible that at least one Matrix client has learnt to share the screen with sound on Linux but I don’t know of any (I also don’t use Matrix a lot so don’t pay too much attention to my experience on that)
On KDE Plasma 6 + Firefox (both Wayland) I can share a window and workaround audio sharing by routing desktop audio to microphone. Vesktop (Discord alternative) supports screenshare w/ audio.
Hell be the host, hell control the stream and no one else. So one sender with no internal communication (coz they might have discord or something setup for their conversations)
according to google, the average no of friends is 5. So may be around 5 receivers
This is your best option. I did do movie nights with friends during the pandemic in a similar way, but I used OBS Studio to create the stream and Monaserver to stream it to all users. I did not know VLC can handle the streaming to users directly, making this dead simple to setup without additional software. You just need to know how to configure your router to allow the needed port forwarding.
A bit less simple, but for a great solution, you could host a jellyfin server and give each friend their own user account in order to then use the syncplay feature.
I run Wayland on my desktop, but there’s nothing (in my flow) that I miss on my work or travel laptop (which are both X11)
I guess external monitors are a little clunky on my work laptop, but monitor profiles on XFCE solve the problem (and that’s assuming I wouldn’t have issues on Wayland, too).
I’m not a Wayland hater, I just don’t have much benefit from it and am waiting for XFCE and the accessibility APIs to get better before I switch.
I’d say flatpak isn’t the future because it’s already here and seems to be universally accepted as the cross-distro package manager.
I do like how the Nix package manager handles dependencies, but it’s not suitable for app developers packaging their own apps because of its complexity.
If a better flatpak comes around I’d use it too, but at least for graphical apps I don’t know what it’d have to do to be better. In my opinion, flatpak is a prime example of good enough, but not perfect and I’d be surprised if there was a different tool with the same momentum in 15 years (except snap, but they seem too Ubuntu specific).
Not officially but people have managed to reverse engineer it before in order to host their own - forum.snapcraft.io/t/…/27109
Whilst I do get the sentiment (and in no way do I support Canonical in keeping it proprietary), how likely is it that alternative Snap repos are going to show up if they did make it possible? Even with Flatpak where it is encouraged and documented I don’t think I’ve heard of anyone setting up a Flathub alternative of any significance.
And I wasn’t aware of the Elementary thing with Flatpak! Admittedly I hadn’t really thought of it in that way, I was thinking something more akin to F-droid where there are a couple of extra repos you can add which have applications not on the main one due to slightly looser requirements. But making it specifically for apps for that ecosystem in particular makes a lot of sense.
Snap is a cesspool for malware and shovel ware. The best apps are packaged by Canonical. Also, when people still cared about Snap, there were frequent reports of incompatibilities because it was developed with Ubuntu in mind.
Snap is shit. I started using flatpak because apt didn’t support apps that I wanted and snap only supported ancient releases. .deb is annoying too and .appimage I don’t like to have the files hanging there
Well… of course only time will tell, but the fact that we’ve been doing that for sooo long… (me for ~20 years?) would imply that it might just be around for longer than snap/flatpak/etc
(Not incredibly educated on Flatpaks, please educate me if I’m wrong) My main issue with Flatpak is the bundled dependancies. I really prefer packages to come bundled with the absolute bare minimum, as part of the main appeal of Linux for me is the shared system wide dependancies. Flatpak sort of seems to throw that ideology out the window.
Let me ask this (genuinely asking, I’m not a software developer and I’m curious why this isn’t a common practice), why aren’t “portable” builds of software more common? Ie, just a folder with the executable that you can run from anywhere? Would these in theory also need to come bundled with any needed dependancies? Or could they simply be told to seek out the ones already installed on the system? Or would this just depend on the software?
I ask this because in my mind, a portable build of a piece of software seems like the perfect middle ground between a native, distro specific build and a specialized universal packaging method like Flatpak.
well, the point of flatpak is to have bundled dependencies so they run predictably no matter the distro
if one of your software’s dependency gets updated, and your software isn’t, you may run into issues - like a function from the library you’re using getting removed, or its behaviour changing slightly. and some distros may also apply patches to some of their library that breaks stuff too!
often, with complex libraries, even when you check the version number, you may have behavioural differences between distros depending on the compile flags used (i.e. some features being disabled, etc.)
so, while in theory portable builds work, for them to be practical, they most often are statically linked (all the dependencies get built into the executable - no relying on system libraries). and that comes with a huge size penalty, even when compared to flatpaks, as those do have some shared dependencies between flatpaks! you can for example request to depend on a specific version of the freedesktop SDK, which will provide you with a bunch of standard linux tools, and that’ll only get installed once for every package you have that uses it
From the conversation it seems to be a similar situation to the project I’m with is in. The flatpak is essentially community maintained rather than being directly supported by the team. To become verified it needs to be done so by a representative of the maintainers of the software. To be verified it doesn’t have to have a team member involved in it but this is a requirement Inkscape seem to have imposed.
For us we just aren’t in a position to want to support it officially just yet, we have some major upgrades coming to our underlying tech stack that will introduce a whole bunch of stuff that will allow various XDG portals etc. to work properly with the Flatpak sandboxing model. To support it now would involve tons of workarounds which would need to be removed later.
But the lack of verification and validation is a huge risk to flatpaks. As someone formerly involved with securing OSes, this kind of thing was scary back then and doubly scary since it entered its “don’t confirm; just get in, loser” phase.
😱 so I guess install via appimage?? Package manager? 🤷 🤯 brain malfunction. Im thinking don’t download or install until you verify the download with a hash and hopefully signature if they exist 🤷 use fedora? Which has better security? 🤷🤯
Flatpak does verify the integrity of files as it is downloading/installing them. For ostree remotes this is done using GPG signatures (which are better than mere checksums). If you want to see the commit ID (which is like a checksum) for something on flathub use e.g. flatpak remote-info -c flathub org.gnome.Builder and for the local copy flatpak info -c org.gnome.Builder. For OCI remotes we at least check SHA256 sums and there might be more integrity verification mechanisms I’m unaware of.
Should all be in place. Even nvidia driver support. It’s one of the rare cases where I actually support nvidia on a technical level, that is, having explicit sync is good. I can also understand that they didn’t feel like implementing proper implicit sync (hence all the tearing etc) when it’s a technically inferior solution.
OTOH, they shouldn’t have bloody waited until now to get this through. Had they not ignored wayland for a literal decade this all could’ve been resolved before it became an issue for end-users.
Sd cards arent the same as usbs or ssds. They seem the same because it’s like the same thing right? But they’re not.
Most usbs and all ssds have a controller that actually handles writing and reading to and from the memory chip. The controller lets them do things like recognize bad spots and write data elsewhere, perform secure erase functions, wear leveling and all sorts of the kinda stuff we expect of components we’re gonna use as hard drives.
Sd cards almost universally don’t have that controller. The goal for sd cards was to provide bulk storage to all kinds of embedded devices like cameras and later, phones. Because there’s no controller, there’s no wear leveling, no overprovisioning, no secure erase. That’s fine because the goal was always to just slam the sucker full of pictures and never erase it till it gets full, then start all over again.
But if sd cards aren’t acceptable hard drives then how come we use them in little sbcs like raspberry pi and whatnot?
Well the install process in that case almost always writes the system to the card first instead of doing a million reads and writes to figure out what repositories are available, updating packages, etc. sbc systems using sd cards as their storage are also (or should be!) configured to do minimal writes, with constrained log sizes and minimal swap.
So don’t use an sd as a usb or hard drive.
People might say that I’m wrong in replies to this post. They’ll say that sd cards are fine and that they have over 20k write cycles on their hyinx megacard128. Sd fails silently. I am not wrong. You literally just had problems installing from an sd. I can’t tell for sure if your problems came from using an sd or misconfiguring the new partition scheme but it sure as heck didn’t help that you used an sd as your install media.
Okay, now you said you have windows back up and running. Is it fully recovered and working good?
Is it using the whole drive?
Do you have all your files back?
Have you made a backup?
If you answer these questions I can walk you through the process of setting up windows to dual boot Linux in a way that won’t fuck up.
Yes I have recovered windows & all my files completely now & that USB I used for windows (just bought one big enough for booting) should be able to be used for linux files, I can just transfer them over from the SD can’t I?
I have a 28GB D drive that seems to be being used for recovery and backups & a 210GB C drive, I could easily free about 30GB for another partition. I have the bootable USB set up.
okay, that’s done. Now what do I do? I am assuming we need to tell the PC to install linyx into that partition (& only that partition without erasing the entire drive)
alright, go through the ubuntu installer and pick the “install alongside” option when it comes up. it ought to be at the same time that it offers you the option to erase the disk altogether. the “installation type” menu. if you don’t get that option, stop and say so.
e: i just finished installing ubuntu desktop lts alongside windows 11 in a vm using the process you’re doing. its the disk selection menu, not the installation type.
Let me check if I have this right. Once i have the USB and disc partition set up boot from the USB & go to the installer. Then select download alongside and chiose tge partition to install linux to?
Okay so Just leave some unallocated space of tge size needed tge option to install alongsode windows will be tgere select that and itll install to the unallocated memory, without touching windows?
Yep. As long as you pick install alongside it won’t screw up windows. If you don’t see that option in the “disk selection” part of the process then bail out.
“SmartMedia” cards are the latest consumer flash package that you can get without a controller. Everything else has one. Even SD cards do. SD cards may not have a very good wear leveling algorithm, they may not have a lot of memory to keep track of fancier remapping structures, but they do have some. SD cards have a little arm processor inside managing everything, because it’s far cheaper than not having one. That processor is responsible for self testing pretty much everything at the factory - the testing jig is mostly there to deliver power and wait for the card to map the good and defective flash regions all by itself.
From my short time with proxmox, I had to dive into the command line to do configuration at the host level that couldnt be done with the UI. I think nixos will help replacd those ad hoc configurations with nix options. In the many articles I read about gpu passthru, and also doing harddrive passthru, I had to work in the host debian environment.
I dumped proxmox because I couldnt get gpu passthrough to work, and havent looked back. Nixos modules and docker have served me better than VMs for my usecase.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.