I’m a student, and I play games. So mostly I’m doing MS Office and Steam, but I’ve got a lot of random niche stuff I do too. Like I’m using Unity to develop a HoloLens app for a research lab, and I just use VSCode as my IDE. I use Bitwig Studio for audio production, Blender, Freetube, and some proprietary software from my University.
I guess I’m just wondering about compatibility issues I might face, and how to approach those. Are there just some programs that I won’t be able to use on Linux? I’ve heard about Wine, but it all feels conceptual. Like you ‘use’ wine to run windows programs but what does that mean? Do I run it like a VM? But it’s not an emulator?
I’m used to going to the internet, finding an .exe, and installing programs. But Linux has a package manager that you should do that through instead? But I’ve also seen a bunch of download links for Linux software online, so is there a difference in downloading something from the internet and installing a ‘Linux’ version of it, or installing that through a package manager?
Sorry I’m all over the place, i think my brain is a little scattered trying to figure everything out at once haha
you wont be able to use ms office, so either use alternatives or the web version(or through a vm)
for most software you want to use the packages provided by your distribution maintainers, as that removes the need to deal with conflicts, often provides some sane defaults and makes it so that for the most part you only have to trust the team of maintainers rather than every software developer in the world.
also you wont be able to play valo and some other shooters, though eac and battleye are both supported and besides native and wine/proton support u can play most games on kvm passthrough vms with little performance loss
No worries, it’s a lot of details to take in having never been part of it. The thing about the open source world is that there’s no central authority figure to say “this is what we’re doing, stop doing that other stuff”. So instead, anyone can do anything without consideration for what else is out there.
So yeah, package managers are one way to install software, there are many different package managers out there, and virtually every distro ships with the one that fits their design philosophy best. Package managers tend to point to a set of repositories (servers full of packages) that are managed by your distro maintainers. Depending on the package manager, a “package” may be a pre-built binary, or it might just reference some source code and scripts to build it. Either way, the purpose is to make it easy to install packages that someone has theoretically taken a look at and given a thumbs up to, indicating that it should work on your distro, in combination with the other packages in the repo (theoretically).
But not every single binary out there has been inspected by every distro maintainer. There are often licenses that prevent them from re-hosting proprietary binaries on their servers, and even if the license is permissive, it’s not uncommon for maintainers to disallow packages that aren’t open source. So ex. Discord has a Linux binary you can download and use, but it’s not commonly served from a package manager.
“Wine Is Not an Emulator” because it’s not emulating hardware. At the end of the day, windows and Linux are both running on your x86-64 CPU. In theory you should be able to point the Program Counter at the first instruction in a binary, and the CPU won’t care which OS it’s running on…until it tries to make a system call, or jump to a windows-specific dll. Wine basically tries to create an environment so that when a binary tries to do something that is normally only offered by the windows runtimes, there is code loaded to do what it expects.
These days, I recommend trying out Bottles to run arbitrary windows apps. It’s user-friendly, you create “containers” for specific windows apps, and it uses wine under the hood.
And then you have things like “flatpack” which are kind of like package managers where the package is a bottle/container, but the software it runs could be for any platform (Linux or windows). There are pros and cons to this (pros usually being stability, cons usually relating to the size of the containers on disk).
There are people who are adamantly for/against each thing, which is why distros exist in the first place. That’s just how the open source world works. I recommend finding something that works for you and not feeling obligated to worry about the 10 other ways people have gotten it working.
so is there a difference in downloading something from the internet and installing a ‘Linux’ version of it, or installing that through a package manager?
Installing with a package manager is easier, since it handles stuff for you. You’ll usually only download software from your browser if it’s not available in your distro’s package manager.
Package managers may have multiple repositories, these are like lists of packages, and may differ from distro to distro.
A good analogy is thinking of a package repo (short for repository) as a library, and the package manager a librarian helping you search for a book.
‘use’ wine to run windows programs but what does that mean? Do I run it like a VM? But it’s not an emulator?
It’s a compatibility layer, to put it simply (since I’m not a WINE expert) it converts Windows stuff to Linux stuff, instead of straight up running a Windows VM.
None of the comments here explain how WINE works, so allow me to elaborate a bit.
WINE is like a translator or a compatibility layer. When a Windows program tries to perform a function that would normally require Windows, WINE steps in and translates that request into something the Linux system can understand and process.
As you may know, Windows programs work by making API calls (eg using Win32 APIs) to operate and perform basic tasks. WINE takes these API calls and translates them to their Linux equivalents (POSIX calls, to be specific, which means Wine can run on several Unix-like systems). This way, when a program asks to say, open a file, or display something on the screen, WINE converts these requests into a form that Linux can execute.
WINE’s approach is about providing compatibility for user-level applications rather than replicating the internal workings of the Windows kernel. It includes various libraries and components that mimic the behavior of those in Windows. This helps in executing the Windows applications as if they are running in their native environment.
The core of it is NTDLL. NTDLL.dll is a core Windows library that provides low-level system functions to interact with the Windows NT kernel. In WINE, ntdll.dll is adapted to work with the Linux kernel instead.
Then you have the Win32 API libraries, providing the basic APIs that Windows applications use for functions like window management, text rendering, and system calls. Examples include user32.dll (for user-interface functions), gdi32.dll (for graphics device interface functions), and kernel32.dll (for basic system functions).
Shell32.dll for handling Windows Shell API functions related to file operations and the user interface.
DirectX Support, for running games and multimedia applications. WINE implements parts of DirectX, like Direct3D for 3D graphics, DirectDraw for 2D graphics, and DirectSound for sound processing. Note that WINE’s implementation converse Direct3D calls to OpenGL, whereas there are community projects like DXVK and VKD3D which translates these calls to Vulkan.
Finally there’s a Registry Implementation, so that applications that need to read or write to the registry can function correctly.
Of course, there’s a LOT more to it, the above is just an example of some key components. Basically Wine has reimplemented (coded from scratch) various libraries and executables that, on the outside, look like standard Windows dlls/exes, but internally they use POSIX APIs to talk to the Linux kernel and other POSIX components. This, along with the Syscall translations, bridges the gap between Windows programs and Linux.
Now naturally, this is neither a perfect, nor a complete implementation of Windows APIs; plus there are some things which Wine will never implement (such as ntoskrnl.exe), so not every program will work as expected - so check out the Wine AppDB for compatibility reports with various Windows apps.
Bitwig and Blender work great on Linux, as well as most games. MS Office and the proprietary apps will need a separate Windows install. Wine is a compatibility layer that essentially translates the Windows files into something that your Linux OS can use. It works great for some things, like games, but isnt recommended/doesn’t work for others, like Office or Adobe suite. Personally I’d recommend finding the alternatives for the programs you need on Windows and trying them out, while keeping the original programs in your Windows install. You can get used to the workflow of the new programs and decide if switching is a viable thing for you. And if not, hey now you’re comfortable with another set of programs just in case you need them in the future.
I love KDE a lot but if I’m honest, I dislike that they posted that… That wasn’t kind of them and it was rude to Microsoft!!! I wouldn’t insult them (“ditch Windows for good”), well, Microsoft has been using and including Linux too!! So both should be fine and friends.
"Cloud native" technology is double speak for your shit is running on other people's computers who will be tracking your use and selling it to pay for server upkeep and also maybe profit?
In this case it's referring to the fact that the OS is built upon the same containerization technology used on cloud platforms such as Kubernetes. As a marketing tool it's a bit buzzwordy, but it's not about running the core OS components outside of the physical machine here.
Both are incredibly stupid attempts to convince people they need something they don’t.
You all should look into a ‘blue ocean’ business strategy. Lots of shitty businessmen are constantly trying to push ‘new’ things and have a vested interest in convincing laymen of their necessity.
Needs are born from solving problems, not making them.
Oh and one additional question, is it recommended to uninstall all programs I had under Windows, so I won’t have to deal with "ghost files "? As to use windows helping me remove installation data? I have my laptop partitioned into C and D, where in D I have all my documents plus installed programs, C is solely for the OS.
Assuming I'm understanding you correctly (I think I am: "ghost files" would be files of the old filesystem read and kept by the new one?) No, that's unnecessary unless you have data you specifically want unrecoverable, in which case you'll want a 'file shredder' or srm type tool to handle that. Other than that you'll probably not be using any filesystem format Windows offers, so it also won't be recognizing any Windows files even if such a thing would otherwise be possible.
As for your main post, you seem to have the right idea. Steam recognizes that Windows games won't run natively on a Linux system and will either "automatically run with a compatibility tool (Steam Play)" (or something like that) or refuse to launch/install the thing until you configure it to run everything non-native with Proton by default (which is a checkbox in the normal settings menu, not anything weird or buried).
...Also sometimes it just launches Wine? At least for me? That's kinda weird, honestly, but I set up my systems in weird ways so that may just be a me problem 😅
Simply put: I think you'll be fine just not worrying about anything and going directly to your "boot from install/live media" step and not worrying about anything else unless there's a problem... at which point you come yell at us and we help you fix it ;P
Why not use a live ISO version of something and boot it from a USB, if you need a full set of network troubleshooting tools, the Kali Linux Everything ISO for example will definitely have everything.
I use Arch for all my computers, including my "critical" systems. I only do full upgrades when I know I have the time to troubleshoot something broken, but rarely need to do so.
More than this, I actually use Arch as the OS for thousands of computers for my work that end up in customer hands, who expect stability. I'm not sure at what point it stops being Arch, though - I pin the package repositories to internal mirrors with fixed package distributions from specific dates to control the software that goes to them, so it's not really rolling release anymore I guess - I control the releases and when updates go out.
Arch is what you make of it. My Arch project desktop pc is constantly shifting and breaking and needing attention as I continually improve it and play with things. My Arch laptop that runs my life and work and is the most important computer I own is a paragon of stability and perfect functioning.
Nope 😂 though, despite their decision obviously having nothing to do with me, I did find it to be somewhat flattering and a bit reassuring that the fine Valve engineers seemed to make similar decisions to me.
Definitely the third / middle left, but the bottom right definitely gets second place to me.
Not a major fan of too abstract art, and those are just both so serene.
I’ve been waiting for this desktop to release patiently. I can’t wait to try it. I have one question that I never got to ask anywhere, how is this going to work with the whole Qt/GTK apps? Are things going to look weird like they do on (mostly) Gnome and (sometimes) KDE Plasma?
We will attempt to automatically generate themes for common toolkits, but the desktop environment has no control over how the toolkit chooses to render itself or operate.
Fair enough. As long as the app goes with the dark/light theme and doesn’t look super tiny on hidpi screens, I personally wouldn’t really lose sleep over it. Will there be an HIG specific to cosmic for devs who want to make apps for it?
Yes, the libcosmic toolkit automates a decent chunk of the process to building an application with our interface guidelines. If building an application with the cosmic::Application trait. Which includes the header bar, navigation bar, and context drawer.
Thank you for answering all these questions. Last question, do you know when an alpha or a beta will be released? I want to test and help out with reporting. I have a spare laptop that I can use to test.
Please don’t automatically generate themes for third-party apps. If an application brings its own styles and icons, it results a weird mix of multiple styles.
If a user wants to style it themselves, they should be able to — at their own risk. But shipping (inherently broken) styles with a distro/DE misrepresents the appplication and creates unnecessary issues for the upstream developers.
Tell that to my eyes when your application only has a blinding light mode. Theming is an accessibility feature and should be prioritized as such.
It’s 2023. Every application should have a theme engine built-in. If not, that’s on the dev. Let’s not make a movement out of a lack of interest in providing support for accessibility.
You’re so silly. If the developer doesn’t want a themeable application, then either don’t use a themeable toolkit, or hardcode the theme so that the system theme is ignored.
I want that individual users are able to theme my app. I don’t want that distributors and DEs automatically theme my app and expect that it still works the same.
It’s a bit like websites: I’m absolutely fine if a user wants to inject some CSS in my website. On the other hand, if a browser manufacturer decided to inject CSS into all websites to customize their look, it would be a nightmare for web developers.
You don’t seem to realize that this is equivalent to that. The user already made the choice to install a desktop environment which generates themes. So if you make the choice to build an application with GTK, and you want users to be able to use system themes with it, then consider it done.
To argue otherwise would make you a hypocrite. It would mean that you don’t actually want users to use themes, so you take issue with desktop environments which make it easy to do so by default. So if you want people to be able to use themes, then you shouldn’t complain when people choose to use a desktop which enables that use case.
You’ll likely need something separate that’ll style both of these through the settings, similar to how you would config GTK themes on Plasma, or vice versa. I haven’t checked if they do this on their on yet, but it’ll probably be handled this way eventually. Out of the box, expect any Qt or GTK apps to look like their Breeze and Adwaita defaults look, unless you’ve already changed this on your system
It technically still does if you use their theming app “Gradience”. I use it currently on my laptop. Pretty nifty little app. It still doesn’t theme the shell (the panel, the password box… etc), but it does theme even flatpaks most of the time
Iirc Gradience punches a hole in the flatpak sandbox for xdg-config/gtk-4.0, which usually is in .config. This makes it work and isn’t a security problem.
Gnome Shell is unaffected because it doesn’t use GTK.
It uses a custom UI framework, St, using renderer primitives built into the compositor, mutter. Whereas COSMIC is using the same libcosmic library inside the compositor, applets, and desktop applications. Thanks due to our Smithay client toolkit being used to provide a renderer for iced which supports the Wayland layer shell protocol.
So that means themes will cover everything and things will be unified, unlike how the shell is always dark on gnome? (I know they’re working on a light mode).
Yes, this can already be seen when configuring a personal theme in the Desktop > Appearances page in COSMIC Settings. Compositor elements, applets, the login and lock screens, and COSMIC applications automatically adjust in realtime to the configuration changes.
Oh, I’m not rushing anyone. I’ve just been anticipating this DE for a long while. I’m very excited for it to be released. I’ve seen some previews and it looks freaking amazing.
No problem here with Opensuse slowroll (Sway WM) and a Realtek bluetootth radio, I’m using blueman for managing enabling/managing bluetooth connections.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.