Quoting: Mar2ck

Quoting: audioboysYou know what's so funny about this? And, hey, I don't advocate piracy or anything, I bought all three games. But you know that's why gamers are mad. They pass around these installers like candy knowing they can just use them to install the full game no problem. Don't pretend that's not what this is about.

But here's the really funny thing: they could just as easily download a completed save file to completely circumvent all these pieces of content that are locked. You can literally just slide a single file into AppData and have every "online-only" gun and item in the game. Imagine being this low-agency lmao. Pirates, everyone.

"New user" posts obvious bait on GoL, in other news water is still wet :grin:

They're not wrong though. This is an example of the usual corporate crap where the pirates get to have it better than the legitimate, paying customers. Would it be so difficult for IO to have removed these online checks before they released their game on GOG and thus allow players to enjoy a truly DRM-free experience playing it, especially if these online checks were only there to serve a purpose that's long since become irrelevant due to the game being old? No it wouldn't.

Regarding GOG, I have to agree with the poster who called out their crappiness. I used to love their service, but nowadays I feel like they've been steadily going down the wrong path in more ways than one, from sloppy handling of releases, to neglecting Linux with Galaxy 2.0, to Galaxy 2.0 being half-finished crap anyway, to Cyberpunk 2077 being the blunder that it was (CDPR is GOG's parent company)... I hope they'll reverse gears before it's too late, but until then I can't say I'm enthusiastic about supporting them and buying my games from them anymore, even with the games being DRM-free (which is an admittedly priceless feature).

View this comment - View article - View full comments

This whole opt-in business sure sounds a bit annoying at first, but it's IMHO completely understandable: with native games, be it for Windows or macOS or Linux, it comes as a given that if you release your game for a given platform you consciously commit to support said platform in everything, including a properly working anti-cheat solution if your game needs to use one. And if you don't release your game for a platform then you just don't have to worry about it. The choice is in your hands.

Wine/Proton is a whole new ballgame though, in that it takes that choice off your hands and allows the users to run your game in a platform that you may not be able or willing to support, and quite possibly without you even knowing about it until trouble comes knocking. And if that trouble is non-existent in the case of a single player game, for an online competitive game it's a nightmare, because you can't have "illegal" players going around and possibly disrupting the game for the "legal" players by either cheating or by simply introducing bugs and unintended behaviors.

The only reason game companies haven't had to deal with this kind of trouble so far, even though Wine/Proton has been a thing for years, is that anti-cheat was incompatible and thus served as an obstacle for "illegal" players entering your online game. But now that it's finally compatible, if it had been made mandatory instead of opt-in then you'd suddenly need to choose between two options, one worse than the other: either you're forced to commit to supporting this new platform that you never even signed up for, with all the financial and organizational headaches this implies, or you don't support it and you let the new users do whatever they want unsupervised, which quite possibly means destroying your game.

In both cases you're f*cked as a business, and not only would it be be unethical on the part of the anti-cheat companies if they did such a thing, but I'd venture it could also very well be illegal and serve as a basis for game companies to take the anti-cheat companies to court. But even simply being unethical is a valid reason for making it opt-in. Not to mention the negative image this would create for Linux.

So anyway, first EAC and now BattlEye, Valve sure has delivered on its promises so far. Kudos to them.

View this comment - View article - View full comments

Quoting: GuestInteresting analogy that I disagree with. GNU/Linux never asked for a seat at the table - the focus was never originally on increasing market share. It dominated the server market by simply being better, and was made better by being open for anyone to tinker with and improve. It was far more accessible to those who had the skills and wanted to create something, so it never needed market share.

GNU/Linux doesn't need market share in order to succeed.

"GNU/Linux never asked for a seat at the table"?

"GNU/Linux doesn't need market share in order to succeed"?

