Personally, I'm in the audience that that style works well on, but I can also see how it might be harder for someone to follow that style. e.g. if English isn't their native language. Similarly, I imagine that style is also much harder to localize (not just translate).

I think both techniques are great and I don't think they're mutually exclusive. That is, you can still inject flavor and style within the confines of a technical style guide. You just do so in a way that's less... flamboyant?

Even if you have to use the internet to do it, making time to talk (with your vocal cords) to a friend on a regular basis can be much better than mindlessly scrolling or reading endless news feeds.

What might be even better are various other social activities away from a computer. It doesn't have to be highly social either. Just being in a park or library with other people silently reading or feeding ducks can be a highly positive semi-social experience. Just silently enjoying a common experience draws way more connection than the various "social" media apps out there.

Yep, works great with non-proprietary docks vs even using a 3rd party dock on Switch has led to bricked units.

> Have you ever tried to use physical media with a Steam deck?

I haven't tried, but I'd be surprised if plugging in a USB optical drive wouldn't work. That'd be pretty silly though, but so are some of the Switch physical releases when the bulk of some games isn't actually on the cartridge.

I think the better thing to look at is DRM instead of specific transmission format. Steam itself is a grey area for DRM (some games are DRM-free IIRC), but you can also use things like Lutris... or generally whatever you'd like. Takes a bit of tinkering, sure, but a whole lot less tinkering than getting anything unofficial to run on a Switch.

> Have you ever tried to get 5 hours of battery life with a Steam deck?

Yep, works great. I'll still give the point to Nintendo because they prioritize battery life so much more, but if you aren't running the SD at full tilt with a large 3D game, it can get decent battery life.

