Yeah good point. I suppose the problem is this function that operates on numbers allows numeric strings to be passed in in the first place. The only place where I would really expect numeric strings to exist is captured directly from user input which is where the parsing into a numeric data type should happen, not randomly in a library function.
On my machine at least man openssl shows that -k is for specifying the password you want to derive the key from, so in that case I think you are literally using the string /etc/ssl/private/etcBackup.key as the password. I think the flag you want is -kfile.
You can verify this by running the command in strace and seeing that there is no openat call for the file passed to -k.
Edit: [email protected] beat me to it while I was writing out my answer :)
It’s kind of insane how bad this whole is-number thing is. It’s designed to tell you if a string is numeric, but I would argue if you’re ever using that you have a fundamental design problem. I hate dynamic typing as much as anyone else, but if forced to use it I would at least try to have some resemblance of sanity by just normalizing it to an actual number first.
Just fucking do this…
const toRegexRange = (minStr, maxStr, options) => {
const min = parseInt(minStr, 10);
const max = parseInt(maxStr, 10);
if (isNaN(min) || isNaN(max)) throw Error("bad input or whatever");
// ...
Because of the insanity of keeping them strings and only attempting to validate them (poorly) up front you open yourself up to a suite of bugs. For example, it took me all of 5 minutes to find this bug:
toRegexRange('+1', '+2')
// returns "(?:+1|+2)" which is not valid regexp
Agreed, but my point is with a centralized network the lowest common denominator wins. There is no reason you can’t have QoL features on an open network, and thusly let everyone have the features that they care most about.
Can you imagine what a shithole the internet would have been if email wasn’t federated an open? There is absolutely no way that whatever centralized bullshit would have spawned instead would already be either long gone or enshittified to the point of being useless.
Good for you, you have a short list of requirements out of a chat service and discord perfectly fills your niche. But different people have different requirements for chat, and they don’t align. And network effects force people who have differing requirements to use the service with the most users which sucks.
For instance here are things that I require from any chat service that I use that discord completely falls flat at:
While I agree that first party systems suck, as someone with neither an iOS or Android device I personally prefer something work rather than a screen that says “connect iOS/Android”.
Definitely agree, but your link is protected by cloudflare (yet another centralized service destroying the internet) and therefore I’m unable to get through because I have privacy.resistFingerprinting enabled on my browser so cloudflare is unable to determine I’m human I suppose.
I despire youtube and it’s monopoly, and I think it get’s an appropriate amount of hate on here and HN, but what confuses me to no end are the people who complain about youtube turn right around and constantly recommend cloudflare. Can someone explain what I am missing?
That’s wild, I’ve never seen an upside down port.
I agree reversibility is better and am happy usb c will finally kill this meme.
I would have more sympathy for Youtube if 1. it wasn’t the de-facto standard where essentially all video media gets uploaded to (which Youtube itself has done everything in its power to make happen) and 2. the company that owned it didn’t also own the most popular phone OS, most popular search engine, most popular email provider, most popular ad network, most popular maps, most popular online office suite, most popular airline booking, 2nd most popular cloud hosting… The list goes on
Until a federated solution like peertube gains more traction I have no problem paying content creators directly via patreon, and do everything in my power to not pay Google a dime. Trust me, they can afford it just fine.
Yeah that’s fair. But I feel like I’ve seen these “USB superposition” memes since before IoT was even a thing.
Can someone explain to me why I keep reading about people having problems plugging in USB A connectors upside down? I feel like I’m taking crazy pills. Per the spec, the holes always go up. They indicate the correct way to plug in the port. Not only that, but the printed logo on the connector also always goes up.
The only time this is SLIGHTLY confusing is if you have a desktop tower where the motherboard is essentially mounted sideways, but for that case it just takes an extra second to think which way is “up” from the perspective of the motherboard.
And before anyone says “who reads the spec?”, it feels like I subconsciously knew this for something like a decade before I even knew what a spec was.
Yeah, sort of. I probably didn’t explain super well, and also probably don’t fully understand the problem so here are some code snippets that might make things more concrete and you can tell me where my asumptions of your codebase are wrong
So first off we have what I assume you were suggesting with multiple options for the individual db props. I commented where things are painful and bug prone:
If Option is indeed the aproach you want to take we can solve a lot of these
problems by moving all the fields that go optional together into a separate
struct:
We get even more type safety and clarity by making them separate types (and have ArmyWithDbProps wrap Army):
Or we could use Into if it’s not appropriate for process_army_from_db to turn an ArmyWithDbProps into an Army:
Also this last example is using clone when if this is in-fact the direction you want to go we could be using pointers to avoid unnecessary clones. Let me know if this is the case and I can write a version with pointers and lifetimes.
I’m sure we’ve missed something here specific to your software (obviously the above links are all trivial examples), but I just wanted to help clarify my original point with some concrete code. If you can share some of your code we might be able to give you more specific advice.
I haven’t used any flatpacks, mostly because they don’t seem to have a good solution for running terminal programs. (Also I don’t like that the application developer chooses the permissions to expose rather than the user.
However, I have been using bubblewrap which is what flatpack uses under the hood to sandbox. This allows me to run both gui and non-gui programs, and I have the control of exposing the minimum required permissions that I’m comfortable giving an untrusted piece of software.
I seem to be in the minority here but I personally prefer using and # to denote root. I like this because not everyone uses sudo and might not even have it installed.
That being said, if you already have other commands that are using sudo -u ... to run commands as a different user then it might be best to just be consistent and prefix everything with it, but if there is only a few of those maybe a cp foo bar && chown www-data bar is an alternative.
Rust has a strong emphasis on strongly typing constraints. So if a collection of fields are always some/none together having them listed as separate options in the struct means there is some assumptions you are making that the type system isn’t aware of which can lead to pain and bugs in the future.
I agree that separate types with Into sounds like a nice solution to me, it would be good to see the error the compiler is giving you (or if you can a minimal reproducible repo). If you absolutely can’t make it work, a single Option<Inner> at least would be more correct as all the fields on the inner struct would be optional together.
it has a nice working sync of connection profiles (even of ssh keys…encrypted!)
Sorry, but what on earth does this have to do with a terminal emulator? Something like this makes way more sense as a separate tool. It’s like if I was making a decision of what video player to use because it can sync my browser bookmarks.
Best I can do is
"\ude41🙂".split("").reverse().join("")returns
"\ude42🙁"