Just do an infinite loop
exec_once = zsh -c 'while true; do waybar; done'
Just do an infinite loop
exec_once = zsh -c 'while true; do waybar; done'
If you are on endeavour, I don’t think there’s much point jumping to plain Arch if you are all setup and comfortable. I say this as a pure Arch user 😛 Not much will change for you, you’ll just be pissing away a day to setup everything you’ve already setup on endeavour again.
Nah, I’d rather put together my own PKGBUILD on Arch, so I have an mostly repeatable build for a package that doesn’t exist in repos. Bonus, I can share that if I wish and make others life easier.
Can they solve the same problems as IT pros? Sure! But it’ll take them longer and the solution might be a little weird.
Well the person just wants a solution that works. They didn’t say it has to be the best solution of all solutions.
Vim or emacs? I mean I know they were created a long time ago, but they are both pretty good pieces of software, both highly configurable. I don’t understand people aversion to them, rather than having the false belief that they are too complicated? When in reality they just aren’t intuitive in terms of modern stuff. But they aren’t difficult, just different.
I am an Arch user and I still don’t get it either. When Arch borks something it’s rarely catastrophic. At worst it’s throw in the live USB, mount your drive and fiddle. And if you are going in as an Arch user, fiddling is something you sign up for.
Well glad you got it sorted.
Funny. The one time I installed it, I just stuck it on a usb, booted from it, started the installer, next, next, done.
I really didn’t have much of a different experience between installing pop os Vs Ubuntu.
I guess some weird hardware thing that Pop OS doesn’t provide for?
Doesn’t Mint make installing Nvidia drivers pretty simple?
Try running a memtest, if it’s not voltages it could be a faulty ram stick. I’ve had it where data gets written, but what is read is garbage, corrupted some pretty important files on my system when I ran an update and it used that faulty section for it’s buffer.
Minikube is excellent for that already.
Linux is a full time and never ending experience, the rabbit hole you want/will dig deeper in hope to find a white rabbit !
While Linux can certainly be such an experience, it doesn’t have to be at all.
If you have a defined use case for your system, and there’s Linix software to support that, it often just install something like Linux Mint, install the software you need from the repos, and wahoo, you have a computer to do what you need and you just use it.
Which, for most people, is how they use their computer anyway, a few bits of software they just use to do what they need to do, no need to tinker, problems unlikely to arise.
But these people are the type that don’t care, they’ll use what comes with the computer they bought, and just be happy, and thus will likely never try Linux.
For those of us who like to stay in the know and on the bleeding edge, and tinkering and understanding, then it’s a full time thing. But we’re such a small minority.
I’d be more interested in knowing how many people are sticking with Linux.
What issues besides insert windows program doesn’t work.
Places where the average switcher has problems that aren’t just user error or misunderstanding some fundamental difference, but good places that the community can investigate and improve on.
Running a pre trained model is much cheaper than training one. But I’d imagine in this case you’ll be sending it over to Microsoft Servers, so they can keep track of everything you ever search so they can better advertise to you.
I’d just point out, for running an executable, wine isn’t JITting anything at least as far as I’m aware. They’ve implemented the code necessary to read .exe files and link them, and written replacements libraries for typical windows DLLs, that are implemented using typical Linux/POSIX functions. But since, in most cases, Linux and windows runs on the same target CPU instructions set most of the windows code is runnable mostly as is, with some minor shim code when jumping between Linux calling conventions to windows calling conventions and back again.
Of course, this may be different when wine isn’t running on the same target CPU as the windows executable. Then there might be JITing involved. But I’ve never tested wine in such a situation, thoughI’d expect wine to just not work in that case.
This seems incorrect, if it’s running natively, it doesn’t need to rely on wine…
Maybe. To be fair, most of what’s important to me to do what I need to do. Like individual applications are available on most other distros, and my dot files, and hence configuration for those applications, is where most of my tinkering time was spent and they are stored in repository. I share this between between my work Mac (macos) my desktop (Arch) and my personal laptop (also Arch). I would be able get going on another Distro pretty quickly if I decided to.
But I really do love Arch. I can get going with Arch on fresh machine quickly too, I now know my way around it, where to look for info, and generally just what to do to achieve what I want to do.
You don’t know me in real life. But I use Arch. It started out as a way to get a more thorough understanding of the bits and pieces that make up Linux. Now that it’s all setup and configured, it all just works, and works the way I made it work. I don’t need to tinker with it much now, unless I want to. It’s probably the only Distro I’ll use from now to the end of time, because I’m quite content with it.
Yeah, this is something I stressed at my place. Your Jeninksfile should set up environment variables, authentication related stuff, and call out to some build tool to build the project. The Jenkinsfile should also be configure to use a docker container to run the build within. In projects at my place that’s a Docker file on the project that ultimately sets up and installs all the tools and dependencies required for a valid build environment that’s just checked in along side the Jenkinsfile.