You may have never asked for a seat at the table, but most of the big companies and contributors behind Linux nowadays (even Linus himself I'd dare say) certainly desire one. Also, I believe you're confusing Linux as a tech made by the knowledgeable few for those of us that use computers as a personal hobby/passion, with Linux as a product made for the masses that use computers as a tool.

In a nutshell: ever since Linux left nerd-space (servers and workstations) and entered user-space (games and desktop/productivity apps) there is no such thing as advancement based on merit alone anymore. There's also marketing, public relations, politics, bottom lines, user experience/satisfaction... the works.

Furthermore....and this gets a rise out of people every time, but I'm not meaning to. Everything that people are crediting Valve for, on a technical side, existed before Valve got involved. DXVK was not started by Valve. WINE was not started by Valve. Mesa drivers and the massive improvements to them was not started by Valve. I'm not making light of Valve's contributions, but instead pointing out that all of this would still have been done without Valve. Valve are the lucky ones that the work was open source and could be invested in to give them what they wanted.

I get what you're saying, after all it's not like Linux and Wine were invented by Valve, but:

DXVK was started by a guy who from day 1 adamantly refused donations and help from third-parties on his GitHub, until it was publicly announced that he was being funded and supported by Valve.

Wine was a fantastic foundation but an incomplete and crappy end-product that could barely handle old DX9 games, let alone DX11 (which was already some 10 years old), until DXVK, and later Proton with all its included middleware, came along and completely changed the game. I agree though that without Wine being readily available to serve as the foundation, we wouldn't have seen such great progress in so little time on the modern gaming front.

Mesa drivers' and Nvidia drivers improvements' are IMHO directly, at least in (a large) part, the result of Valve lobbying in favor of Linux/Proton and nowadays the Steam Deck. If not for that we'd probably still be living in the BSD stone age.

And even though you didn't mention them, further improvements like WMF support and anti-cheat integration will be the direct result of Valve working on/lobbying for them. Anti-cheat in particular is a great example of a tech that we wouldn't be able to implement on technical merit alone, without at least a modicum of marketing/PR, because the obstacle is not the technology itself but the politics around it. Same goes for other stuff like Nvidia's Shadowplay, which are part and parcel of the modern gaming experience; it's not only about the game itself nowadays, it's also about the extras, and you can't get these without market share and thus a "seat on the table".

What I do 100% agree on, though, is that Valve is equally (if not more) lucky that Linux & Wine were there when it needed them in order to take advantage of them. In the end, if this whole endeavor proves to be successful, we end-users will be getting our gaming fix, hooray; Valve on the other hand will be earning tens of millions per year. It's clearly of more benefit to them.

Quoting: AnzaBut large masses are not like that. Large masses use Linux because it's preinstalled on the device they bought.

And then they cry (with good reason) when they find out the device they bought is more useless to them than a door prop, because they want to actually use their device for their use cases, not admire it for its technological prowess. And we get to explain to them why their new and shiny computer can't play their new and shiny games (not "Windows games", games, period). Oh, but Linux runs great on servers! Now that's important to Average Joe out there, don't you think?

Of course this all is hypothetical, because large masses don't actually use Linux, they use Windows and Mac and Android and iOS.

Quoting: GuestTo turn things on their head: if you're such a fan on Windows games, why aren't you using Windows?

The answer is extremely simple: because we like Windows games, not Windows itself, and Proton has allowed us to finally ditch Windows while still being able to play Windows-only games. Do you really not comprehend how liberating that feels to someone who enjoys gaming but dislikes Windows?

View this comment - View article - View full comments

Quoting: Ehvis

Quoting: BielFPsSo if we get in a state where wine / proton can 1:1 with native DirectX, without the need to rely on Windows, then their only choice would be port / open source DirectX, or sabotage using patent protected components Media Foundation, which is the case with this game.

Or they release DX13 and we can start all over again. I'm with mirv on this one. Going for DX on proton as the basis for Linux gaming is just keeping Microsoft in control of the pc gaming ecosystem.

Quoting: Guest

Quoting: BielFPsMy point is something like Proton is worse for Microsoft than for Linux gaming, and what I think it really need to happen is Vulkan to become more mature and easier to develop, in a way that developers can rely on without the fear of causing problems they don't know how to fix.

I'm not really concerned with it being worse for Microsoft, so much as not good for GNU/Linux.

Microsoft is actually pretty good at documentation and developer help too. It's not really a problem for them to release something new and have developers pick it up - indeed, it's often a selling point. So it's not too difficult for them to introduce a Windows-only bit of middleware, or a subtle change to DirectX, and games no longer work through wine.

Microsoft is and will remain in control unless and until game companies have the incentive to use something other than DirectX for developing their games. And like it or not, as things stand now, that incentive can probably only come either by Vulkan proving to be 10x more performant than DirectX (unlikely) or by the Steam Deck succeeding and thus Proton and Linux catching the game companies' shareholders' attention. So right now our only hope to increase our chances is to achieve 100% compatibility with the dominant game development SDK, which would be DirectX.

As for MS introducing some change into DirectX, DXVK and VKD3D don't depend on the official DirectX SDK but rather re-implement it based on the public spec, so as long as the world is publicly notified about the change (which it will be if game developers are expected to actually develop games that work with this new version) there can no longer be a vendor lock-in. The only thing DirectX can have to its advantage compared to Proton is performance (even WMF and similar extras are already being implemented in Proton).

Quoting: Guest

Quoting: BielFPs

Quoting: GuestIt will, however, slow innovation and adaptability in GNU/Linux gaming.

Interesting, which one of those of those are being jeopardized by Proton?

Other than lacking of a more friendly and supported development environment on par with Visual Studio?

Lack of focus in areas that could keep games running across distros, kind of like containers (which haven't gained any traction yet for gaming)?

Lack of integration with desktop and features such as Twitch integration? (I like to shout out Hive Time here).

How about streaming from main server into the living room? If you think that's covered by Steam, think again.

Simple tweaks to drivers along the lines of what is seen from control panels available to Windows users? Sure, most of that is pretty crap, but ideas do come out of much of it.

GNU/Linux desktop has had virtual desktops for a very long time. I don't see many games taking advantage of that, or even trying to.

Anti-cheat mechanisms that don't rely upon kernel level access.

What about experimental driver features, API extensions? OpenGL had that for years. Vulkan has continued that. Not available with DirectX. Sparse texture volumes would never have existed without that, directly impacting games like Enemy Territory: Quake Wars, Rage, Rage 2, Doom 2016, Doom Eternal. Now granted they were all Windows games - but what would happen if you had a lot more people using OpenGL back then, and more using Vulkan now, on an OS where there are a whole heap more freedoms to experiment?

But no, apparently that's all insignificant and "Proton" is the way forward, just do whatever Microsoft dictate. That should get you started on something to think about.

--edit: and let's not forget about gametime, which came out of someone at Feral (at the time).

These all sound very nice, but you seem to be forgetting the simple fact that Linux is at best an afterthought for most game companies. No matter if you're in the right, you can't hope to dictate the market if you only control less than 1% of the market (and that's only if you include Proton-compatible games) and you can't hope to control more than 1% of the market if no one gives half a f*ck about you or your ideas or your needs (talking about Linux here).

It's like a poor Third World country in sub-Saharan Africa asking for voting rights in the UN security council, in order to promote a plan for peace and prosperity and Unicorns for the whole wide world. A noble cause, but what do you think would happen? I'll tell you what, same thing that would happen to Linux gaming if there were no Proton around. Again, like it or not, in the gaming world Linux is less than an afterthought for anyone that could potentially help it become something more than an afterthought... except Valve. We're freaking lucky we got Valve for free.

View this comment - View article - View full comments

Quoting: Ehvis

Quoting: NociferActually scratch that, the most annoying thing is that all these crowdfunding platforms like Fig are not subject to common law.

Actually, there is. Anything you pay for a crowd funding project is a donation that doesn't entitle you to anything in return. And people should really remember that before they open up their wallets.

Sure, but what I meant is that the law should change so these crowdfunding platforms become binding like actual contracts. As you said, you're currently not entitled to anything in return as they are considered "donations"; well, IMHO you should be entitled.

Quoting: whizse

Quoting: NociferWhich means that they've intentionally used tech that they know is neither portable to Linux and Mac (i.e. they'll need to replace all the WMF stuff in their code before they even think of porting) nor possible to be used with Proton in the meantime, which of course means no playing this on the Steam Deck. If this isn't a deliberate act of sabotaging a competitor, I don't know what it is.

Never ascribe to malice that which is adequately explained by incompetence. I'd be surprised if this was anything but the usual short shortsightedness that's ubiquitous in game development.

Wise words in most cases, but here we're talking about a company that a) has previously already developed games for Linux and Mac, and b) has just recently been bought by the very company that is both the biggest competitor to Linux and Mac and, as "luck" would have it, the creator and patent holder of the WMF tech.

Also, let's not forget that even if they're just incompetent as developers and they simply never bothered to take Proton into account (which they should have, as an absolute minimum of respect to their customers, as soon as they decided to not have the promised native Linux version out on day 1), this doesn't change the fact that WMF is a Windows-only tech and not portable to other OSes, so this would mean that they've known for a long time that in its planned final state (you probably don't add something like WMF as a last minute decision) their game is Windows-only and can't be published to Linux and Mac as is; so they've been lying to their customers all along that they've been developing all three versions in parallel.

View this comment - View article - View full comments

IMHO the absolutely most annoying thing here is not that they didn't deliver on their promise to have Linux and Mac support on launch day but that they've gone and used Media Foundation, which is widely known as one of the last remaining huge issues for Proton, all the more among game developers that have supposedly done at least some preliminary work/research on the Linux and Mac versions of their game and thus should know better.

Which means that they've intentionally used tech that they know is neither portable to Linux and Mac (i.e. they'll need to replace all the WMF stuff in their code before they even think of porting) nor possible to be used with Proton in the meantime, which of course means no playing this on the Steam Deck. If this isn't a deliberate act of sabotaging a competitor, I don't know what it is.

Way to go Tim; and you used to be one of my favorites in the industry. Also, way to go anyone who's still naive enough to believe that today's Microsoft is BFF with Linux.

Actually scratch that, the most annoying thing is that all these crowdfunding platforms like Fig are not subject to common law. In a fairer world this should qualify for a lawsuit against them on grounds of breaking their contract with their funders.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: NociferBut I don't see myself moving on anytime soon, because one thing is indisputable: passing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

That first point is actually quite disputable. You assume that the person doing all this stuff is fundamentally competent at technical stuff--no doubt because you yourself are. If they suck, they could go through all that and end up making themselves a wonky piece of crap Linux system. I mean, there's been plenty of lousy distros, and those are put together by people with pretensions to technical knowledge; I don't see why many users couldn't similarly do a poor job configuring their own system.

The learning part is fundamentally good . . . but for many, not an important enough good to repay the time spent. I'd be in that camp. The world is big and complicated and there are many, many things to know about. I can't possibly know about them all. There is not enough time. And it so happens that on my list of priorities of things to know about, any more than a pretty dashed basic understanding of the nuts-and-bolts of my computers' operating systems is quite far down, well past quite a few other things that I will also never take the time to learn.

Regarding the first point, touché. Re-reading what I wrote, I realize that I ended up seemingly painting Arch as some kind of special Linux system that's inherently better and more solid than the rest of the Linux ecosystem due to some kind of secret special sauce.

The point I was trying to make is more like this: Arch is potentially one of the most solid Linux systems you can have, exactly because you don't have to worry about random tweaks and/or misconfigurations by "technologically pretentious" third parties that could produce instability and/or undocumented behaviors that may result in messing up your system (i.e. the bane of most distros), due to the fact that your system is built by you.

The above comes with the caveats that a) this is valid only if you either already know what you're doing or you consciously treat the experience as a learning process, and b) if you know what you're doing, ALL Linux systems have the same potential for stability because you have the ability to tweak them yourself and reverse any unwanted changes.

That's why Arch is "one of the best" in my eyes: because a) due to its transparent DIY nature it give you the option to delve into the internals and treat the experience as a learning process, whereas most other distros provide you with an opaque system that you have no idea how it's built, and b) it gives you the potential to tailor it to your tastes right from the get-go instead of having to "debloat" your distro of choice post-install to bring it down to where you want it.

