Yeah, it takes time I think since Podman UI is newcomer here. But the future seems promising, especially when Docker decision outraging many their users before. And of course as a Linux user, cli is the best option here for a moment…
I like podman because rootless capability. Red Hat teams already working hard to convince docker to accept their PR on the rootless, yet docker decline, and close the PR.
In the end, podman spin up, and it’s very very powerful, for local development, yet light…
That’s Podman primary feature right? still… privacy and security has a downside on convenience as far as many people critize, and I choose that features rather than easy implementing with no security system enhanced. Yet, the future still bluring on Redhat side when they more expand than competition. Do we will face same tragedy like Ubuntu / Docker aggresive decision in open source space again?
I don’t think so, as the team that works in podman are veteran in Industry since Red Hat inception, I don’t think they will do something stupid, unless that the management meddle too much…
Red Hat need more profit to grow… and they are protecting their interest with GPL rights that people never think off… soo… I won’t touch more than podman topic, he he he…
Some points I handpicked for you. Ignore the uninformed masses.
The Debian GNU/Linux FAQ
Chapter 3 Choosing a Debian distribution
3.1 Which Debian distribution (stable/testing/unstable) is better for me?
If you are a desktop user with a lot of experience in the operating system and do not mind facing the odd bug now and then, or even full system breakage, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly.
3.1.5 Could you tell me whether to install stable, testing or unstable?
Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.
Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
3.1.6 You are talking about testing being broken. What do you mean by that?
Sometimes, a package might not be installable through package management tools. Sometimes, a package might not be available at all, maybe it was (temporarily) removed due to bugs or unmet dependencies. Sometimes, a package installs but does not behave in the proper way. When these things happen, the distribution is said to be broken (at least for this package).
3.1.7 Why is it that testing could be broken for months? Won’t the fixes introduced in unstable flow directly down into testing?
The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let’s say this threshold is 5 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days. The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps testing in a usable state for most of the time. Overall a brilliant concept, if you ask me. But things aren’t always that simple.
tldr: “The goal of the Debian project is to produce Stable”. Sid is essentially a rolling release, it’s nothing like Fedora Rawhide in the old days when was essentially a testbed for Red Hat but it’s not meant to be as smooth as, let’s say, Arch or Tumbleweed. Testing in the other hand isn’t merely some layer between Unstable and Stable, it’s part of a bigger project, Testing exists for the sake of Stable, not for the sake of Testing. Same logic applies to Unstable but you do achieve some level of “just works” when you’re just pushing all the latest software, after all Debian also has Experimental but you should still expect breakage when something truly major happens.
Although this is useful information, gratuitous displays of hubris are gross. You should do yourself a favor and keep reading - it is clear that the decision should be up to the user after careful consideration.
All of the issues in regard to testing have well known mitigations which are trivial to implement. You can find this information and the corresponding links here
It is a good idea to include unstable and experimental in your apt sources so that you have access to newer packages when needed. With the APT::Default-Release apt config setting or with apt pinning you can have packages from testing by default but if you manually upgrade some packages to unstable or experimental, then you will get upgrades within that suite until those packages migrate down to unstable or testing. The apt pinning needs priorities lower than 990 and equal to or higher than 500 for this to work nicely. You can also pin some packages to unstable/experimental that you always want the latest versions of.
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable. If you have unstable in your apt sources but pinned lower than testing, you can automatically add temporary pinning for packages with security issues fixed in unstable using the output of debsecan.
Although this is useful information, gratuitous displays of hubris are gross.
Oh, looks like I hit a nerve.
It is a good idea to include unstable and experimental in your apt sources so that you have access to newer packages when needed. With the APT::Default-Release apt config setting or with apt pinning you can have packages from testing by default but if you manually upgrade some packages to unstable or experimental, then you will get upgrades within that suite until those packages migrate down to unstable or testing. The apt pinning needs priorities lower than 990 and equal to or higher than 500 for this to work nicely. You can also pin some packages to unstable/experimental that you always want the latest versions of.
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable. If you have unstable in your apt sources but pinned lower than testing, you can automatically add temporary pinning for packages with security issues fixed in unstable using the output of debsecan.
And that’s why Windows users say Linux is for nerds. At that point it would easier to switch to Arch, or at least just use Sid and maybe set up some rollback mechanisms.
Bash scripts kept in the home directory or another place that’s logical for them specifically.
history | grep whatever (or other useful piping), though your older commands are forgotten eventually. You can mess with the values of HISTSIZE and HISTFILESIZE environment variables in your system.
+1 for fish shell. The lack of POSIX compliance really doesn’t matter at all day-to-day, but all the qol features that the shell has absolutely do matter and they are so worth it.
If you can’t see the possibilities behind automated tasks that you have no control in… then I’m afraid to say that talking to a nearby wall will be more fruitful than (even trying to) start a convo with you right now.
I admit to only having naive user knowledge of flatpaks being an alternative. I am learning a lot today, which is why I asked.
As far as my comment goes, I was thinking about the fuss over systemD, but that is an entirely separate problem I am probably also not equipped to converse about either.
If I was looking for a top of the line card I would dig in and learn everything there is to know about graphics cards to make an informed decision. When it comes to buying a run of the mill card, its hard to get that excited!
Not sure what I’ll buy yet, but you’ve pointed out what I need to look for. Thanks!
ag to be honest I’m so frustrated by having to remember what package manager was used for installing which binary. I don’t have time for this horse shit
I have a Darter from System 76 with Pop!_OS as my personal laptop that I code on and I absolutely love it. It runs extremely smoothly and I’ve not had any crashes with it.
I also have a Lemur from them with Ubuntu for work and it’s kinda meh. Is difficult to say what causes the issues I have. It may just be the corporate tools but I end up having hard locks that require a reboot.
If you go with them I strongly suggest Pop! The distro is built for their hardware and works really well.
So, one use case would be saving your current terminal setup. Instead of exiting the terminal and navigating to the project and setting up the environment again next time, you can simply detach and re-attach.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.