I fundamentally dislike the concept of flatpacks. It's fine and/or necessary for immutable distros, but I see little point in loading every dependency individually for every app. It's fine for an app or two, but adds up to a lot relatively quickly when used as the default system. To each their own I guess, but I'm very happy with the ecosystem of the huge, up-to-date native repo + availability of the AUR.
- Posts
- 0
- Comments
- 497
- Joined
- 3 yr. ago
- Posts
- 0
- Comments
- 497
- Joined
- 3 yr. ago
This is just complete and utter nonsense.
It just is a real alternative by now. Has been for a while. I have no idea why they say "getting closer".
If you want to just try it out, there nothing stopping you. Most distros allow you to just live-boot and use it without installing. It install into a 2nd boot SSD (a 30$ 128gig is fine), so you can dual boot.
I would not recommend the frequently recommended Mint though, as is somewhat outdated advice. It's good advice for people who just use a computer, but not really "power users". As a power user myself, who switched relatively recently, I am incredibly happy i went with CachyOS. While also targeted at gaming, it just works very well for any use case and being incredibly polished and honestly stable (despite being based on Arch, which is a rolling release). It's also very well setup to run Windows apps in general if the need arises. Wine and associated tools are there and available as optimized packages (with some selected patches).
I don't know what the time frame or interval of these events is. I switched to CachyOS 5+ months ago now, updated in the evening before going to bed (basically daily, bleeding edge as you might say).
I had zero issues. Maybe it'll be an issue one day. But while I could check for any critical known issues, and that would be an extra step (I don't, so it's not), it has saved me so much time just having up to date packages on literally everything just in the repo. It's insane compared to especially Debian, where things can be years behind and the only way to get a reasonable recent version is to build from source, find a .deb repo for it or install a manually downloaded package directly (like on Windows).
Packaging the USB-C-to-3.5 doesn't solve the problem for me. I could plug in a headphone or line out AND a charger at the same time. And yes I frequently used that. There's are adapters that do both, but they are fiddly.
Also I will need to have that stupid adapter with me. I have many many headphones. There's a headphone in every jacket I own (you never know when your need one). Every backpack. I then forget to bring the fucking adapter, and what use is all the depositing of headphones so I'll always have one? I'm not adding adapters to my headphone stashes, that's for sure.
My experience has been very different. While I'm competent on Linux from the server world, I haven't run a desktop Linux in decades, and never seriously. Until I switched a few months ago, choosing CachyOS. Honestly, almost everything just worked. Games, music, video, browsing, office. Even Ms teams for work. The only fiddly bit was getting the VPN for work to connect, and remote desktop works but isn't equal in quality/feel. But that's just a slight inconvenience that isn't even bad enough for me to start looking into it.
One game (a demo) I couldn't get to run, and I know it should work and just doesn't on my system. Haven't bothered digging into this either, I have plenty of other unplayed games. Another game I play frequently (online/multiplayer) gave me some lag issues early on, I tried a few settings and it's fine now.
Absolutely nothing of my experience would I describe as a struggle. Frankly most of the time I forget I'm not on Windows. I just use my PC. Sometimes I want to check some windows specific setting, open the "not start menu" and then realize "right, this isn't Windows".
A Spotify jam you can start at any time, anywhere. Then whatever you're playing is that "Jam". You can send other people (who also have Spotify) a link/qr and they can hear it, and play songs too. It's literally 1 click to do this with a group.
I also don't use it, so I don't know how it exactly works once you're in it. Like how don't suggestions work or if anyone in it can just add to the queue, but that's the assumption on my part.
Yes. That's basically the point. They call it a "drop in replacement", but last I used it manually there were some extra steps for what I wanted to do. To be clear: not for every thing you want to setup, just one if the things I read don't up required extra steps. But I also hear that those things have changed since then and it's mostly seamless now.
That's not really the same though and much more manual while in use, and also quite a lot of setup.
Especially without any additional context or knowledge about their background, directed at someone clearly only starting out, this is incredibly bad advice.
Edit: typos (italic), sorry that was probably hard to read.
Proxmox and Docker don't really do the same thing. They live in the same area, but the coverage is very different. You can always use docker when your host is running proxmox: either individually or in groups inside of an lxc, or all in w dedicated VM, or even natively on the same house if you prefer chaos. But you can't do the opposite: Sometimes you just need a VM. Maybe you only need a couple of devices, and you know they run on or are even designed for docker, then that's the better option. In all other cases, and when just getting started, proxmox is just the way more universal solution if you're only planning on having a single host (for now).
The management tools in proxmox are great. The community scripts are a fantastic resource and only work with proxmox. I would suggest you set it up natively, not on top of Debian though, even if that's already installed. Not the least of the reasons are to be able to use ZFS easily, including on on the boot partition (select that in the installer).
Finally, if you're gonna stick with docker, like others said: consider podman. That really does the same thing docker does, but it's fully open source. Arguably it's better in some areas, but on the flip side might, in occasion, require fiddling with something intended specifically for docker and using advanced setups.
Also there really is no wrong answer, either. And you can always change whatever you choose.
Ironically, many Europeans could drive through it with their vehicle. Actual Americans, probably less so...
That's cool and all, but it took me way too long to read that graph. Only figured out which line was CoMaps after reading the text with the amount of contributions.
Who thought using line colors black, orange, and three slightly different shades of green was a suitable choice? I get it's the app colors, but that doesn't make it any more easy to read...
I think you keep missing my point. This isn't about a "usual web form". You aren't entering your address or something. You're configuring a service or server. Those are very different worlds. I understand that those kinds of forms where you enter your address (or whatever) wouldn't ever have a default in there. In that context a default doesn't make any sense (default name, default street, default city?). And even in the cases where it might, it would be - as you pointed out - unexpected for the kinds of users that usually fill out "web forms".
When you're configuring a server/service, that's a very different world. Many fields could have defaults, and you wouldn't want to hard-code those into your config. That is what this is. It's essentially a web interface for a config file, which often has default values for any field you don't specify for a variety of reasons. Defaults DO have special meaning here. That's the whole point I'm trying to make! In that world it very much makes sense. The best way to show it is obviously a matter of personal taste, I actually like (and prefer) the greyed out way for reason I mentioned above.
Being shown what's the default isn't the same as having it actually in the field. For example the default might change, then these values would change with the default. There are also cases where they are inherited or something similar, where the upstream value isn't as fixed as defaults normally are. So there is a functional difference to showing you a greyed out default and actually having that default be in the field.
Especially for things that essentially are a web interface for a config file where the config file gets larger with values that aren't needed (this includes both NPM and Proxmox, as examples). Instead of like 3-4 lines it could now be like 20. It also becomes unclear when looking at the values later if they were actually set to that value intentionally or if it just happens to be the default that got filled in because some UI was used that filled all fields with their default values.
Showing the default outside in a label or as a tooltip-hover is an option, but has implications for the space needed and readability. And this way is actually much clearer if you want to look over a config and you need for example the default port or something, it's in the exact place you expect it, shown in grey to make it clear that it wasn't set intentionally but that it's just the default. In some UIs there's room for defaults, in some not. I personally vastly prefer them to be shown like this, as you might have guessed already.
Yea I realized that only after. I agree it's slightly different from the grey text in text fields, but it still illustrates the point because it's also an implicit default value (that happens to be unchangable in this context). So it kinda applies, but yea not quite the same.
I'm coming from the perspective of administrative interfaces, not generic forms. See my other reply for the examples that I use daily that made me have a different "intuition" here. Edit: But the fact that I got three replies in like a few minutes also shows that my perspective might not be the universal one. Still, I think it does hold up in the context of administrative interfaces (which is what NPM is).
always [...] why would it be an implicit default?
Cause that's what I intuitively expected, because in the tools that I use daily, that how it is there. Here are some examples of other administrative web interfaces that use grey to show you the implicit default that I happen to have running and could find in like 3 minutes. So much for your overconfident "always":
- Proxmox PVE or PBS. Basically every dialog. Example network interface configuration:
- TrueNAS, example "Add Dataset"
- OPNsense, example "Firewall Rule", the destination port range has an implicit default and is grey:
Note: I'm not talking about a form to fill in your name with "john doe" or whatever, and even that I can't even remember seeing either. Cause it just says "Name:" and nobody needs an example.
If you consider how subscribing actually works (or rather: has to work) with federated content, this isn't surprising. There could be some mechanism that uses the old community and some sort of meta-post to trigger the subscriptions to migrate, but the hard part is making that abuse-resistant. Probably too hard?