Windows has had the ability to flag individual directories as case-sensitive for a few years now. It’s… something, I guess.
Also, why is the website for the original comic crossed out? It wasn’t completely cropped out or hidden like most asshats do, but it wasn’t left alone either. Someone deliberately went out of their way to vandalize it but did it in perhaps the most pointless possible way? I don’t understand people sometimes.
Five years of Mate (which is essentially Gnome 2 on life support) replaced by a couple years of KDE Plasma.
Mate treated me well enough, it was mostly stable, capable, and competent. But it was a bit crusty around the edges, and being so niche meant search-engine-visible help resources for anything than went wrong were virtually nonexistent. In hindsight, using it as a beginner’s DE was probably a mistake. I suppose in being so austere and devoid of resources it taught me to develop more of a “get to the bottom of it yourself” attitude to debugging and have humbler expectations about form versus function, but that’s a pretty rough sell to most people. Mate is definitely better as a drink than a desktop environment.
I don’t need to talk about KDE Plasma at all because the rest of the thread already has. I have nothing new to add beyond the comment that I like their mascot character.
I have no informed opinion on Gnome 3. All I’ve gleaned about it is that it’s supposedly “my way or the highway” by design, and the “my way” in question is controversially counter-grain to a lot of established expectations (e.g. it’s literally why Mate exists). Which is neither here nor there to me, objectively. But I will say I have no interest learning a new way of doing things, even if it’s theoretically superior, when a conventional system still exists, is viable, is highly polished, and is kept sharp-edged. Hence, KDE Plasma.
In that case, you may get some mileage as well out of Old Reddit Redirect. It will automatically force all Reddit links to open in old Reddit for you.
It’s only available for Firefox.
+1 for Reddit API exodus.
Lemmy was sold to me as a Reddit replacement. And it is, superficially. I knew it wasn’t going to be drop-in going in. But the longer I use it the more I think it’s not really quite like Reddit, and never will be. And that’s fine. Lemmy is its own character and I like it for what it is.
I still use Reddit. Lemmy doesn’t scratch all the itches for me. But only old.reddit on the desktop and on mobile with a UI de-shittifying extension. I’m amazed they still offer it at all. Once that’s cut off, something I’ve been bracing myself for for years, I’ll consider the UX enshittification to have fully completed and I’ll truly bail. I simply refuse to use their gentrified UI. And I’m tired as it is having to slap on compatibility layers just to keep their less terrible alternative on life support; I’m not going to do the same thing to make their mainstream UI somewhat more palatable.
It’s a divesting of unwanted responsibility.
If any change can break something then all broken bits will need fixing.
Right. So the less decrepit, old code that contains annoying little time bombs, the less time spent fixing things.
But that’s true of all code in the kernel. […] Why not remove all drivers in case an update breaks them.
And how many people actually need these ancient drivers maintained? More than zero, sure, but how many more than zero?
Maintenance effort is a finite resource. Choosing where it gets spent is an executive decision. Every dev hour you assign to debugging some ancient driver that one or two enthusiasts might still want someday is a dev hour not spent on development of some new feature, or fixing a problem affecting thousands, potentially millions of known, current, active users.
We can’t maintain all code forever. At some point the theoretical value it may have is outweighed by its cost to keep alive, and it gets cut.
A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
That’s sort of where we’re at now, in a way.
Yes, all of these drivers presumably are still fully functional at the time of cutting. But the devs have essentially all decided, “We are not fixing these anymore” already. If any of these break for any reason, they would all be immediate candidates for axing by your system.
The reason they aren’t just left in with a “we’ll just run it until it dies, then!” mentality is because a project like the Linux kernel doesn’t want to be full of software with undefined mystery behavior where they can reasonably avoid it.
A chunk of code being part of it at all is an implicit promise of, “This is intended to function as-documented. If it does not, we are responsible to fix it.” But we already know no one will fix it. So instead it just becomes, “This chunk of code may or may not work. We don’t know and we don’t care, lol. Use at your own risk. If you can prove it’s broken, we’ll just remove it”.
The Linux kernel does not want to be full of code like that. All of its code should be reliable to build things on. If it’s coming out, it needs to be announced in advance so users have time to migrate. A “we will run it until it suddenly breaks” system doesn’t afford that. The feature ideally has to be sunset while it’s still functional.
“Unstable code, use at your own risk” projects are better relegated to optional packages. If someone wants to bundle up these ancient drivers and offer them as an optional package, they are free to do so. If there ends up being zero will from anyone to do even that, I guess it’s more evidence to how little the functionality was actually demanded.
It is. But that’s not saying much.
I may have had to keep a few of the waypoints of the trail in my head for, oh, a week or so, just long enough to scribble it on a history test. Then that information was immediately cleared out to make way for whatever other junk we had to temporarily memorize next chapter.
Only a vague, blurry notion that the Oregon Trail A) existed and B) was a trail to (presumably) somewhere in Oregon remains with me today. Oregon City is certainly not a part of that notion.
Not to shit on the Oregon Trail or Oregon City in particular, of course. I would be truly baffled to meet anyone that retained, in significant detail, even a tenth of what any grade school history class purportedly taught them.
It’s “I am working” not “I be working”.
From how it’s used and understood, it’s a lot closer to, “I am in a situation where I find myself working from time to time”. “I am working” suggests you’re doing it right now, “I be working” does not. This example is a unique, condensed way to convey a very specific idea that your idea of “proper English” cannot convey without a boatload of extra words.
If that’s still bothersome to you, well, I guess have fun kicking that proverbial land-crawling fish back into the sea if that’s where you get your jollies. IMO some prescriptivism is okay to get people on the same page, but the moment you use it as a cudgel to beat people who are very clearly already being understood, you’re being a prude.
I’ve heard this one phrased: “Newbs deserve a helping hand. Noobs deserve a kicking.”
Happy Debian daily driver here. I would never ever recommend raw Debian to a garden variety would-be Linux convert.
If you think something like Debian is something a Linux illiterate can just pick up and start using proficiently, you’re severely out of touch with how most computer users actually think about their machines. If you even so much as know the name of your file explorer program, you’re in a completely different league.
Debian prides itself on being a lean, no bloat, and stable environment made only of truly free software (with the ability to opt-in to nonfree software). To people like us, that’s a clean, blank canvas on a rock-solid, reliable foundation that won’t enshittify. But to most people, it’s an austere, outdated, and unfashionable wasteland full of flaky, ugly tooling.
Debian can be polished to any standard one likes, but you’re expected to do it yourself. Most people just aren’t in the game to play it like that. Debian saddles questions of choice almost no one is asking, or frankly, even knew was a question that was ask*-able*. Mandatory customizeability is a flaw, not a feature.
I am absolutely team “just steer them to Mint”. All the goodness of Debian snuck into their OS like medicine in a kid’s dessert, wrapped up in something they might actually find palatable. Debian itself can be saved for when, or shall I say if, the user eventually goes poking under the hood to discover how the machine actually ticks.
I recently had a rather baffling experience trying to preemptively avoid this by downloading the stupid app right away, only to discover I needed the website version anyway.
I was attempting to add my Known Traveler Number to an already booked trip with Southwest Airlines, booked by someone else. I was able to link the trip to my account right away in the app, no issue. And I could see the KTN field for my ticket sitting there, empty, greyed-out, and not interactible. I opened up the moble version of their website, completely unsurprised to find it was identical to the app, except for the detail that the KTN field there was functional. Put in the information, changes reflected in the app instantly, and I was in the TAS-pre line that afternoon.
Why did the two versions obviously built from the same codebase have two different sets of capabilities? Why was the website the more capable of the two this time? I have no clue. All I know is I never want to be a developer at a corporation where I’d have to be responsible for this flavor of trash.
It’s also part of what makes FOSS niche.
I recognize three kinds of comments that have different purposes.
The first kind are doc block comments. These are the ones that appear above functions, classes, class properties, methods. They usually have a distinct syntax with tags, like:
/*
* A one-line description of this function's job.
*
* Extra details that get more specific about how to use this function correctly, if needed.
*
* @param {Type} param1
* @param {Type} param2
* returns {Type}
*/
function aFunctionThatDoesAThing(param1, param2) {
// ...
}
The primary thing this is used for is automatic documentation generators. You run a program that scans your codebase, looks for these special comments, and automatically builds a set of documentation that you could, say, publish directly to a website. IDEs can also use them for tooltip popups. Generally, you want to write these like the reader won’t have the actual code to read. Because they might not!
The second kind is standalone comments. They take up one or more lines all to themselves. I look at these like warning signs. When there’s something about the upcoming chunk of code that doesn’t tell the whole story obviously by itself. Perhaps something like:
/* The following code is written in a weird way on purpose.
I tried doing <obvious way>, but it causes a weird bug.
Please do not refactor it, it will break. */
Sometimes it’s tempting to use a standalone comment to explain what dense, hard-to-read code is doing. But ideally, you’d want to shunt it off to a function named what it does instead, with a descriptive doc comment if you can’t cram it all into a short name. Alternatively, rewrite the code to be less confusing. If you literally need the chunk of code to be in its confusing form, because a less confusing way doesn’t exist or doesn’t work, then this kind of comment explaining why is warranted.
The last kind are inline comments. More or less the same use case as above, the only difference being they appear on the same line as code, usually at the very end of the line:
dozen = 12 + 1; // one extra for the baker!
In my opinion, these comments have the least reason to exist. Needing one tends to be a signal of a code smell, where the real answer is just rewriting the code to be clearer. They’re also a bit harder to spot, being shoved at the ends of lines. Especially true if you don’t enforce maximum line length rules in your codebase. But that’s mostly personal preference.
There’s technically a fourth kind of comment: commented-out code. Where you select a chunk of code and convert it to a comment to “soft-delete” it, just in case you may want it later. I highly recommend against this. This is what version control software like Git is for. If you need it again, just roll back to it. Don’t leave it to rot in your codebase taking up space in your editor and being an eyesore.
That’s the thing, though. I computed from the claimed figure above of 13 billion net income. The costs are already accounted for.
I’ve been told we have state senators who openly claim to only be there to keep speeding tickets low.
If you make $50k/yr after taxes, the equivalent fine would be on the order of about $120.
Where I’m from, that’s a speeding ticket.
why is there no replacement for x11 forwarding over ssh??
There kind of is. The project you’re looking for is waypipe
Knowing how these things tend to go, I predict you’ll try to use it for your use case and it just won’t work for whatever stupid reason. But I successfully used it to tunnel an app from my Debian machine at home to a Windows machine under WSL.
Fellow tattooless here. Uh, neither?
I simply don’t see the appeal of putting on something I can’t easily take off if I wanted to, for its own sake. Yeah, tattoos aren’t permanent, a removal process exists. But they cost money and require an appointment to be rid of, on top of the investment of time, money, and pain to buy in. The barrier to entry and the barrier to exit are both too high for my liking.
Ideally you get a tattoo and enjoy it for life. I can’t commit to that kind of decision. Not for a funny body picture. If I need a memento to cherish memory of a thing or event I’ll get a tchotchke or something.
I have no complaints about others’ tattoos. They’re more often than not incredible works of art.
There are exactly three kinds of manpages:
I will take 1 any day over 2 or 3. Sometimes I even need 1, so I’m grateful for them.
But holy goddamn is it awful when I just want to use a command for aguably its most common use case and the flag or option for that is lost in a crowd of 30 other switches or buried under some modal subcommand. grep helps if you already know the switch, which isn’t always.
You could argue commands like this don’t have “arguably most common usecases”, so manpages should be completely neutral on singling out examples. But I think the existence of tl;dr is the counterargument.
Tangent complaint: I thought the Unix philosophy was “do one thing, and do it well”? Why then do so many of these shell commands have a billion options? Mostly /s but sometimes it’s flustering.
The first four of them are “just how floats work”, yeah. Has nothing to do with JavaScript.
typeof NaN // "number"Classic, yes, very funny. “NaN stands for ‘not a number’ but it says it’s a number”. But for real though. It’s still a variable that’s the Number type, but its contents happen to be invalid. It’s Not a (Valid) Number.
The next three are just classic floating point precision moments.
The
Math.max()andMath.min()ones are interesting. Seems that under the hood, both methods implicitly have a fallback “number” that it compares to any argument list you give it that will auto-lose (or at closest, tie) with any other valid number you can possibly give it, so when you give it nothing at all, they leak out. Honestly, makes sense. Kinda ludicrous it needs to have defined behavior for a zero-argument call in the first place. But JS is one of those silly languages that lets you stuff in or omit as many arguments as you want with no consequences, function signature be damned. So as long as that paradigm exists, the zero-argument case probably ought to do something, and IMO this isn’t the worst choice.Every other one is bog standard truthy/type coercion shitlery. A demonstration of why implicit type coercion as a language feature is stupid.