Amen. Now, where’s that Wine?
Web Developer by day, and aspiring Swift developer at night.
Amen. Now, where’s that Wine?
FWIW, I’m referring to the local DNS (domain name system) resolver; the mechanism that resolves local domain names into IP addresses so that computers can talk to each other over the LAN.
Here is a good primer on the configuration files and their possible locations: https://www.freedesktop.org/software/systemd/man/latest/resolved.conf.html
Edit: be careful because this is your domain name lookup you’re messing with. 😊
Let’s be honest, they’d probably already be screaming foul play regardless.
Because it’s not simply “distributing” the load; it’s actively hiding an instance as if it doesn’t exist. So what do they do when the next instance gets “too big” for their liking? Hide it, along side LW? And the next?
Re-read my comment — specifically the second half where I offer a potential solution that would actually distribute the load more fairly without having to hide anything.
Honestly, it’s a short-sighted move made with hubris by the developer’s personal ideology. Both @nutomic@lemmy.ml and @dessalines@lemmy.ml admit in the PR that it’s not a good solution, but yet they continue any way — probably because it’s an easy “solution”, despite alienating 41% of their active user base.
It’s a terrible trend in a lot of programming circles that programmers think because it is easy and it “works” (in that one circumstance) that it must be correct. This can be evidenced by browsing StackOverflow and reading the accepted answers for a lot of questions (SSL errors in software and disabling hostname verification or cert checks comes to mind).
In my 18+ years of experience, if I find an “easy” solution to a complex problem, I keep looking for the correct solution. What is “easy” now will most likely lead to more complex problems down the line. And as they say, “if you can’t find the time to fix it right the first time, where are you going to find the time to fix it again?”
Look, I get Lemmy is meant to be decentralized. Hiding away your biggest instance looks shady to outside users not in the know. The real solution is to “go door to door” to app makers and ask them to not default to any one instance of Lemmy (side note: randomizing a default server is not much better). If anything, add a link to join-lemmy where people can browse the list of ALL instances (yes, ALL of them) and let them make a genuinely-informed decision on their own. As a convenience, and API should be provided (assuming one does not already exist) so that apps can query a pageable/searchable list of existing/active instances (maybe also provide a link to their homepage too).
Hell, if it makes everyone feel warm and fuzzy, the default sorting of returned values can be weighted by percentage of active users (i.e., higher percentages get lower weights to help promote smaller instances). This would help to round out the number of signups without excluding instances.
But whatever developers do (not just Lemmy devs), do NOT overly dictate how people use your software “because I don’t like it”; lest you piss your user base off.
/two-cents
Edit: clarified a few points.
You can use kill -l
(lowercase L) to see a list of signals. But IIRC it’s the same as -KILL
.
EDIT: fixed the signal name.
Nah, we gotta kill
, preferably with -9
. 🤣
Replace the vase of flowers with a tub of Vaseline or moisturizer.
Kamala Harris is a non-white, non-GOP woman. Period.
I would imagine that it would be equally devastating to Putin to cut the cables as it would be to anybody else. I want to believe that he’s bluffing, trolling everybody to get their attention and reactions.
How ya going to download anything from servers outside of your country if the connection was cut?
What I suggest is not the same as using git rebase
. It’s pretty automatic and easily abortable.
In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).
This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.
Also, git pull --rebase
is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.
Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.
I know this is a joke, but those errors/warnings/messages screenshot is not from git. That looks more like results from a compiler of some sort.
Sometimes it takes a little unintentional embarrassment to drive a point home. It’ll make them think twice next time.
What I mean by that is that as long as you’re not intentionally or maliciously trying to embarrass them, then you shouldn’t feel bad. You cannot always control how somebody receives information; nor should you. The best you can do is to be clear and polite in your communication. If someone’s feelings get hurt, that’s on them to reconcile, not you.
This is genuinely like parenting a child: they need to develop their critical thinking skills, and to gain their own confidence. So they must be left to make their own mistakes to learn from. Your job is to give show them the tools to use, give advice when necessary, and be there to catch them when they fall; because they will fall.
Doing this will help bolster their self-confidence and make them better mid-/senior-developers later in their career. Coddling them and constantly holding their hand will make them reliant on other people and prevent them from learning anything.
Edit: also remember KISS. 😊
It’s all good. If you’re using bash and readline to read the file, you can use sudo echo ${INPUT@Q}
(assuming your variable is named $INPUT) to have bash escape things like the quotes and other characters that could get you into trouble.
sudo echo "# FYI quotes(") must be escaped with \ like \"
👆 that is not a comment. That is a command that says to echo the text “# FYI quotes(” and then to do ) must be escaped like \ \"
which is invalid syntax.
I assume that startup script is reading the contents of the file and trying to echo them into another file? i.e., using the original file as a template, but is not escaping the input, hence the error — which you’re lucky that’s the problem you’re encountering and not something actually destructive like sudo echo "# foo" && rm -rf /*
.
The problem is that they both are contextual and can mean any position in a list/array. The starting index or starting offset is generally zero, but could be one, depending on the language used.