Which brings me to your second point: though of course I agree, that's not specific to Arch or Linux or computers in general but rather applies to every kind of skill or knowledge. As you say, there are more than many things one could learn, and not enough time or motivation for a single person to learn them all in one lifetime. So, the learning part comes with its own caveat: if you have an interest in learning more about how computers in general and Linux specifically work, then Arch is one of the best ways to go about it. If not, then of course Arch is not worth the trouble and you'd be better off using some other distro.

In my case technology and computers have always interested me, and before Arch I always hated the fact that I was using Linux but was not able to really tweak it or fix it (I'm the type who likes DIY in general, from fixing up a leaking faucet to maintaining a bike to building a backyard shed), so Arch was a natural next step. But of course while I was learning about Arch and Linux system administration, I postponed learning some other stuff that I will either have to learn later in my life than originally planned, or will never learn because they're too low on my To Do list. But, that's life priorities for you :)

Quoting: STiAT

Quoting: Nociferpassing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

Well, I was TU in Arch and used it 2003-2017. Besides that I'm software developer and know my way around well enough.

That said, I switched from having to know the system exactly to I actually just want it to work and do my work with it than working on my own system.

It's a matter of perspective I'd say. But since I do not want to waste my time on finding out which optional depends got added if something stops working after an upgrade... not worth my time.

And again, I mostly agree with the sentiment. Judging by that usage period I'm probably a bit younger than you, and I'm treading a similar vector: I'm also a software developer, which is why I originally loved the nuts and bolts approach of Linux and later of Arch, but nowadays I know enough about Linux and computers to satisfy my thirst, and also my work priorities have shifted to other, non-tech ventures (got bored with computers in general tbh), so I'm very much in favor of having a system that gets out of my way and allows me to simply do my work.

This means that, as I said in my previous comment, at some point down the road I'll probably switch to a more curated distro. But I can't overlook the fact that this is me speaking only after I've already cut my teeth on Arch and accumulated enough knowledge and experience with it to confidently know I'm able to administer any distro out there and tailor it to my requirements, even if it's not as DIY as Arch. In other words, probably like you're also doing with Solus.

I also can't overlook the fact that this only after Flatpak and Snap and Appimage (not to mention containers) have risen in prevalence and efficiency, which means that the Arch advantage of a rolling system + AUR is beginning to diminish in favor of a stable system + Flatpak/Snap/Appimage/container userland.

In other words, me using Arch nowadays is more a matter of momentum, yes, but switching from it will not so much be a result of Arch being especially tedious for me to maintain (e.g., as far as optional dependencies are concerned, pacman and the various AUR helpers, and even the GUI tools like Manjaro's Pamac, do inform you of any optional dependencies of any packages you're installing or updating) as it will be a result of other distros having caught up with it (again, very much due to Flatpak - I would never be able to go back to a fixed release distro as far as userland is concerned).

But again, I do understand the sentiment.

View this comment - View article - View full comments

Quoting: BielFPs

Quoting: Nocifer- the transparent filesystem compression (everything is configurably compressed on the fly, so you get less used space for the exact same contents)

Wouldn't this have impact on performance? Since it sounds like the file would need to be "decompressed" before its use.

I mean it sounds very good for storage disks, but I have doubts with something dynamic like games (of course I'm not expert on this subject)

Well, the thing is that modern games already work by loading the whole bunch of stuff they use into memory and using it from there, which is why most all games you see today come with their resources compressed into a small number of huge binary chunks instead of lots of separate files like it used to be. This is because your CPU and RAM are both orders of magnitude faster at I/O than even the fastest SSD, so it's much quicker to load these huge binary files into the RAM and decompress their contents on the fly than it is to load lots of smaller separate files from the disk as and when the game needs them. That's part of why modern games require so much more memory than before, it's because they're trying to eliminate the slowest part of your system from the equation, which would be the HDD (don't forget that consoles up to now only had HDDs, and most modern games are optimized for consoles first).

So the same is true for btrfs compression: in general, on an average modern system the CPU and RAM will be able to compress/decompress files much faster than they could be written on or read from the disk, so there will be no perceptible overhead. And there is also the "configurable" part, which allows you to configure the compression level and/or algorithm according to your specific needs and system capabilities. E.g., on a hard disk meant for storage you could increase the compression (because the speeds on HDDs are lower by definition so the overhead can also be larger without impacting performance) and on an SSD meant for everyday use you could decrease it to get higher speeds.

There's lots of benchmarks about this online, but a quick test on my system (with ZSTD level 3 compression) gives me the following:

Spoiler, click me

$ btrfs filesystem usage /
    Device size:                 465.26GiB
    Used:                        285.38GiB
    Free (estimated):            179.52GiB      (min: 179.52GiB))
    Free (statfs, df):           179.52GiB


$ dd if=/dev/zero of=benchmark bs=1M count=20000 && sync
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 8,64825 s, 2,4 GB/s


$ dd if=benchmark of=/dev/zero bs=1M count=20000 && sync 
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB, 20 GiB) copied, 7,38954 s, 2,8 GB/s


$ btrfs filesystem usage /
    Device size:                 465.26GiB
    Used:                        286.02GiB
    Free (estimated):            178.91GiB      (min: 178.91GiB)
    Free (statfs, df):           178.91GiB


$ compsize benchmark                               
Processed 1 file, 160169 regular extents (160169 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL        3%      625M          19G          19G       
zstd         3%      625M          19G          19G  


And as a bonus:

$ compsize /usr
Processed 409197 files, 268591 regular extents (274089 refs), 198321 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       49%      7.6G          15G          16G       
none       100%      3.6G         3.6G         3.7G       
zstd        34%      4.0G          11G          12G

Take these test results with as many grains of salt as you want, but I do believe they show that the compression more than benefits me and my system :)

View this comment - View article - View full comments

Quoting: STiATWhile I love Arch (was TU there for some years), and later switched to Manjaro, my real issue with it is actually the KISS approach and their approach to optional depends.

Like, if you require a package so MTP and Bluetooth actually work with phones and results in cryptic errors if they are not, they should be a dependency.

Since they are not required compile time, Arch will put them optional and you've to search why certain functions in your desktop don't work as expected. As Manjaro pulls from arch, you have the same issue there.

And that drove me away from it, though, my love for its general approach and flexibility I really like, it's not what I prefer on a daily base.

So I'm on Solus since 2017, and did not even try other distros since then. Though, Solus is rough around the edges too with snap and flatpak support not being in the solus-sc and similar, it's a much more curated approach to a desktop for daily used.

Which is not the intention of Arch, and that's fine.

Actually, what you describe was going to be my second example of where Arch lacks somewhat for me, but I deleted it in order to keep my comment from becoming too long:

"Another example is the concept of optional dependencies: e.g., in order to see WebP thumbnails in KDE's Dolphin one must know to install qt5-imageformats, which is an optional dependency not of Dolphin itself but rather of Dolphin's dependency kio-extras, and also is part of the Qt5 group but not of the kf5 group, so one can't even get it by bulk-installing the KDE components; rather, they must manually check the optional dependencies of this specific KDE package, find out about this optional dependency, and then manually install the required package to satisfy it.

At first this irked me to no end ("but how can such major functionality be hidden away in an unrelated optional dependency!"), until I realized that it kind of made sense, because Arch is very much a DIY Linux OS - with the exception of the kernel and the core userspace utilities, this isn't some preassembled ready-to-use distro but rather a collection of components that you can mix and match however you like to basically create your own custom distro."

And there is your answer: despite being a mainstream distro, Arch has more things in common with the likes of Gentoo and LFS than with the likes of Fedora or Ubuntu. The user is expected to actively participate in the building of their system, which translates into manually checking and verifying non-essential packages, manually setting things up (there is no "sane defaults" because you're building things from the ground up), manually enabling/configuring services (contrast this with how a distro like e.g. Fedora does it, where the package manager is expected to take care of restarting services on its own, per the Phoronix article from just the other day, whereas on Arch such practice is generally frowned upon), etc.

Anyway, all of the above is just a convoluted way to say that I do get what irks you about Arch's KISS attitude, to the point that if I ever decide to move on from Arch, this will be what will have motivated me to do so as well. But I don't see myself moving on anytime soon, because one thing is indisputable: passing through all these hurdles (which is really required only once, i.e. on first install) will end up with you having built one of the best and most solid Linux systems you can get, and with the added bonus that during the process you will have acquired a more than vague idea of how this system actually works, which means you'll have made your first step(s) towards transitioning from computer n00b to an actual computer user :)

Quoting: BielFPs

Quoting: NociferYeah, btrfs is certainly one of the best unknown gems of the Linux world, and implementing first-class support for it is certainly welcome. I expect and hope that now with Valve selecting it as the filesystem for the Steam Deck, more people will get to install it on their own systems (in an attempt to enjoy the full benefit of Valve's efforts on Linux gaming, which will probably include btrfs features like reflinks) and find out just how awesome it is.

What are the advantages of btrfs over ext4 (despite the RAID ones)? Any kind of performance improvements?

For me it's:

- the transparent filesystem compression (everything is configurably compressed on the fly, so you get less used space for the exact same contents)

- the integrated volume manager (I no longer need to partition my hard disk into /boot, /home, / or whatever else and then juggle with the free space between them; I just format the whole thing as one single btrfs partition, create a separate subvolume for each former partition, and there you have it: totally separate partitions in every sense of the term, but sharing the whole of the disk space between them as they/you see fit; it's like LVM on steroids but more performant, because it's tightly integrated with the filesystem itself, and also without the many usability headaches that come with LVM)

- the snapshots (the ability to instantly "capture" the state of a subvolume and store it as a backup, into which you can either return to should things go south - like the System Restore functionality in Windows but actually working - or treat it as a normal backup and selectively restore files from it when you need to)

- the integrated RAID support (the RAID 5/6 writing hole does not prevent you from using RAID 0 or 1, which AFAIK both work like a charm - never tried them myself though because my mdadm array is impossible to rebuild unless I spend a fortune on additional hard disks)

View this comment - View article - View full comments

Quoting: LinuxScouserManjaro was my first taste of what it was like on an Arch based distro. I still haven't quite figured out how to run pure Arch as setting up my various installed drives and partitions purely by command line still terrifies me to this day.

Fun fact: most long-time Arch users are equally terrified of editing partitions by command line to this day :)

But if that is the only thing preventing you from using Arch, there is a very easy solution: fire up a live CD of e.g. Manjaro, use a GUI tool like Gparted to partition your disk, then boot the Arch ISO and install Arch on your already partitioned disk. No need for the command line at all.

On the other hand there is nothing inherently bad about using Arch-derivatives instead of "pure" Arch, as long as they don't do unnecessary adjustments to how the base system works (e.g. like Manjaro and its update policy), so if you're good with Endeavour or Archcraft then you might as well stick with them.

Quoting: lectrodeIMHO, the enhanced installer support for Btrfs is by far the biggest new feature to come to the manjaro iso. The automatic setup of btrfs subvolumes for your main partitions (no more worrying about balancing the size of the root and home partitions separately), as well as the automatic snapshots whenever you update are a huge benefit to newcomers to linux.

If you need to boot into an earlier snapshot of the system, you have options right there in the grub menu on startup. No manual setup required, and all your files, settings, preferences, etc are exactly the way you left them, in the same amount of time it takes to reboot. How cool is that?

Granted, I've never run into breakage issues because I watch the update announcement threads for potential issues (and follow the rare but necessary manual update steps, like merging pacnew files), but this provides a very robust safety net for anyone worried about installing updates on an Arch-based system, right out of the box.

Yeah, btrfs is certainly one of the best unknown gems of the Linux world, and implementing first-class support for it is certainly welcome. I expect and hope that now with Valve selecting it as the filesystem for the Steam Deck, more people will get to install it on their own systems (in an attempt to enjoy the full benefit of Valve's efforts on Linux gaming, which will probably include btrfs features like reflinks) and find out just how awesome it is.

I call it an "unknown gem" because many/most people nowadays usually dismiss it due to the infamous RAID 5/6 "writing hole", without realizing that a) if you don't use RAID 5/6 this is nothing to worry about, and b) btrfs in every other respect absolutely ROCKS, so much so that IMHO it should be the major Linux filesystem in place of ext4. The only thing it lacks for me is casefold support.

Quoting: KymusI ran Ubuntu for nearly 15 years and was extremely cautious when jumping to Manjaro at a friend's suggestion, but with the AUR, I've surprisingly found it to be an easier and beer experience overall than Ubuntu (which broke on me when installing new versions 75% or more of the time, for some strange reason).

As a former Ubuntu user (until 2013 IIRC) I can sympathize. After the struggle that is PPAs and backports and release upgrades every 6 months, having a light and transparent system where you install it once and then it gradually gets updated piece by piece to the latest version, and where you can have access to everything you may need via the AUR (either using premade packages or making one on your own, the latter being its greatest strength) is definitely a great step towards achieving computing piece of mind. Also, apt vs pacman >.>

On the other hand, some people might miss the hand-holding they can enjoy by using other, more centrally managed distros. Arch is more like a commune; nobody is gonna force you to do anything (unless it's about cleaning duties, but thankfully Arch is only a virtual commune :P) but you're also not going to be getting any new and shiny changes automagically unless you educate yourself about them. Just the first example among many that come to mind, rootless Xorg: back when it became a thing (~2018 or so?) other distros (eventually) came with it already preconfigured, while on Arch you had to know about it and enable it by hand-editing an obscure (by average user standards) configuration file.

Arch is certainly not for the "it just works" kind of people.

View this comment - View article - View full comments