I love openSUSE and think it’s one of the few distros that has a pretty good implementation for every DE/WM. GNOME, KDE, Xfce, lxqt, enlightenment, mate, sway, etc… are all a solid experience on openSUSE.
That said, I have never found a distro with a good Cinnamon experience other than Linux Mint. Probably in part due to cinnamon being developed by mint, but regardless, if you want to use cinnamon, mint is your best option.
thank you, that seems to be the general opinion i have seen online. i am writing this on linux mint, thank you to all of the comrades who helped me pick it sankara-salute
But also keep in mind that it couldn't exist without Firefox/Mozilla existing. A world in which more people use Firefox over Chromium-based browsers is a better world.
ehhh debatable, mozilla still gets a lot of funding from google so they’re not as independent as you think. A better world wpuld be one where qtwebkit based browsers, chromium based browsers and firefox based browsers have the same market share.
Unfortunately Apple stole qtwebkit and drove it into the grave so there’s little chance of that actually happening :(
I still hold out hope though, and try to use Falkon whenever possible
A Mozilla dependent on Google seeing value in Firefox sending searches their way is at minimum as good as one in which Mozilla doesn't exist and everybody uses Chromium-based browsers, by definition - and in practice, way better.
But yes, more non-Blink engines in use in general would also be a better world. Alas, that, too, isn't the world we live in.
I still don’t understand why Microsoft dropped Blink. Surely there’s nothing for them in letting Google own the browser engine, and it’s not like they cannot afford to keep developing their own. Weird.
I did. But why should I need to? Firefox is the product, if nobody uses Firefox mozilla uses marketshare. Why do we need Librewolf, which really is the only Firefox you should use out of the box? The same with Mull for Android, where damn “Firefox Focus” is their privacy option which is pretty useless.
If Firefox is so bad you need to use Librewolf, Firefox as a product is useless for many people.
I now use Firefox again and harden it myself. But I dont expect ANYONE to do that, as its even a bit too inconvenient for me
I get you. But Firefox is not mass adopted, so you can assume its only the privacy concerned people. If you are about features, Firefox is good. But for the most part, and for people that dont care, Chrome is just as good, but with Webapps, using your phone as a 2FA key, flashing damn GrapheneOS through a browser, faster speed and supposedly a more secure sandbox.
Firefox relies on Google, but Google has no reason to support it anymore. So this funding will probably vanish soon.
I’ve never had a problem with ext4 after power failure.
Zram is not a substitute for swap. Your system is less optimal by not having at least a small swap.
Firewalls should never default to on. It’s an advanced tool and it should be left to advanced users.
Not to mention how much grief it would cause distro maintainers. If they don’t auto configure the firewall they get blasted by people who don’t know why their stuff isn’t working. If they auto configure they get blasted by people upset that the auto configurator dared change their precious firewall rules. You just can’t win.
Honnestly. Firewalls shut be enabled by default. Specially on laptops connecting to public places.
A good default shut be choosen by the disteo maintainer. A default shut not overwrite your own config. Like any config really. So no upset folks that like to change the firewall. Also if you dont block much outgoing trafic you are not likely to run into problems. And for people that like to poke holes in the incoming trafic. Your a “advanced” user anyway.
So what should happen when the user installs a service that needs an open port in order to work? Presumably the whole point of installing it being to, you know, use it.
Their are not many programs that require open ports for incoming trafic. Things like ssh or a web server do. But then again those are services you would manualy want to open anyway.
My current rig has 64 gb, and I opted to not create a swap partition. My logic being I have more than enough.
The question is does swap ever get used for non-overflow reasons? I would have expected 64 GB to be more than enough to keep most applications in memory. (including whatever the kernel wants to cache)
I also have 64 GB and yes, it gets used. For very low quantities, mind you, we’re talking couple hundred KB at most, and only if you don’t reboot for extended periods of time (including suspend time).
Creating a big swap is not needed, but if you add one that’s a couple hundred MB you will see it gets used eventually.
You don’t have to create a swap partition, you can create a swap file (with dd, mkswap, swapon and /etc/fstab). You can also look into zswap.
Swap is not meant as overflow “disk RAM”, it’s meant as a particular type of data cache. It can be used when you run out of RAM but the system will be extremely slow when that happens and most users would just reboot.
What is the difference between physical swap and having a swap partition on ZRAM, especially for the kernel? To the best of my knowledge, nearly no Linux distribution supports suspend to disk any more, any ZRAM swap looks for the kernel like … swap. Thanks to the virtual file system. Further, I have high trust in the Fedora community, which decided to use ZRAM.
We can agree to disagree about the firewalls, especially for people who don’t now why their stuff isn’t working, it protects them and is much better than having unconfigured services with open ports on a laptop in a public network IMHO.
As others have mentioned, the sequential speeds in RAID 0/5 won’t really help you in gaming. What you might see at best is faster loading times, but that’s really about it.
One option which no one else has mentioned is using setting up tiered storage using bcachefs - where your SSD acts like a cache drive, which would contain frequently read aka “hot” data, and the rest of the data would be on your spinning disks. This way, you’d be making the most of your limited SSD space, whilst still taking advantage of the large storage provided by the spinning disks.
The advantage of bcachefs is that all your drives can be part of the same pool and it’ll all be transparent to your OS/programs, and all your data is striped like a RAID 10 array, so you can replace your drives in the future without any issues, or any major config changes. Like if you get a faster NVMe drive in the future, you can set that as your “hot” (promote) drive, your SSD as the foreground drive and your spinning disk pool as the background ones and your data will automagically migrate.
The main drawback right now (for you) is that it’s not yet part of the kernel. The good news is that it’s gonna be in the next kernel (6.7), so you can either wait for it, or use a third-party kernel with bcachefs already compiled in it (I believe linux-tkg is one of them).
I think I need to change my plan abit. What do you think: if I buy 2x1TB, use my sata ssd as foreground, and use 128gb nvme drive as promote drive. I still do not understand the difference between background, foreground, ans promote tho. I went back and forth both reading the guide.pdf and archwiki. Still have no idea how they actually work. It’s bleeding edge, as no one beside the developer talking about it on youtube.
However, I think I’m gonna use both linux-tkg linux-git as they are available on the aur. Tkg is the Garuda used, no? It is on chaotic-aur, so I assumed so.
Foreground targets are where writes initially go. Data is moved from foreground to background targets while idle or as needed. Data which is read from the background targets is moved to promote targets.
If you set your NVMe as a promote target, SSD as foreground and your HDDs as background targets, all writes would first go to your SSD, then get copied to your HDD during idle, and finally the copy of the data on your SSD will then be marked as a cached copy. In case your SSD becomes full, then it’ll store the data on other drives. As for the promote targets, any time you read data from either the SSD or HDD that wasn’t on the NVMe, it would get cached to it, so the next read will be faster.
The main point of the foreground vs promote is to prioritize write vs read speeds. If you value faster writes, then set your NVMe as foreground. If you value faster reads, then set your NVMe as promote. Of course, you can also set your NVMe as both foreground and promote to benefit from both faster reads and writes.
But since you plan to introduce an SSD in the mix, you can create a single group for your NVMe + SSD, and a second group for the HDDs, and set your SSD group to foreground + promote, which will simplify things.
If you’re concerned about chucking both the SSD and NVMe in the same group, no need to worry cause bcachefs will automatically prioritize reads from drives with lower latency as mentioned in the wiki.
If they are different speeds, reads for replicated data will be sent to the ones with the lowest IO latency.
But regardless of which setup you go for, main thing to remember is to use the NVMe (or the group containing the NVMe) as the promote target, as that will be your primary cache drive.
I’d hope so. It wouldn’t be good if they were blind.
Anyway, I didn’t question the accuracy of what he said, just that his manner of delivery is obnoxious and portrays an attitude of self-importance. It feels like he’s yelling at the viewer with hostility.
Aussies tend to be quite direct. It’s basically our natural state. I get how it can be perceived as hostile, but I don’t actually think Brodie is very abrasive. He seems like a pretty relaxed guy.
Also, GitHub PRs atleast to me feel like they encourage reviewing changes by the total diff of the entire PR, and not each commit. I don’t want a slog of commits that don’t add any value - it just makes doing things like reverts more annoying. Stuff like Gerrit and phabricator enforce reviews by making you review individual commits / changes / whatever you want to call them and not branch diffs.
GitHub has an option when merging a PR to “squash and merge”. This option squashes all of the commits on the PR branch into a single commit and cherry-picks it on top of the base branch. We use this by default in our open source projects at work. Most people are not gonna go through the effort of making a well defined patch series the way it would be required for a Linux kernel contribution. Most changes aren’t that big though and so it doesn’t really matter. Send as many commits as you want in the PR, I’ll just review the diff as a whole and squash it when I’m done. Workflows should adapt to user preference, not the other way, and this is a good example of that.
How much of that is what GitHub encourages and how much of that is what Users prefer? Plenty of users seem to enjoy phabricator / Gerrit for code review in practice precisely because of their workflows.
Well squash and merge isn’t default or pushed in any way. It’s an option, and we chose to enable it ourselves because that’s what works best for us. It’s what works well for many other projects too, which is why many choose to enable it instead of the default merge commit.
Yeah, but phabricator and Gerrit are entirely separate workflows from GitHub, and a lot of people prefer that workflow because it leads to encouraging better histories and reviews. It helps you in getting rid of the “fixed typos” type of commits, while still letting you make larger PRs.
GitHub obviously does let you keep a clean git history, but the code review workflow in GH just doesn’t encourage reviewing commits.
I think the idea here is that reviewing individual commits is irrelevant if the plan is just to squash it all down. Each PR corresponds to a single change on the main branch in the end, the fact there was a main commit followed by a half size “fixed typos” and “fixed bug” commits doesn’t actually matter since it will be blown away in the end. The process results in the same clean history with good individual commits on the main branch, just as if the user squashes those commits locally before pushing it up to the code review platform.
Right, but squashed commits don’t scale for large PRs. You could argue that large PRs should be avoided, but sometimes they make sense. And in the case where you do have a large PR, a commit by commit review makes a lot of sense to keep your history clean.
Large features that are relatively isolated from the rest of the codebase make perfect sense to do in a different branch before merging it in - you don’t merge in half broken code. Squashing a large feature into one commit gets rid of any useful history that branch may have had.
I agree, and GitHub allows choosing how to merge each PR individually if you need to do something different for a specific PR. Large PRs like that are at most 1% of our total PRs, and we review those more per-commit and use a merge commit instead of a squash. By default we optimize for the other 99%.
“Although we’ll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time”
We can all read it right there plan as day.
If they weren’t planning to/considering it, then why specify “at this time”?
I’m only a native English speaker, so guess I could be interpreting it wrong.
Do tell oh wise one, what alternative meaning could it possibly have?
I’m only a native English speaker, so guess I could be interpreting it wrong.
You should try being a native English reader.
What it means is “they will not be accepting pull requests at this time.” Whether or not they are open to changing this in the future is not specified. They have not specifically stated that this is off the table, nor have they stated this is their intent.
So they are considering it.
Thanks for confirming my point.
If they weren’t, they wouldn’t have specified, they’d just say “we will not be accepting Pull Requests”.
How does the opinion of your supposed internal contact at mozilla affect the basic English interpretation of the public announcement?
We’d see who’s interpretation is right? Duh.
Padenot (contributer with direct ties to Mozilla internal) agrees with me on GitHub PR being terrible. 🤣
Waiting for other responses. 10000007231000000724
Note : most of them are sleeping rn, so it’s going to take a bit of time.
I asked Glob (the literal author of the announcement) directly as well. Waiting for him to wake up and see it, he was up at 3am last night, lol.
You’re quite the lunatic. I’m obviously not defending GitHub PRs, or saying Mozilla should or should not use them. I said “we are not open to PRs at this time” is not the same as “we will be open to PRs in the future.” The truth of that statement has absolutely nothing to do with whether or not Mozilla is, in fact, open to using PRs in the future. But there’s no point in telling you that, because you’re clearly unhinged. Have a good life.
Is not what I said they meant to being with. I said planning/considering, which is wildly different.
Second :
Who’s unhinged? 10000007281000000729Looks like I was right all along, they were indeed considering it but have since decided against it because of the same concerns I had mentioned previously. Is this definitive enough for you?
Nobody here needs “a long history of submitting patches to Firefox” to have an opinion on the tools used to manage the project. I assume that most here sharing their opinion don’t and yet you need not scroll far. You merely need some knowledge and experience with the tools, be it in personal, corporate, FOSS, etc. projects. Besides I don’t spend my free time helping FOSS projects just to use it to be like “my opinion better” that’s literally just the “appeal to authority fallacy”. But if you must know, I have helped here and there throughout the years under various different aliases/accounts. (Why “various aliases”? because I enjoy helping not some meaningless credit, it’s just how I am.)
So what you are saying is that as someone who has never worked on the Firefox codebase, you still somehow know more about managing contributions to one of the largest FOSS projects in the world that has been running pretty successfully for the last 25 years?
Idk, maybe try a bit of humility - like if it looks like they are making a weird decision, maybe it’s not because they are dumb and you are very smart, maybe it’s because they know stuff that you don’t?
First off, not what I said.
Second off, I never called them dumb. I actually happen to have a good relationship with them, so I take offense to what you’re implying. I mearly stated that I don’t like GitHub and gave some legitimate reasons. Which btw : 100000072310000007241000000728Maybe the one who should learn humility is you.
Here’s some creative software that replace the functionalities of Adobe software & more.
photo editing: GIMP
vector images: Inkscape
drawing/painting: Krita (GIMP also fine for this)
video editing: kdenlive
3d modelling, animating, etc.: Blender
audio editing: Tenacity (Audacity fork made after the buyout without telemetry)
DAW: LMMS
media player: VLC or mpv
if there’s any other specific software you’re looking for a FOSS alternative to, don’t hesitate to ask. You always have more options on Linux than you’d think.
for a bit more context, ncdu is a Disk Usage analyzer that runs in the terminal. If you've ever used WizTree on windows, its kinda like that. Really useful to see whats taking up space on your disk
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.