Skip Navigation

-> @jrgd@lemmy.zip

@ jrgd @lemm.ee

Posts
7
Comments
142
Joined
2 yr. ago

  • I just did some testing in the past hour or so and did a portable install from scratch using the Fedora Workstation 39 iso. I'm not exactly sure what your hardware detection issue would have been, but I can say that Anaconda could detect both a USB flash drive and an external hard drive I had plugged in.

    Going with the USB flash drive, I did skip using the automatic partitioning and went for using blivet to do my work. I did format the drive beforehand as I have always had issues with that drive properly accepting various partitioning commands (the installer no exception as tested). I did reserve a partition for a shared storage filesystem, but didn't actually give it a filesystem here.

    In blivet, here is a sample of the kind of partition schema I was talking about (something that might be helpful to OP or anyone else that wants to try this setup):

    I was able to then complete the install as normal and boot into the finished USB drive. I noted a small non-fatal complaint from grub on boot, but I imagine this is fixed with updating the system. All systemd units boot without failure and I am able to get the system working with minimal issue. The only real issue I could note is that the installation is very sluggish (due to it being on a flash drive rather than an external ssd or some other more suitable media). After booting, I then opened Disks and added the missing exfat (or NTFS) filesystem I reserved a partition for. The reason I didn't do this in blivet during install is because the option doesn't actually exist to make an exfat fs in the tool.

    Hopefully, this comment is helpful toward getting such a setup working.

    EDIT:

    Something I did notice with GRUB on Fedora Workstation 39 is that by default, the menu will not show unless pressing escape on boot. There is a useful AskUbuntu post that explains in detail how to access the grub menu and how to change it to behave in a better fashion for a multiboot system.

  • Ah, that would put a bit of complication into things. If you want to actually accomplish this though, you should largely start with the same steps as a standard system install, using a second USB flash drive to write the distro onto the external SSD, leaving enough space to build the rest of the partitions you need. If you intend to make a Windows-shared partition (exfat, fat32, or NTFS), it is probably best to put that partition either first or just behind the EFI partition so that Windows systems won't have a hard time finding it. Exfat or NTFS would be a better choice for this type of partition.

    I would still generally recommend keeping the live distros on a separate bootable drive, but you can size and reserve dummy partitions after the rest of your normal dual-boot installs and shared data partitions for live installers to overwrite. There is likely going to be some experimentation with getting the OS bootloader (such as on GRUB provided by Fedora in this case) to pick them up and add them as boot entries. You should (depending on the live image) be able to dd write them to the ending partitions reserved for the image for as long as the partition is sized equal or larger than the ISO image's size (it's best to give at least a few blocks of oversize on the partition when writing ISO's directly).

    Edit: In a proper Fedora install, you should almost never need to disable selinux or set it to permissive unless you know why you don't want it.

  • For the longest time reading this post, I didn't catch that you were setting up a simple dual boot for an internal SSD and thought with using tools like Ventoy you were making a multiboot portable install.

    You are obscenely overcomplicating this. Your current approach is almost completely wrong to getting a functional multiboot system that passes secure boot and everything else.

    Quite literally, bootstrapping from windows can use Rufus or ventoy on a USB stick to dump the ISOs on. Then boot into bios from the USB EFI entry. From there, simply install Fedora (no VM necessary). You'll get Fedora installed in a GPT/EFI configuration (if you formatted your drive for install). If doing manual partitioning to leave space or do other configurations, format the drive to GPT. If multibooting, you may want to expand your EFI partition beyond 512MiB for multiple distros.

    For other Linux OS to install alongside, you can then install them in the free space. Another comment mentioned to not install a bootloader on the secondary OS(es), which is generally a good idea.

    For Tails, it is not meant to be installed on an SSD. It is best to use it on a flash drive.

    Overall, a majority of your issues stem from the following:

    • trying to use live distro images as an actual OS install
    • using Ventoy as your bootloader
    • using legacy MBR partition tables instead of GPT without expressed need for them
    • Using virtualbox in general to provision bare metal hardware (changes need to be made in your VM software of choice to get EFI booting to work)

    I'd argue your conclusion of people not switching to Linux because you found it too hard is almost entirely not because of any issue on Linux, but the factors you wedged yourself into on a modern x86 PC due to your methods in accomplishing your goal.

  • The username release is quite recent for those not participating in beta versions of Signal.

  • Could you elaborate on this? As someone who uses SystemD extensively on workstations and servers for spawning and managing both system-level and user-level services, I do find minimal issues overall with SystemD minus some certain functionalities such as socket spawning/respawning.

    Of course some of default SystemD's housekeeping services do suck and I replace them with others. I would like to see the ability to just remove those services outright from my systems as separate packages since they do remain useless, but it isn't that big of an issue.

  • This is render offloading, not GPU switching. GPU switching implies switching the primary rendering device (the one power the displays) entirely rather than rendering on a separate GPU and copying the output to the primary.

  • I'm glad I am not the only one who calls my little ASUS netbook craptop. Kinda flimsy and definitely underpowered, but a perfect little device to run basic applications and terminal applications on a minimal window manager.

  • Before going any further to adjust your Z offset and other factors to tune for better bed adhesion, you should probably adjust your bed to actually be level as well as ensure (seeing that you only have one z lead screw?) that the X axis frame isn't sagging on the side not containing your Z lead screw. Once you've got those factors sorted out, you should check your probe repeatability and then set your Z offset accordingly.

    Bed adhesion even with proper, clean first layers can be a pain depending on the bed surface, material being printed, how clean the bed is of oils and other contaminants, how hot the material is being extruded, and how hot the bed is among other factors. While using a bed mesh will greatly help to account for off-zero unevenness in your bed surface, you really shouldn't use it to compensate for uneven bed leveling (especially when it looks like you are nearing more than 0.5 mm in unevenness).

    To diagnose other print issues, it will be helpful to see a picture showcasing the problems described in a failed print.


    As a side note, it is somewhat difficult to read your Klipper config file without using view source as it is being markdown formatted. You can negate it by using three graves on the lines above and below it so that it is wrapped in a 'code block' and isn't formatted.

    Some code  eeeee  fffff

    Turns into

     
        
    Some code
      eeeee
      fffff
    
      
  • As the original issues over on MySQL forums suggested, using DBeaver or other similar software rather than SQL Workbench is the best option. You unfortunately seem to be locked into using a keychain solution if you want to use SQL Workbench.

  • Perhaps it is possible that multiple issues are involved? Looking back at other issues with SQL Workbench causing DBus failures due to missing DBus endpoints could include the fact that SQL Workbench seems to rely on a keyring (be it Gnome Keyring or KDE Wallet). In an issue posted from 2022, SQL Workbench outright fails to connect to DBs in the same manner described if the keyring application isn't running. It might be worth using KWalletManager to check through your KDE keyring to see if SQL Workbench has been attempting to store and resolve database passwords through your keyring, which won't be running by default in a plain i3 session.

  • Traditionally, one using a "from-scratch" Linux install might start in a console TTY and then use the startx command to start X.org and other applications alongside it (including the window manager like i3). This is often done through the .xinitrc file. In your case, it's likely that you aren't using such a method, and rather using a display manager (most likely sddm since you are using KDE Plasma) to launch your user session (a bit of an oversight on my part, my bad). When not having some kind of pre-launch file or some other service list to launch everything surrounding your desktop, you might have to rely on your window manager to ensure secondary processes are launched. I do believe sddm can be configured to allow for additional processes to be launched, but I'll point you in the direction of doing it from i3's config files as it's quite simple to do.

    Within your i3 config file, you can add exec entries into it. Typically exec entries are meant to be used with bindsym to launch things with a keybind, but you can use exec entries on their own line to launch applications when the configuration file is read (on startup). For instance, you could add the line exec --no-startup-id "/usr/lib/polkit-kde-authentication-agent-1 &" in order to launch KDE's polkit authentication agent with your i3 instance, at which point applications (like SQL Workbench) should be able to make use of. As usual, changing your i3 config does require restarting your session for changes to take effect.

  • So you executed KDE's auth agent in a terminal and then ran the mysql service through the same terminal and everything worked? If so, that's good. I believe the only thing missing to getting SQL Workbench working is by having your authorization agent of choice launched in your i3 .xinitrc file. That way it should initialize any environment variables for your full graphical session rather just for a single terminal.

  • Just a wild guess, but does your i3 setup have Polkit setup fully like it would be in KDE? The "the name is not activatable" is a string typically stemming from DBus. Especially for potential cross-user services that may require various permission sets, polkit is often utilized to bridge what is necessary. If you don't have an authentication agent setup for your i3 desktop, you should probably set one up, even if it is something basic like xfce's or lxqt's.

  • User-Centric Innovation: Unveiling the Industry-Leading Battery Life

    We know how a smartwatch becomes integral to its wearer's life, and battery life can't be a concern. That's why we went back to the drawing board, driven by community feedback, to ensure the OnePlus Watch 2 delivers an exceptional user experience. With up to 100-hour battery life in full Smart Mode, it sets a new industry standard, ensuring that your watch keeps pace with your life, uninterrupted.

    Really impressive how OnePlus is touting a relatively mediocre 4-day (at best) battery life on a smartwatch as something exceptional or something that they (falsely) claim as industry-leading. Maybe it is good by typical WearOS device standards, but is by no means top of the line for the smartwatch industry.

  • In general, Microsoft doesn't support many filesystem formats at all. In the same way you shouldn't attempt to cross-run a steam library from Windows on Linux, you really shouldn't do from Linux to Windows. It's in part due to how permissions, execution flags, filesystem case sensitivity, file metadata, is interpreted by Windows applications vs. Unix-like applications. There will be issues going either way when using foreign filesystems in complex tasks.

    While it should be expected that the files will have the same contents where they are actually the same (i.e. a Proton game will be the same as a Windows game as it comes from the same steam depot), there is a good chance that translation of interpretation isn't to be 1:1 on either side. Furthermore with using Steam libraries, Steam includes additional data beyond just the game files, which is likely why they are invalidated. A significant portion of visible cross-os portability issues is due to many applications like Steam using OS-specific file structures. More than likely Steam is going to intentionally make the library metadata not fully compatible between Linux and Windows Steam and force validation before launch because there is a good chance the games aren't even compatible builds or otherwise have additional compatibility content dragged along (such as Proton WINE prefixes that are to be completely ignored when launching from actual Windows or having additional libraries, modded executable binaries that have platform-oriented patches).

    If you seriously want to run a cross-share of a Steam Library between Linux and Windows, you should really utilize Steam Cloud save. If you want to "deduplicate" your games, your best bet would be if you can open the foreign fs and have a compatible copy of the game, to simply clone the game files to the current filesystem and remove from remote rather than attempt to force a multi-os single-partition shared library. You are less likely to destroy your Steam library if you treat the actual libraries separate, but move the games like they were downloaded externally. Barring being able to do that, just don't cross-share games. Simply reboot into the OS that has the game you want to play instead.

  • One can comfortably use NTFS to read and write files on modern Linux distributions, but NTFS in general is not very suitable for running applications on or using for long-term usage between a dual-boot. Windows can and will often lock up NTFS partitions whenever it decides to hibernate rather than shutdown or sometimes suspend. NTFS while not being the greatest FS in general will also have worse performance on Linux than Windows. You can totally keep data stores on a Linux system, though you won't be able to make use of many of the advanced features some Linux/BSD-oriented filesystems offer. You can totally keep your drives as they are now, though if you intend to make a full switch you should consider migrating your drives' data over to more Linux-oriented filesystems (be it Btrfs, Xfs, or Ext4 is your choice depending on the features you want). In short, NTFS works but lacks a lot of features and performance that a more suitable filesystem would offer.

  • I am not sure if jest, but you could always take a few seconds at protondb to see that yes, all of those games do in fact run on Linux. Forza in particular seems to have issues for some users, but everything else works with minimal hassle.

  • The desired alternative is not Matrix simply because privacy-conscious, open-source ecosystem vs. proprietary solution is not the goal. Matrix would still generally be terrible for support. What people want is publicly searchable content that is ideally indexed like a wiki. Many will happily settle for issue boards or even forums though. Discord has pathetic search capabilities in comparison to any search engine and has no way to properly and publicly backup information that is posted to the platform. With a website of any kind, one could clone the site for mirroring or simply get a web archive service to crawl relevant sections.

  • Not the same person, but I greatly enjoy my (now second) Pebble classic for several reasons, which I imagine some are shared between Starayo.

    • Always-on Display
    • Week-long battery life
    • High contrast display that can be read easily in low light as well as in direct sunlight
    • Simple notifications support, with quick canned replies
    • physical button navigation that make the watch easy to use without needing to look at it
    • Isn't obscenely large
    • quick launch application shortcuts from holding side buttons
    • simple media playback control that is responsive
    • Doesn't attempt to be another smartphone, but rather as a local companion to your existing smartphone (doesn't thrive on individual apps, but rather companion apps to complement smartphone usage)
    • Customizable and relatively simple to write applications and watchfaces for.

    Unfortunately for me, fossil's watches do not match up. Looking at the gen 6, still uses an ill-suited AMOLED display that is bound to have poor contrast in direct sunlight unless the brightness is cranked so far that it will blow through the battery. Even then, the average battery life on the gen 6 is atrocious compared to most Pebble models as many reports say it can make it through one day. I'm sure by now, WearOS devices have worked out some of the kinks to make them easier and faster to use, though I am not sold on needing a personal assistant in order to do basic tasks (as Fossil markets their gen 6 smartwatch; I do doubt that this is necessary for general function).

    Also, this might be controversial, but I personally feel that a device that has Bluetooth and is intended to communicate with a device that is often within ten feet of it really doesn't need to waste resources and probably become more of a privacy nightmare by including Wi-Fi, LTE, and other data communication methods (beside NFC). Furthermore, pretty much every WearOS device I have seen has had a struggle to keep battery life for more than a couple days, and everyone deems that devices that can should be praised for whatever reason. Seeing as my ancient smartwatch that does most of what these newer watches do yet can effortlessly hold a six day battery life at worst, I seriously question why newer watches that have so much compromise and are incredibly misguided as to what a complementary wearable should be are what are being developed. Not to mention that the Pebble classic on launch was $99 USD whereas one can easily find $400+ smartwatches that still have way too much compromise in comparison.

  • There are not many Android phones that actually let you flex the open source benefits of AOSP. Android as it is packaged on many devices is not open source, and nor are the devices willing to fully let you install what you want. Ironically some of the only choices you have with the highest degree of freedom are from google.