Thank you, that’s so kind! I’ll probably try to tackle the comments first as they come quite messy from the api, then I’ll probably give the images a go.
To be honest, I’m hoping this project doesn’t get out of my league too quickly as a have almost no experience with working with apis.
MicroOS. I didn’t switch from losedows to still have my PC restart on me while I was working. Also, it kinda broke and was annoying to configure, and had way too little documentation.
If you scroll to the bottom in the combustion section you add packages you want, and custom scripts. OpenSUSE also haa auto yast for cloning your system and applying it to another machine
Refind does not generate the proper Configs when ran from the live image. From the wiki
Warning: When refind-install is run in chroot (e.g. in live system when installing Arch Linux) /boot/refind_linux.conf is populated with kernel options from the live system not the one on which it is installed. Edit /boot/refind_linux.conf and make sure the kernel parameters in it are correct for your system, otherwise you could get a kernel panic on your next boot. See #refind_linux.conf for an example file.
This is how my /boot/refind_linux.conf looks like:
<span style="color:#323232;">"Boot with standard options" "rw root=/dev/nvme1n1p2"
</span><span style="color:#323232;">"Boot to single-user mode" "rw root=/dev/nvme1n1p2 single"
</span><span style="color:#323232;">"Boot with minimal options" "ro root=/dev/nvme1n1p2"
</span>
Every time I made this mistake I booted again the live iso, mounted the boot drive and edit it.
Edit: you can also just edit the entry on refind directly to boot once on a correct config, and then fix it inside your actual system. The error is that the root filesystem will have an uuid that relates to the live iso image, not to your actual system.
First step, in case you didn’t do that yet: Create a disk image of the partition - you don’t want to try data recovery on the actual data. Easiest is just using dd to dump the disk to another drive.
Next try running testdisk on the image to see if it can find the backup superblocks - if it does you can feed that to fsck to restore the filesystem.
If you know the blocksize of the filesystem you can also run mke2fs with the -S parameter - this will just write the superblocks. Again, only do that on a disk image, not the actual drive.
You can decide yourself if the data in that disk is more valuable than the price of a new disk to store the backup image. If it’s not that valuable I guess you can one-shot it.
You can do all of that on the device - but you only get one shot. If you mess up that’s it - so no sensible person would try any form of data rescue directly on the device. Storage is cheap, if you don’t have sufficient space on your computer just get another external disk.
I know you wont understand where I’m coming from so I wont bother explaining it. If I need another storage device than I’ll just have to wait until next year to get another storage device.
Edit: I don’t understand why I’m getting downvoted but it proves to me that I made the right choice in not explaining my situation.
I don’t think I can use that mostly because my internet package has a data cap and I don’t want to risk exceeding that.
Also, I know it’s not really the time or place for this type of discussion but I’ve noticed recently (within the last few months) that for some reason the Lemmy community has changed. I don’t know if anyone else feels that way but it sometimes seems like some users are unnecessarily hostile/judgemental towards me. I wont say anything more because once again, this is not the time or the place but Lemmy wasn’t like this when I first started using it over two years ago.
If the disc is corrupted it may be failing, recommending ddrescue over dd is probably a better call not knowing anything else about this situation. Essentially, no reason not to use it.
I swear by ddrescue. It’s a situation I strive to never be but i’ve been there before. I used it once to rescue an employees masters capstone project from their dead work laptop.
After reading about it - true. Disadvantage of doing this stuff for a long time - you miss new developments. Only reason I’m aware of testdisk is that I lost the sources of my own superblock search tool, my old binaries broke with a newer glibc, and before reimplementing it I checked if sombody else had done that in a more usable form in the meantime.
Another tool that has helped me when the others couldn’t was RecuperaBit. It has the same restrictions though, you have to do it on an image of the drive.
The hard drive should be connected by SATA or eSATA when making the image. Connecting over USB is just asking for more trouble when the drive is not working correctly.
That has changed over the last few years - I’d prefer a proper usb3 to sata bridge over a shitty sata controller - and the quality of integrated sata controllers isn’t that great nowadays.
Anecdote, I know, but for my use cases, Wayland just isn’t there yet- I wind up with far more random bugs and less battery life. I don’t pretend to know why, I’m a pleb non-developer, but until that’s resolved I’m still stuck on X. I’d love to use the new shiny thing of The Future™, but not at the cost of stability and usability.
I think that given how frequently this argument is brought up (and it is of course true about it not being completely there yet) so this is just my opinion on the situation (and I am not a dev so I am fine with being wrong and corrected). It is kind of needed for more projects/distros to start actively using it. As a lot of the stuff kind of needs the band-aid ripped off to start forcing it to get there faster at this point. Otherwise it just keeps being held back as people on the coding end of things will keep focusing on X11 issues instead of getting things ready for Wayland.
Kind of like the conundrum of mobile OSes that aren’t Android or iOS. It is hard to get people/companies to even try the new OS because the lack of apps (specifically the most common ones used by the most people). But app devs don’t want to spend time re-building or starting new apps for an OS that isn’t being used (or on devices people are buying). So at a certain point it needs both sides to interact and make progress. The OS needs the apps more at this point, and getting feedback and data from those devs makes it known where things are and aren’t working. But it is also true the devs for the apps might end up finding out the OS is actually easier to work with compared to what they have been doing/dealing with on Android/iOS.
Getting a replacement for X11 has been needed for a long time as the OSes and features keep needing something new to better work for how computers have advanced. And it isn’t something that many devs would want to take on given how easy it is to just use what is already known. Since Wayland has finally gotten to the point it is now, it is time for more devs to start learning/moving to the new thing to get attention to the stuff that they need. The hardest part is this in between period for users as it can and will cause random issues (like the ones you have seen). Stability is important, but Linux is great because there will always be distros and projects that keeping the old thing running well is the main objective. So we are in some great times for the new to be pushed hard so it can become the stable future needed.
Been trying to think of a term for this issue. It’s not quite chicken or egg. But both sides need the other side to incentivize them. If one gets going the other will follow, but they’re waiting for each other. Like some sort of collaborative standoff.
You will never be a real display server. You have no hardware cursors, you have no xrandr, you have no setxkbmap. You are a toy project twisted by Red Hat and GNOME into a crude mockery of X11’s perfection.
All the “validation” you get is two-faced and half-hearted. Behind your back people mock you. Your developers are disgusted and ashamed of you, your “users” laugh at your lack of features behind closed doors.
Linux users are utterly repulsed by you. Thousands of years of evolution have allowed them to sniff out defective software with incredible efficiency. Even Wayland sessions that “work” look uncanny and unnatural to a seasoned sysadmin. Your bizarre render loop is a dead giveaway. And even if you manage to get a drunk Arch user home with you, he’ll turn tail and bolt the second he gets a whiff of your high latency due to forced VSync.
You will never be happy. You wrench out a fake smile every single morning and tell yourself it’s going to be ok, but deep inside you feel the technical debt creeping up like a weed, ready to crush you under the unbearable weight.
Eventually it’ll be too much to bear - you’ll log into the GitLab instance, select the project, press Delete, and plunge it into the cold abyss. Your users will find the deletion notice, heartbroken but relieved that they no longer have to live with the unbearable shame and disappointment. They’ll remember you as the biggest failure of open source development, and every passerby for the rest of eternity will know a badly run project has failed there. Your code will decay and go to historical archives, and all that will remain of your legacy is a codebase that is unmistakably poorly written.
This is your fate. This is what you chose. There is no turning back.
There is one named neonmodem overdrive but it is buggy.
It really is buggy, iirc I couldn’t even get it to run properly.
It also support discourse forums any plan for this?
I really don’t have any plans (or even a name) for the app, as I’ve just started playing around with pythorhead yesterday. I just hoped posting a prototype or a proof of concept might spark a discussion and maybe inspire someone much more competent than me.
Easy… decoupling. You hit the pause button on your keyboard, it does not need to “know” (in code or compile time or at runtime) what your music player is, and it can still pause it. Similarly, you can write a new media player, and not have to convince 1000 different projects to support or implement your custom api. en.m.wikipedia.org/wiki/Enterprise_service_bus
There’s nothing about dbus that makes decoupling easier, you can do it just as well with sockets. Pipewire and pulse both speak the same protocol, and they both rely on sockets, not dbus. The vast majority of the apps on my system don’t know or care that they’re speaking with pipewire instead of pulse. Read my comment here lemmy.world/comment/6284859
Every change will bring it’s fair share of complainers, not much we can do about that. LILO to GRUB, SysV to systemd and now X11 to Wayland. No one is forcing your hand (unless you use a pre-packaged distro like Ubuntu/Fedora, in which case you go with whatever the distro provides), keep using X11 if you want stability, if you wanna dip your toes in bleeding-edge software and increase it’s userbase to show hardware manufacturers that their drivers need to be updated (I’m looking at you, NVIDIA) then feel free to mess around.
Eventually the day will come when Wayland apps will simply not launch on X11 and you’ll migrate too.
In case of Gnome it was addressed, just by different people. Gnome 2 continues to live on as MATE, so anyone who doesn't like Gnome 3 can use it instead.
I don’t understand why anyone ever expects a different outcome. They fork something that has quite some investment into the original version. How do they expect to keep up?
There were news about Ubuntu doing it too some time ago, maybe they realized it’s not feasible yet. I don’t follow their development as I don’t use those distros
Go tell Fedora that then lol. They want it gone to the point where Nate is telling users who want X to stay away on that post. Xwayland I believe will still be around though.
They’ll recant after their usage drops to a fraction. This move makes zero sense no matter how you look at it. As a generalist distro it’s too early to drop X.
If they want to become a niche distro whose only claim to fame is “we only pack Plasma 6”, big whoop, like there’s any shortage of that. What kind of distro defines itself by what it does not offer? And is that the kind of distro that Fedora aims to be?
lmfao Wayland is already ready for over 90% of use cases. Hell, GNOME has been wayland-default since twenty-fucking-sixteen if I remember my dates right. You’re overestimating the value X.Org provides.
It was not sysv to systemD, and it was forced (by making udev not work without it).
Other then nvidia, wayland is still missing some protocols (example: what virtual desktop you want your window to be on). But those protocols are (still) being worked on. And you will always be able to run x11 programs on wayland.
The advantages of wayland are a more direct path to hardware, and trowing away lots of code.
I’d say that’s already becoming the case in a few places. Hyprland isn’t just “Wayland good”, it’s “You should use Wayland good”.
Yes, I know the devs behind it act like pissants. That’s bad and I’m sorry for liking their software. I use Emacs too and RMS was kind of an asshole. Hell, I use Lemmy even though one of the devs has slighted me on more than one occasion.
… has gotten some help and is now a pretty well-adjusted human being, who still tells right wing trolls to go suck it, and still tells paid professionals that they should have known better when they should have known better, but in language that isn’t abusive.
I think you’re like 5 years behind on this. It’s true, just read up on it. Linus took time off after criticism for his language got too much. And he improved by a lot. You’ll find no more name calling directed at contributors after a certain date.
I daily drive Hyprland too, there are some shortcomings with how the mouse behaves with XWayland but I don’t think it’s a Hyprland issue and Gamescope remedies that problem so overall, it’s a great experience.
Look into history of object brokering in object oriented environments. I was around when KDE went from CORBA to DCOP to DBUS, but not involved in the decisions. Basically: object sharing between processes with security, type translation, and a few other things. In the Microsoft world, this was called “component object model” if my memory is correct.
Based on the various other descriptions of the DBUS features, I kept thinking “this sounds like a message passing model with a bit of CORBA hiding in there”. It’s got a bit of SLP and AMQP/MQTT to it, just on a local machine instead of a distributed network. It’s solving a lot of problems with service discovery, message passing structure, and separating transmission layer details from service API design. Raw sockets/pipes can always be used to pass data (it’s how DBUS does it!), but there’s additional problems of where to send the data and how to ensure data formatting that sockets/pipes do not have the capability of solving by design since they’re simple and foundational to how interprocess communication works in the kernel.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.