I just removed the volume widget on KDE plasma (for aesthetic reasons). But by doing so, my volume control keys don't work anymore.
I have to open the settings everytime I want to change the volume.
Is there any way i can get rid of the volume widget while still using my volume control keys ?
Related
I have the following use case: building and delivering a product composed from multiple container images. The product is delivered and deployed to air gapped environments that don't have access to external systems like image registries.
Delivering patches for the product implies rebuilding container images and delivering full container images. Although the changes are small, a patch is more than 10Gb in total size as most of the images are rebuilt (e.g. for addressing new vulnerabilities).
Are there standard ways of delivering image patches only (like only the binary content that changed) instead of the full images?
I want to build a Google Cloud image using Packer, but can't seem to find a way for packer to add additional disks. This is required as want a persistent disk for application to store data on it.
Is it something that can be done through startup_script or any other way?
From a quick glance at the GCE API documentation it looks like images only can contain one device, the boot device.
I'm playing around in .netcore and attempting to make use of the user secret store, some details are here: https://docs.asp.net/en/latest/security/app-secrets.html
I'm getting along with it well enough when working locally, but I'm having trouble understanding how this could be utilized effectively in a team environment, and if I wanted to work on this project from more than one computer.
The store itself (at least by default) keeps its configuration json file within the users/appdata (on windows). This feature is good to use if you're uploading the project to github, to hide your API keys, connection strings etc. This is all great when it's just me, on one machine working on a project. But how does this work when working in a team environment, or on multiple machines? The only thing I can think of is to find the configuration file, check it into a private repo, and make sure to replace it in the correct directory when changes occur.
Is there another way to manage this that I'm not aware of?
As you already know, the Secret Manager tool is providing another method to avoid checking sensitive data into source control by adding this layer of control.
So, where should we store sensitive configuration instead? The location should obviously be separate from your source code and, more importantly, secure. It could be in a separate private repository, protected fileshare, document management system, etc.
Rather than finding and sharing the exact configuration file, however, I would suggest keeping a script (e.g. .bat file) that you would run on each machine to set your secrets. For example:
dotnet user-secrets set MySecret1 ValueOfMySecret1 --project c:\work\WebApp1
dotnet user-secrets set MySecret2 ValueOfMySecret2 --project c:\work\WebApp1
This would be more portable between machines and avoid the hassle of knowing where to find and copy the config files themselves.
Also, for these settings, consider whether you need them to be the same across all developers in your team. For local development, I would normally want to have control to install, use, and name resources differently than others in my team. Of course, this depends on your situation and preferences, and I see reasons to share them too.
I'm working on an AIR app that will have a free basic version and a more advanced paid version that's unlocked with a license key. Ideally once a license key is entered I'd like it to unlock the application for all users of the computer.
However, I haven't been able to find a suitable system-wide location for storing the license key file. All of the preconfigured locations in the File class (e.g. File.applicationStorageDirectory) are either user-specific or read-only.
Is there a standard system-wide location in AIR where I can store things like this? If not the file system, maybe shared objects, or SQLite, or the encrypted local store? Failing that, are there standard locations on each system (Windows, Mac, Linux) that I could hardcode that are guaranteed to be writable by all users? The last option is made more difficult by the lack of access to any environment variables.
If all else fails I guess I could just require the application to be unlocked per-user, but that doesn't sound like a recipe for happy customers ("What do you mean I have to buy it twice for my wife to use it? We only have one computer!").
(Okay, yes, it it's per-user I'll probably let one key unlock the app 3 or 4 times to be nice about it, but it's still less convenient for the user to activate multiple times).
you can choose your own location using literal paths that could be system wide and writable, for example:
//windows:
new File("C:\whatever ...");
//mac:
new File("/System/whatever ...");
the available directories in flash.fileSystem.File (IE: File.desktopDirectory) are conveniences for developers since these directories are common to use and different on each system, but you are not limited to using them.
you will, however, have to know of and hardcode these directories into your code, which could be dangerous since these directories may not exist on the users computer or they may need administrative privileges to write to these directories, etc.
i suggest that you simply store the key in the File.applicationStorageDirectory for each install of your application, but perhaps include a user-limit written license with each purchased key.
with licensing keys these days your goal can only be to keep honest customers honest, not thwart the efforts of hackers. this is especially true with ActionScript 3.0 / AIR, since the code is going to be exposed (unless you are using an obfuscater like SecureSWF)
there's also the Adobe InMarket if you want to simplify the process of selling your application.
out of curiosity, what are you working on, if you don't mind elaborating.
I'm getting pretty tired of my development box dying and then I end up having to reinstall a laundry list of tools that I use in development.
This time I think I'm going to set the development environment up on a Virtual Box VM and save it to an external HDD so that way I can bring the development environment back up quickly after I fix the real computer.
It seems to be like a good way to make a "hardware agnostic backup" and be able to get back up to speed quickly after a disaster.
Has anybody tried this? How well did it work? Did it save you time?
I used to virtualize all my development eviroments using VirtualBox.
Basically, i have a Debian vbox image file stamped in a DVD. When i have a new project i copy it to one of my external hdds and customize it to my project.
Once my project was delivery, then i copy the image from my external hdd to a blank DVD and file it.
I've done this with good success, we had this in our QA environment even and we'd also make use of Undo disks, so that if we want to test for example Microsoft patches we could roll the box back to it's previous state.
The only case we had issues was on SQL Server's particullary if you do a lot of disk activity. We had two VM's replicating gigs of data btw each other hosted on the same physical box. The disks just couldn't keep up; however, for all the other tiers it worked like a breeze.
One cool idea I just saw a presentation on is using VirtualBox, and have your host using OpenSolaris with ZFS. That makes it easy to take a snapshot of your image(s), and rollback to the snapshot when things go wrong, or when you want to restore to a known state for QA purposes.
I keep all development on virtual machines. In a multi-developer shop this allows for rapid deployment of a new development environment if someone fries their VM (via service pack or whatever) and allows a new developer to join the project almost immediately.
K
I'm reading the question much differently than the rest of you guys. I read it as the OP asking about keeping an image of a fresh install as a VM, then, when a server needs to be redeployed, you can restore from a backup of the VM.
In this case, the VM is nothing more than a different way of maintaining an image of an OS install, and if it works, it's not a half bad idea, IMO.
In the companies I work with, I encourage the use of network installable operating systems. With the right up-front work you can configure a boot server on your office network which will install your base operating system, all the drivers you need for your hardware, and all the software you'll use. Not only will this bail you out in a disaster scenario where you lose a machine, but it makes deploying hardware for new employees trivial.
This is easier with Linux than it is with Windows or Mac, but the latter two can work in this manner too.
I use the same network install methods for deploying servers in a live environment too.
The Virtualisation approach isn't a bad answer to the same problem, but to me it doesn't seem quite as clean.
That's not the way to go.
When you are developing you want to have many tools, some which require a lot of computing power.Keep in mind that (IIRC, I couldn't find it on VBox website ) only emulates a PIV.
At the moment only one VM simulates a dual core CPU, and that's very new. This is important because there are race conditions that can only be seen on multiple CPU machines, so you want to test your code under multiple CPU/cores.
I think a simpler and better thing to do is make a disk image of your system and configuration partitions, restore it once a month to keep a clean system, and restore it
when ever your system gets mussed.
Now a quick word about Windows, since the other systems where I have done this are no problem. The partitions that you image, should not be changed in between. Not a problem
for other OS's, but some briliant person decided to put Profiles on Windows smack dab in the system files. I simply make it a point to not put anything in my Profile (or on my Desktop which is in my Profile ) that I'm not willing to lose.