> Have you ever put a Steam deck in your pocket? (I do have big pockets, but at least with the Switch Lite, it's possible.)

I would love a Steam Deck Lite or something. That's probably the biggest reason I keep my Switch Lite: it's easy to just toss in a bag on a whim while the SD (and other Switches) require planning to actually use them.

> Nintendo will be just fine.

Yup. They're probably still sitting on piles of cash from the DS and now Switch. People were saying Nintendo was doomed when the Wii U did poorly, but others at the time rightly pointed out that they've probably got enough runway to have a few more total flops of consoles.

> I personally will never use a platform that can kick me out on a whim, or could screw me the moment Gabe Newell gets hit by a bus.

Losing Newell is a valid concern (again, for Steam as a platform), but Nintendo is certainly an interesting choice to say they won't kick you out on a whim, given their track record of bans, lawsuits, and just being particularly litigious.

Metacognition, for all its benefits, comes with the newfound sisyphean task of being unable to intentionally avoid thinking about a white elephant for an entire minute. "Don't be influenced by the ads/media/propaganda" works about as well.

So perhaps the best way to reduce manipulation is to find a way back to sleep sometimes. A sort of meta-meta-cognition, if you will. It's self-awareness all the way down.

Of course, but if there's a game that I really would like to play, it doesn't matter how good some hypothetical version of it might be if nobody ever ports it. The quality of a nonexistent game(/port) is zero, no?

> There have been pretty much no native ports of big games since proton got pushed by Steam. All Linux game porting companies have either shuttered or switched focus to only Mac and mobile. > There were many more native releases in the period before Proton than now.

I suppose we are just in different circles of "big games". Before Proton, I can't recall the last time I saw a AAA game with Linux support. The occasional indie game had support, but that's still the case. World of Goo 2 just came out with native Linux support, for example. DRM free too, if you buy it direct from them.

> In a way where they can in the future publish changes that break the game on Linux without you being able to complain because what you bought is a Windows game.

This is the case regardless of native vs Proton. Just because a game has a native Linux version at some point is not a guarantee that an update won't break it nor that they won't just drop Linux as a platform outright.

> Absurd. There were plenty of native programs released before either compatibility layer.

And there are still about as many (in my experience) with both compatibility layers.

"Better" is always relative, so it's often more correct to say it is/sounds "different".

For example, a true temperament guitar can sound weird/"wrong" to some people. A lot of folks are used to those compromises just being part of the sound. Similar to a "honky tonk" piano: if you tuned it differently, it would come across as a timbre change more than simply "better" tuning.

In the grand scheme of things, there are professions and arts that were once considered essential to everyday life and in ways that we today don't even consider. The profession is lost to time, but so is the need. It's the in-between transitional state, where the profession is in the process of dying, that is the most painful period.

Some day, the last note played on a piano will be played and lament for the piano tuner will die with it.

Is it illegal for me to create a piece of art (i.e. a game) whose sole purpose is to demonstrate the fragility/absurdity of modern software abstractions by building it in some insane nesting of APIs?

I don't ask these to rhetorically imply that we don't need more regulation. I completely agree that there are online services that need way more regulation as they have become infrastructural.

These are all questions that we have to collectively (and not just programmers) discuss and decide where the lines are. It's not as simple as "force a set of simple as possible exe file format and OS interfaces."

Yes, a few game devs will drop native Linux support because building and maintaining just the Windows version and relying on Proton will be cheaper for them. Some number of them would have inevitably dropped native Linux support anyway. Take Rocket League for example. For most games, very few would have EVER had a native version for Linux. Source: the decades of PC gaming history prior to Proton.

Even with regular WINE being available, it's not like game devs were testing how their game ran in WINE. Currently, if your game doesn't work in Proton (and therefore the Steam Deck), you get an "Unsupported" icon on your store page. Getting that Deck Verified green checkmark is an actual economic incentive for game devs to support Linux in any way, even if that way is unsavory to some.

So, like Electron, the argument is less "Electron app vs native app" and more "Electron(/Proton) app vs no app at all".

Also, given that Proton isn't preventing developers from still offering a native Linux version, you really can't say that Valve/Proton are why those devs are dropping it. The developer is still choosing to drop native support.

I block ads at the DNS level and am not about to tweak things forever just to de-mangle my paid-for YT experience. So I dropped Premium, started supporting channels that I actually watch directly via things like Patreon, and watch YT videos via tools like Invidious and yt-dlp.

Local video players such as mpv and IINA are so much better than the YT player has ever been in any browser and I don't have to worry about buffering. The bonus is that I can keep a backup of favorite videos sans baked-in ads or whatever customer-hostile tactic Google dreams up next.

Just because transactions are "basic" doesn't mean they aren't also negative and, therefore, exploitative.

The bit about them not selling your information outright: the way that they sell those ads is based off of your information. The way that they do so matters, but not as much for this particular conversation: they are still exploiting your data regardless of the precise way that they package it.

Yes, you can use their services to get features and abilities for free. Nobody is saying that part is bad. The problem is that they have made it hard/impossible to go anywhere else if you don't want to use them.

The "company stores" of yore also made it particularly easy to get the tools and supplies you needed, but it was still an unfair trade. The fact that Google and Facebook make such massive economic profit off of something supposedly so worthless as personal data just doesn't add up.

Do any platforms require that both parties add one another? (And/or allow for restricting an account to such a mode)

e.g. if user123 and user789 wish to communicate, then user123 must add/contact user789 AND user789 must add/contact user123. Until both do so, then nothing happens.

It's more work to legitimately establish contact with someone, but that seems like it pales in comparison to the effort produced by spam/scams.

Same thing with verifying identities. In order to actually establish proper contact with someone, you need to communicate with them via some outside means (ideally in person) in order to establish the connection. Requiring both parties to enter/scan some ID/code/whatever seems like it would only facilitate proper verification (though not guarantee it, of course).

I'm sure that I'm missing something, though. I assume I'm just not familiar enough with these platforms and that some/all of them provide such a feature. It's just odd to me that spam sounds like such a problem when it feels like the above solution would be highly effective and simple to include.

For example, if you search for ["foobar"!g] (without brackets), you will not be redirected to Google, but you would be if you did ["foobar" !g].

For example, even if a corded $THING costs as much as its cordless counterpart, with the cordless one, I have to think about things like:

- Charging schedule

- Whether the device is draining battery when I'm not using it

- How long before the battery needs replacing

- How much a replacement battery costs

- How to dispose of the battery when it needs replacing

- Whether I'm even able to replace the battery

- How well the device functions without a battery or with a dead/dying one

Without going down that particular rabbit hole, things like right to repair attempt to help with some of those things. However, the corded version avoids all of them categorically.

So it's not that I'll never buy a battery-powered $THING again. Just that I really try to consider all of those "hidden costs" before choosing instead of just rather-blindly going with the battery-powered version (like I did before). In other words, having a battery installed in a device really needs to provide a consistent and realistic value for my personal use case before I'd choose it over a corded version.

If we ever create a battery with effectively infinite recharge cycles, then my stance might change, but I'm not holding my breath on that ever happening. For several reasons.

Also, I started using vim basically at the same time I started using Linux and really learning to program. There were plenty of other editors and IDEs around at the time. Even for the languages I was learning. I still use vim, but not those editors.

I will break vim into two parts: its philosophy(s) and its technical implementation. I think both are valuable, but for separate reasons.

First the technical implementation

Because I've been using vim for so long and from such a foundational stage for me, vim is largely just how I think about editing text now. Not just insert vs normal mode, either. Vim includes a whole host of features for editing text. I've been using it pretty regularly for many years now and still learn about new features. The rabbit hole is huge.

To the point that I find a lot of plugins either re-implement built-in features or outright go against the philosophies in vim (more on this later). Personally, I spend as much time (or more) trying to remove plugins as I do trying to find new ones to solve a need.

Plugins have better SEO, but worse integration with the editor, on average. Because of this, I might use a plugin for a bit just to solve a need, but then upon reading up on vim documentation (some of the best around), I might find a way to do something better than my current plugin-based way.

A frequent example is when I need to open a file that doesn't have built-in highlighting support. Instead of adding another plugin that might include more than just syntax support, I might really just need to alias it as another language. e.g. Jenkinsfiles are mostly just Groovy, so the following line is all I personally needed to make editing Jenkinsfiles in vim acceptable [0]:

au BufNewFile,BufRead Jenkinsfile setf groovy

None of that is to say "don't use plugins". Some people use hundreds of plugins, others use zero or very few. Both are correct. Personally, I still think that it's really easy to get carried away with plugins in attempts to try and turn vim into vscode or an IDE. If that's your goal, save yourself a ton of headache and just use vscode or an IDE. Truly ask yourself what it is you are trying to achieve with vim and work towards that, not feature parity with a completely different piece of software. [1]

Probably the biggest watershed moment for me was learning to use vim's buffers to manage multiple open files instead of always using vim's tabs. It has tabs, but they are a different metaphor from "tabs" in most editors. That still resulted in me adding a plugin to display open buffers at the top of the view, but that is an incredibly simple plugin that augments built-in vim functionality rather than try to shoehorn vim's tabs to work like tabs in other editors.

Getting a bit more philosophical

If you'll pardon a somewhat-forced metaphor, vim is a box full of handtools, not an all-in-one power tool. Each one can accomplish the vast majority of what the other can do and neither is inherently better than the other, but their ways of doing so differs greatly.

In particular, vim (like handtools) expects you to learn how to use it. It expects you to not only read the manual, but to keep referencing it and gradually learning new techniques for doing things. It expects you to sharpen it. It expects you to oil it. It will cut you if you abuse it [2]. This is also true for the power tools and other editors, but the whole point of using those is that your expected learning and maintenance is greatly reduced.

The payoff for those years (yes, years) of dedicated learning, at least in my experience, is that you will have a closer understanding of how the tool works. You will gradually develop a sense as though the tool itself has wants and needs. To be entirely too romantic, it is a symbiosis. Again, the way I think about editing text is in vim's commands and metaphors [3].

The other reward for that time spent is that vim doesn't really change. Sure, it's still updated (thankfully) and gets new features, but it is glacially slow to really change anything fundamental. This is often cited as a bad thing, but I personally love it as it means I can depend on it. I don't have to worry about my tool changing out from under me. That is rare in software, especially these days.

Sometimes even a master woodworker might still need a 3D printer, but having mastery over a hammer and chisel can pay dividends.

[0]: That line creates an autocommand for whenever a file called Jenkinsfile is opened or read, set its filetype to groovy instead.

[1]: There is an old article called Linux Is Not Windows. It's been a while since I've read it, so I might not agree with everything in it, but it presents a really great point: the only way Linux can be better than Windows is by being different. That means you will have to change your mindset before you understand it and/or like it.

[2]: Pretty big stretch here. It's not buggy and won't really do damage. I really just mean "cut" as more of "will be slower/harder than it might be otherwise".

[3]: I should point out that, while tools like vscode have plugins and settings to emulate vim's commands and a couple of modes, I have always found those lacking for my needs. I hope it's clear by now that vim is far more (to me, at least) than just using hjkl to move, dd to delete a line, etc.

Not to mention, you'd also need a really effective solvent for resin that doesn't also happen to be a solvent for whatever the mosaic is made of. Perhaps the mosaic is made of resin beads.

All that being said, it's virtually guaranteed that a valid attack on these methods exists. There's no such thing as perfect security. It's always a case of evaluating your threat model to make security attempts that thwart a constantly moving array of types of attack.

I see it frequently cited as always meant sarcastically/disingenuosly. It certainly can mean "screw you", "go away", or "... so much fail".

However, if there's one thing people should understand about southern/NC etiquette, it's that passive aggression is the primary form of aggression. There are plenty of southerners who would never tell you to GFY straight to your face. That doesn't mean they aren't thinking that and trying to say that, though. Perhaps even with a "bless your heart".

Given all of that, "bless your[/their] heart" is absolutely to be taken at face value about as often as it shouldn't. That level of plausible deniability provides the highest level of potential passive-aggressiveness.

I can't speak for absolutely everybody, but at least if someone from eastern NC says "bless your heart", they could mean anything between "GFY" and "I'm so sorry that happened, please come to my house so that I can shower you with hospitality". You might never know which they meant, and that's intentional.

That doesn't preclude the people within the corporation from having malice for you, though.