On their readme
Harper currently only supports English, but the core is extensible to support other languages, so we welcome contributions that allow for other language support.
On their readme
Harper currently only supports English, but the core is extensible to support other languages, so we welcome contributions that allow for other language support.
SIGINT is sent when you press Ctrl+C. SIGTERM is sent in just about every other situation - basically when the system wants the program to end. For instance when systemd wants to stop the service or the default signal with programs like kill pkill htop etc. You should catch both of these signals.
Or refactored at a later date.
GUIs tend to only cover the common/basic usage. Which is easy to remember without a cheat sheet. When you need more advanced stuff then GUIs tend to become more of a sticking point I find. And with common workflows it is far easier to automate with the CLI then with a GUI.
Never seen anyone change it for the mouse, but I think for a joystick and especially gyro it is more common to have them different. Same basic principal applies to all three inputs though.
In first person games the distance you need to move horizontally is often far more then the distance you need to move vertically, quite often only needing to look up/down a small amount. So you can get better accuracy in the vertical direction by turning down the sensitivity without sacrificing the ability to move quickly up and down. But in the horizontal direction being able to move quickly is generally more important than better accuracy.
Not sure how important the difference is for the mouse though, likely why people don't use it. But it is an easy setting to split up for the developers so why not give players control over it and set it however they like? Would be nice if you could lock them together, but that is a little more complex and requires more thought to do. And I don't see game devs giving that much thought about the minor user experience improvements in their games settings when they have a load of gameplay still to worry about.
Cdk8s is better at generating yaml. Pulumi is more of a terraform replacement that has a good kubernetes provider (the tf one sucks). Though it can generate yaml as well it is really not designed for this.
IMO there is something nice about having all your infra, both inside and outside kube, controlled by one thing. Then you can declare a whole application in one rather then half of it in one tool and half in another.
Define safe. Your can recover from just about anything with a live USB by just reinstalling any missing packages. But that is only needed if you remove some vital packages, those in base or to do with your bootloader. Which is only a small list. And none of those will be in the AUR unless you explicitly opted into something critical (like zfs as your main filesystem, or a custom kernel).
Most things, especially GUI stuff is optional in Arch. You might break your GUI but you should always have access to the CLI to reinstall things like you did when you first set things up.
The only time I would be really wary is if trying to remove a package also tries to remove half your system packages. Then it is more likely to be required by something you want and should very carefully audit the list of packages it wants to remove.
But I’m sure someone did the math
I would not put too much weight on that. The number of solar roadway projects and similar tech that when you run the numbers shows it being a complete waste of time - only for many different cities to invest in running a test (at their own expense) only for the project to fail later on for being too costly and not giving the benefits they were promised. Solar solutions seem to be the modern day monorail grift from the Simpsons...
Would still probably be better to have static solar panels along highways and charging trucks with some kind of pantograph setup instead.
This is the type of thing we should be investing in first IMO. A solar truck might make sense some day when solar is cheaper and more efficient - but we currently have a lot of static infrastructure around solar we could be building instead of these less efficient trucks (that is in terms of use of the solar cells, rather than the trust itself).
With all the solar roadways test projects that have been done over the years that every time the experts say is a complete waste of time and then end up failing completely - I don't assume that everything is taken into account any more. This seems like one of those ideas were the resources could be better spent on a different design.
Though I have not run the numbers - I am just skeptical of this solution. Not saying it wont work - just I don't have high hopes for it to be a good solution at this point in time. It seems to me that solar panels in static places are still needed and are more efficient and can feed into the grid when not feeding a battery. And we should be questioning if this is actually a good idea. We seem to have a lot of ideas that sound good on the surface until you actually run the numbers - yet projects like that still get funding. Especially around supposably greener technology solutions.
EDIT: seems it wont render ampersand correctly at all.. so the below is just has everything escaped when I didn't mean it to be and more confusing than it should be because of this... not sure how to get ampersand to display correctly in a code block, seems to be bugged.
& is the HTML escape code for ~~&~~ ampersand. As ~~&~~ ampersand is a special character in HTML which means entity reference and should you can use the escaped form to get the browser to render just & rather than treating it as a reference. The same goes for other characters like ~~<~~ less than or > etc. However a lot of browsers still treat ~~&~~ ampersand as a literal in places where it does not look like a reference so the literal still works in a lot of places. But the escaped form always works.
But when you copy html from a page your browser is probably copying the escaped form the page used in its source rather then the rendered form. It does this to let you get rich markup when pasting into documents - the app you paste into understands the html and knows when you are using heading or bolding text etc.
But in this case the app just pasted in the escaped form with no conversation. And for security reasons likely escaped it again as you don't want users to be able to post any old html formatting in a comment, so any html special characters in the input get escaped leaving you with a double escaped char, which the browser only unescapes one layer of when rendering.
Nothing wrong with hardware raid in general. But most consumer motherboards do not have true hardware raid - but instead fake raid. Which is some basic hardware boot time support for software raid. IE the BIOS can understand the basic raid features to boot the system - before handing it off to the OS to manage.
I would not use fake raid on a Linux system if you can avoid it, full software raid is just better than most consumer hardware fake raid support.
True hardware raid generally requires a separate expensive card that has its own controller and ram buffer.
I don't agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.