I did a (Linux) thing

[overclockedmind]

around 2200 packages, XFCE minimal, it'd be smaller than this but I left Firefox ESR.

Started on a normal expert install of JUST XFCE in Debian Bookworm (12.)

The . files (in the user directory) set up the look. Dark theme, default, with the OS 9 menu layout,
*and a dock.*

Now considering this is a VM, how do I export it from Bookworm and get it to remember everything?

[tperry2x]

The easiest way, by far - rather then messing around with adding remastering tools to your distro (and extra package overheads you don't want), would be to instead clone it from the VM.

First, make a VM snapshot of the VM exactly how you want it, a saved state you can revert back to.

Download rescuezilla outside of the VM as an ISO.

Before you boot the VM, create a second blank hard drive - big enough to hold the entire clone. If you have the space, should be as big as the vm's HD.
Attach the blank drive to the VM as a secondary hard disk.

Attach the iso of rescuezilla to the VM, start the VM and boot into rescuezilla.

Choose backup

Select the drive to backup - the drive containing your distro.

Select the destination - your new secondary blank drive.

Name the clone something.

Next, and wait for clone to finish.

Once done, shutdown rescuezilla.

You now have a complete clone of your distro on that secondary drive image.

Dont detach that secondary drive from your VM yet.

Detach the rescuezilla iso from your VM, as you are done with that.

Boot into your VM as normal. You should be able to mount the second drive with the VM clone.

You need to get that cloned folder across to a real external drive now. Either plug in a usb drive big enough, or mount a shared folder and copy it out.

Shutdown your VM.

Burn the rescuezilla iso to cd / write to boot usb stick.

Copy that rescuezilla entire clone folder, whatever name you chose for the backup, onto an external plug in backup drive, big enough to hold it.

Find a suitable real test pc, that you don't mind wiping. Preferably with a similar hardware spec to your original system.

Boot from the real rescuezilla usb stick.
Plug in your real external drive containing your saved clonezilla system image.

Choose restore, select the source and destination - making sure to get these right.

Wait for restore to suceed.

Reboot & unplug drives.

You now have a complete clone of your VM on real hardware, without having to install any extra packages and keeping it lean. Plus you can restore using this hardware snapshot method at any time -should anything go wrong - or if your computer fails.

Once you have confirmed that's worked, you can restore your software VM to the software snapshot you created at the start, so that is back to the original spec of having one drive.

I've done this countless times, with verifiable proven success for any Linux distribution. Works for MacOS too by the way, and Windows - except with windows, don't put on a different PC otherwise you'll need to activate again.

Oh, and once you are happy that's worked - you can detach that secondary new large virtual drive from your VM and delete it to save space. You've still got the'real' / physical clone on that external drive after all.

Hope that makes sense.

[tperry2x]

If that doesn't make sense, I can probably do a post with illustrations - but it'll take me a while to put that guide together. Essentially though, the steps are as above.

[overclockedmind]

If that doesn't make sense, I can probably do a post with illustrations - but it'll take me a while to put that guide together. Essentially though, the steps are as above.

I'll get it. Don't do more work.

[overclockedmind]

If that doesn't make sense, I can probably do a post with illustrations - but it'll take me a while to put that guide together. Essentially though, the steps are as above.

I'll get it. Don't do more work.

That came out... standoffish. Sorry! I was simply saying I understood your directions to the letter. Please take no offence.

[overclockedmind]

The easiest way, by far - rather then messing around with adding remastering tools to your distro (and extra package overheads you don't want), would be to instead clone it from the VM.

First, make a VM snapshot of the VM exactly how you want it, a saved state you can revert back to.

Download rescuezilla outside of the VM as an ISO.

Before you boot the VM, create a second blank hard drive - big enough to hold the entire clone. If you have the space, should be as big as the vm's HD.
Attach the blank drive to the VM as a secondary hard disk.

Attach the iso of rescuezilla to the VM, start the VM and boot into rescuezilla.

Choose backup

Select the drive to backup - the drive containing your distro.

Select the destination - your new secondary blank drive.

Name the clone something.

Next, and wait for clone to finish.

Once done, shutdown rescuezilla.

You now have a complete clone of your distro on that secondary drive image.

Dont detach that secondary drive from your VM yet.

Detach the rescuezilla iso from your VM, as you are done with that.

Boot into your VM as normal. You should be able to mount the second drive with the VM clone.

You need to get that cloned folder across to a real external drive now. Either plug in a usb drive big enough, or mount a shared folder and copy it out.

Shutdown your VM.

Burn the rescuezilla iso to cd / write to boot usb stick.

Copy that rescuezilla entire clone folder, whatever name you chose for the backup, onto an external plug in backup drive, big enough to hold it.

Find a suitable real test pc, that you don't mind wiping. Preferably with a similar hardware spec to your original system.

Boot from the real rescuezilla usb stick.
Plug in your real external drive containing your saved clonezilla system image.

Choose restore, select the source and destination - making sure to get these right.

Wait for restore to suceed.

Reboot & unplug drives.

You now have a complete clone of your VM on real hardware, without having to install any extra packages and keeping it lean. Plus you can restore using this hardware snapshot method at any time -should anything go wrong - or if your computer fails.

Once you have confirmed that's worked, you can restore your software VM to the software snapshot you created at the start, so that is back to the original spec of having one drive.

I've done this countless times, with verifiable proven success for any Linux distribution. Works for MacOS too by the way, and Windows - except with windows, don't put on a different PC otherwise you'll need to activate again.

Oh, and once you are happy that's worked - you can detach that secondary new large virtual drive from your VM and delete it to save space. You've still got the'real' / physical clone on that external drive after all.

Hope that makes sense.

For OXT, do you see any reason to go to Ubuntu? Or should it... gasp... just work?

[tperry2x]

Debian (especially a plain Debian built from scratch) is a lot leaner and much more lightweight than Ubuntu. So, I'd stay with Debian if that's what you are using.

Depends on what window manager and desktop session you are using.

It also depends on what init system you are using. Again, if using a fairly unaltered Debian distro, I'd stick with that.

Xfce has a few inconsistencies and it fights for focus on the inspector and message box in OXT, but there's a few options in OXT Lite > Preferences > Compatibility to combat this.

It seems Ubuntu is more compatible with the Linux player widget, although I hope to eventually replace this - making it more compatible across other distros.

Even though Ubuntu is built on top of Debian, it has a lot of the packages in place already to allow OXT to tie in with the player widget. This is because the engine is intended to be compiled within a Ubuntu distro & related Debian set of packages.

OXT should run on pretty much most Debian based Linux distros, as long as it's 64-bit. There's not many I've found it won't run on. The only exception is Unix as it lacks compatible display libraries. (Even though MacOSX is built on Unix - but that is a different kettle-of-fish altogether).

I'm not sure about others like Arch, Fedora, Opensuse, Slackware, Puppy Linux, Haiku, TinyOS, Void, Manjaro... etc

[OpenXTalkPaul]

It seems Ubuntu is more compatible with the Linux player widget, although I hope to eventually replace this - making it more compatible across other distros.

Even though Ubuntu is built on top of Debian, it has a lot of the packages in place already to allow OXT to tie in with the player widget. This is because the engine is intended to be compiled within a Ubuntu distro & related Debian set of packages.

Do we know exactly what packages the engine needs in a distro for the player control to work properly?
Whatever they might be you should be able to add them to a Debian build.

GSteamer, I would think is the API we should be hooking into on Linux for media stuff? It seems to be commonly available part of that whole 'G' ecosystem.

For that matter do we know exactly the package dependency requirements for the CEF-based Browser Widget (until it that can be updated)? The limited documentation on that subject basically say if your distro can run Chrome then it should be good. But I'd like to have a list of exactly what libraries that means need to be available in the OS. This way they con be included in a sandboxed package/bottle/container like set-up (such as AppImage, Flatpack, etc.)

there's not many I've found it won't run on. The only exception is Unix as it lacks compatible display libraries. (Even though MacOSX is built on Unix - but that is a different kettle-of-fish altogether).

helloSystem is FreeBSD based and theoretically should be able to run it with it's Ubuntu compatibility overlay, but the AppImage would fail at the damn registration stack and haven't yet tried to rebuild the AppImage with your newer linux engine build.

I would bet there are BSD builds of Cairo and libSkia graphics, so theoretically the engine could be re-ported/compiled to run on BSD UNIXes. I think the Emscripten build of the engine uses a bit of WebAssembly port of SDL for rendering engine so I guess that proves the engine can work with SDL framework. It would be cool to have a BSD build of the latest version engine, it would be bringing the engine back full circle to where it began life as MetaCard.

[overclockedmind]

Debian (especially a plain Debian built from scratch) is a lot leaner and much more lightweight than Ubuntu. So, I'd stay with Debian if that's what you are using.

Depends on what window manager and desktop session you are using.

It also depends on what init system you are using. Again, if using a fairly unaltered Debian distro, I'd stick with that.

Xfce has a few inconsistencies and it fights for focus on the inspector and message box in OXT, but there's a few options in OXT Lite > Preferences > Compatibility to combat this.

It seems Ubuntu is more compatible with the Linux player widget, although I hope to eventually replace this - making it more compatible across other distros.

Even though Ubuntu is built on top of Debian, it has a lot of the packages in place already to allow OXT to tie in with the player widget. This is because the engine is intended to be compiled within a Ubuntu distro & related Debian set of packages.

OXT should run on pretty much most Debian based Linux distros, as long as it's 64-bit. There's not many I've found it won't run on. The only exception is Unix as it lacks compatible display libraries. (Even though MacOSX is built on Unix - but that is a different kettle-of-fish altogether).

I'm not sure about others like Arch, Fedora, Opensuse, Slackware, Puppy Linux, Haiku, TinyOS, Void, Manjaro... etc

Reply: I'm sticking with DebIan XFCE. If I have to go Ubuntu, I'll just apt-get list packages and transfer the same crap to Xubuntu.
So, I'm kind of at the turning point.

[overclockedmind]

I have a Debian Bookworm install with XFCE and like, 2000 packages. 64-bit

It'd be less, but I wanted to get SeaMonkey and I couldn't find it. Maybe it's a case of "hunt down the .deb"

I can cross-migrate to Xubuntu any time I want. But with 64-bit Debian 12, do I want?

Answer? No.

So here we are.

[overclockedmind]

I have a Debian Bookworm install with XFCE and like, 2000 packages. 64-bit

It'd be less, but I wanted to get SeaMonkey and I couldn't find it. Maybe it's a case of "hunt down the .deb"

I can cross-migrate to Xubuntu any time I want. But with 64-bit Debian 12, do I want?

Answer? No.

So here we are.

I can, CAN go to Xubuntu. I know how. I'm on 64-bit Debian current. I feel like I shouldn't have to.
tperry2x, this is the OS that gets installed on my main box. You advise me. Sorry to pull that kind of a stunt.

[tperry2x]

I can, CAN go to Xubuntu. I know how. I'm on 64-bit Debian current. I feel like I shouldn't have to.

I'd stay on Debian.

[overclockedmind]

I can, CAN go to Xubuntu. I know how. I'm on 64-bit Debian current. I feel like I shouldn't have to.

I'd stay on Debian.

YAY! Hehe.

[overclockedmind]

Minus what was once called xfce-global-menu in Ubuntu, it's pretty much the layout of 9 and X. Think Rhapsody DR2 without global menus.

I still wanna give them/me a chance at a browser that packs more punch per MB. I'm not arguing against Firefox ESR, but for instance SeaMonkey offers Web, mail, and IRC and still probably "weighs" less.

Yes, I know I could just ftp into ftp.mozilla.org anonymous/user@domain.org and get whatever I want, I'm just seeing (correct: I am NOT) SeaMonkey in the Debian repos...

Any thoughts? I like my per-window menus (just personal preference) but like I said, put the global menu bar back and it's... well, it's brand-a** new Rhapsody, essentially.

[tperry2x]

Could you not add seamonkey from a deb (assuming you want the US version with this link), or the download page if you don't.

Getting the globalmenu working might be more of a challenge. Link here to someone else's article I found.

By the way, I'm not sure how OXT works with globalmenu either

[overclockedmind]

Could you not add seamonkey from a deb (assuming you want the US version with this link), or the download page if you don't.

Getting the globalmenu working might be more of a challenge. Link here to someone else's article I found.

By the way, I'm not sure how OXT works with globalmenu either

An honest, appreciated answer.

[tperry2x]

I just tried it:

Screenshot at 2024-04-21 12-28-56.png (5.41 KiB) Viewed 69 times

Does indeed give me a globalmenu

Screenshot at 2024-04-21 12-32-38.png (13.01 KiB) Viewed 69 times

Short answer, not implemented in OXT:

Screenshot at 2024-04-21 12-33-12.png (29.02 KiB) Viewed 69 times