My phone has this problem. It's RAM.
My phone is literally never not using the full 8 GB it has, and it's constantly juggling. Even when I have next to nothing open.
What's eating it all? Fuck if I know. My phone also has a system memory leak that has eaten up 90% of the onboard storage with modem crash dumps I can't delete without root, and this phone has no custom firmware to do that. Got what I paid for, I guess...
You don't. One of the core aspects of Git is that it fully expects conflicts to be inevitable, and it gives you tools to resolve them.
I will say that if you learn to aggressively rebase branches, you can at least occasionally reduce the complexity of conflicts.
If you are working on a long branch and three other branches that conflict with your changes land in the meantime, a simple merge will force you to reconcile all of those conflicts in one big stinky merge commit.
If you instead rebase after each individual branch lands, you resolve the same number of conflicts but in three smaller, focused steps instead of one big ugly one. You also don't get a merge commit full of redundant deltas that serve only to resync your branch to master; all the conflict resolution becomes baked in to your individual branch commits.
Spreading out the problem is not reducing the problem. But it can make fixing the problem less daunting, which has a similar effect.
I have no idea what you mean by DIY distros, what a peculiar adjective in this context. Linux itself is DIY. Life is DIY.
Pretty sure what they meant is no distros where you have to manually curate and possibly even build every sodding package, like Linux From Scratch, Gentoo, and maybe to an extent Arch. I presume they want a disto that flashes to a live USB, walks through a wizard, and boots up out of the box fully functional in minutes, no fuss required.
Yeah, the notion that "cut" and "delete" are the same operation was an interesting hurdle. It's quite elegant, honestly.
The only thing it disrupts is the situation where you want to copy something, delete a second thing, then paste the first thing. Oops! Too bad! It's gone now!
I'm aware we do have access to multiple registers in Vim, effectively giving us many clipboards to bypass this, but I don't know the commands to utilize them. Without that knowledge, this little quirk remains an occasional irritation. Just not irritating enough to motivate me enough to knuckle down and learn it.
I can never reliably cut/copy and paste what I want in Vim. I'm always either picking up or leaving behind stray characters at the edges of my visual selection, because I find the end cursor so counterintuitive.
Especially true when newlines are involved, it's always a mystery how many newlines I'll paste into my document when I hit p to put.
This is not Vim's fault, it's just skill issue.
Oh, and it's also a mystery whether the system clipboard will work properly with Vim out of the box or not. There's some voodoo setting you have to tweak if it doesn't.
I like VIM as a casual user.
I barely know any of the fancy shortcuts, never successfully used a macro in my life, can't remember how to open more than one edit buffer and have to look it up every single time, and I still constantly wrongfoot copy and paste regularly to the point where I consider it a waste of my time to try and I just type things out the long way. I totally get why people feel very defeated by this editor.
But I do feel very slick darting around with hjkl, occasionally throwing in a gg or a G or a $ to leap around. Yeah, there are faster ways to get where I want if I'd only learn them, and I may some day, but this gets me around. If you can build up just the basic movements, that's enough to at least begin to appreciate the editor.
Not having to touch my mouse to edit text is a massive game changer that is worth it on its own. Not that vim is the only one that offers this benefit, of course. But what it does well that I haven't experienced in editors I've tried is how beautifully it flows if you happen to already know how to touch-type. Y'know, hands on the homerow, certain fingers hit certain keys, building up the muscle memory so you don't have to look at the keyboard to type, all that. It's why vim uses hjkl to move the cursor--it's where the right hand rests in a touch-typist position.
If you don't use keyboards this way, vim will probably ruin you. I know a lot of people who are proficient typists who never learned standard touch typing, instead home-rolling their own cursed setup that works for them, and god bless them, but they would be hard-pressed to negotiate vim. If this is you, vim may not be the editor for you.
Man, I haven't seen a pony in the wild in ages.
step 2 of this process involves making a backup. whether they understand how they did so or not.
Not to mention a rapidly growing segment of the population is unable to read analog 12 hour clocks, so the analogy is not that helpful.
This, 100%. The only value of preordering is guaranteeing stock of a physical item that threatens to be out of stock if you were to buy it walk-in. In the modern digital age where downloading tens of gigabytes that take up no space, ship near-instantly on demand, and have theoretically infinite supply, preordering is pointless if the actual game itself is all you care about.
Is this because the kernel assigns that port to that specific process, so that all traffic at that port is associated with only that process?
Yes, that's what ports do. They split your IP connection into 65,536 separate communication lines, that's the main thing, but that is specifically 65,536 1-on-1 lines, not party lines. When a process on your PC reserves port 80, that's it. It's taken. Short of hacking the kernel itself, it cannot be reassigned or stolen until the bound process frees it.
The SO answer you found it interesting, I was not aware that the Linux kernel had a feature that allowed two or more processes to willingly share a single port. But the answer explains that this is an opt-in parameter that the first binding process has to explicitly allow. And even then, traffic is not duplicated to all listening processes. It sounds like it's more of a "first come first serve" to whichever of the processes are free to read the incoming message at the time it arrives, making it more of a load balancing feature that isn't a useful vector for eavesdropping.
To me it comes off like you're irrationally afraid to invoke its name.
I get and appreciate that you're trying to make a statement here, but in my opinion it isn't landing the way you think it is. By giving its name special reverence you're needlessly elevating it, not diminishing it.
The point of the firewall is not to make your computer an impenetrable fortress. It's to block any implicit port openings you didn't explicitly ask for.
Say you install a piece of software that, without your knowledge, decides to spin up an SSH server and start listening on port 22. Now you have that port open as a vector for malware to get in, and you are implicitly relying on that software to fend it off. If you instead have a firewall, and port 22 is not one of your allowed ports, the rogue software will hopefully take the hint and not spin up that server.
Generally you only want to open ports for specific processes that you want to transmit or listen on them. Once a port is bound to a process, it's taken. Malware can't just latch on without hijacking the program that already has it bound. And if that's your fear, then you probably have a lot of way scarier theoretical attack vectors to sweat over in addition to this.
Yes, if you just leave a port wide open with nothing bound to it, either via actually having the port reserved or by linking the process to the port with a firewall rule, and you happened to get a piece of actual malware that scanned every port looking for an opening to sneak through, sure, it could. To my understanding, that's not typically what you're trying to stop with a firewall.
In some regards a firewall is like a padlock. It keeps out honest criminals. A determined criminal who really wants in will probably circumvent it. But many opportunistic criminals just looking for stuff not nailed down will probably leave it alone. Is the fact that people who know how to pick locks exist an excuse to stop locking things because "it's all pointless anyway"?
This question reads a bit to me like someone asking, "Why do trapeze artists perform above nets? If they were good at what they did they shouldn't fall off and need to be caught."
Do you really need a firewall? Well, are you intimately familiar with every smidgeon of software on your machine, not just userland ones but also system ones, and you understand perfectly under which and only which circumstances any of them open any ports, and have declared that only the specific ports you want open actually are at every moment in time? Yes? You're that much of a sysadmin god? Then no, I guess you don't need a firewall.
If instead you happen to be mortal like the rest of us who don't read and internalize the behaviors of every piddly program that runs or will ever possibly run on our systems, you can always do what we do for every other problem that is too intensive to do manually: script that shit. Tell the computer explicitly which ports it can and cannot open.
Luckily, you don't even have to start from scratch with a solution like that. There are prefab programs that are ready to do this for you. They're called firewalls.
The way I understand it is like this:
The grand theory of classic package managers is the idea that lots of programs all need the same core libraries to function. An analogy would be like noticing most construction jobs need nails. So instead of making everyone bring their own copy of nails, resulting in dozens of redundant copies of it lying around, they have a single nails package that everyone can use.
But there are different versions of nails out there. Each version picks up unique new features, and drops legacy ones. Recent builds may incorporate and thus require the new features, making them incompatible with old versions of nails that don't have them. On the other hand, some builds may still use and rely on legacy features of nails, and are thus incompatible with the new versions. You may run into a scenario where you want Software A that needs nails version 14+, but also Software B that can only run on nails v <13, and you just can't, because they don't overlap.
Additionally, there may just be a totally different competing package out there, screws, that does largely the same job as nails, but in a completely different way that is totally incompatible with projects that expect nails. So if you need Software C that relies on nails, but also Software D that relies on screws, you might cause problems by installing both.
What a distro is is essentially a group of devs declaring that they are putting together some specific list of libraries (like, say, nails v14), and then sculpting up a bundle of software around those specific libraries. Can't cope with nails v14? That sucks. No package for you, then.
In that sense, distros are differentiated by what libraries and other low-level system softwares are available to the programs you wish to install on them. If you want your program to be available natively on every distro, it needs to be compatible with every competing set of libraries each distro has elected to use.
It is possible to just say "fuck it" to the distro's built-in libraries, and instead bundling the specific version of nails or screws or whatever you project needs directly with it. Build your own with blackjack and hookers, as it were. That's exactly what Flatpak does, among others. But it's trading flexibility for redundancy. In the age of cheap and plentiful storage memory, many people think this trade is well worth it. But it makes many formalists cringe.
deleted by creator
imagine if every application on your desktop reacted differently depending on how many times you clicked a spot
yeah, wow, imagine. different applications using different design patterns for different contexts. perish the thought!
Is that also OK just because one browser started doing it and every other browser copied that function?
one browser did an arguably useful thing, every other browser agreed it was arguably useful, and it became a widely adopted feature? sounds ok to me. gee, it's almost like this is how standard patterns come to be, or something...
I admire the respect you have for those who ask questions like this, but I think I disagree.
If there is something egregiously wrong with the premise of what a person is seeking to do, and there are no qualifying statements in their query about why they do in fact need to do this specifiic thing in this specific way, chances are high that they are uneducated about why the premise of what they're trying to do is flawed, and they are best served by being course corrected. Giving them the answer they're looking for to continue the bad thing while hiding your suggestion of what they should be doing instead in a footnote is just enabling them to double down on the short term path of least resistance that will probably come back to bite them again later.
If they really did know what they were doing with regards to doing an otherwise unsafe and/or unsupported thing, or if the restrictions tied their hands from using the obvious replacement solution, it either should have appeared in their question prompt, or it should be in the first replies to the first round of answers.
I say, withhold outdated advice unless the context of the conversation makes it explicitly clear that the old advice is genuinely required and not substitutable with current advice. But also don't be smug, rude, dismissive, or standoffish about it. Don't argue with someone who says they really do need a specific solution.
That said, this only applies in really cut and dry cases like this one, where there very clearly is an indisputable thing you shouldn't be doing, and a drop-in replacement you should be using. The ones I hate are moreso those you may see on StackOverflow where the question is like, "how do I do
<X>
in JavaScript?" and five of the seven responses including the accepted answer offer a solution in some big dumb framework or lib that they apparently expect you to just incorporate into your project.I don't really mind either way whether these posts are allowed to remain or should be culled.
If you keep them around, they will just keep shitting up the feed. The overall browsing quality of the community goes down, hindering the user experience. I don't think it's uncontroversial to say these posts have next to no value; they're essentially equivalent to birthday notifications or "I voted" stickers. Like... congrats! You and everyone else! Now what? Where's the discussion here?
On the other hand, I do want to think thrice about controlling this with moderation. All too often on Reddit I've see the trope of a sub that appears to be crawling, and you get the idea to join in with an enthusiastic post, only to get removedsmacked by automod because you posted this on the wrong day of the week, or this post type is outright banned because the community is sick of seeing it. It's sensible, yes. But ugh, what a demoralizing filter for newcomers. Overly curated subs/communities are not public forums, they are increasingly impenetrable cliques. That may not necessarily be a bad thing if we think the tradeoff is worth it. But we have to keep in mind what we become when we make that trade.
The one thing I will say willl absolutely not help anything at all is making a designated containment community for this specific kind of post. The whole complaint here is rooted in there being no discussion value for these types of posts. You think a community comprised entirely of those would be a community anyone would want to post in? It'd largely be the Lemmy equivalent of a donotreply@ email address. A dumping ground where unwanted posts go to die. And I don't know about anyone else, but somehow I find being directed to a designated dead-end forum by mods is an even bigger slap to the face than simply having my post removed.
It bumps the speed and officially supports Displayport and PCIe protocols being tunneled through.
Also, as a tiny nit for seemingly no other reason than to piss us all off, they have decided the "correct" way to write it is "USB4" (no space). This is in contrast to every previous version of USB such as "USB 3" (space).