Pretty sure Tim Cook has said before he does most of his work on the iPad; it doesn't seem like an unreasonable guess that too many of the C-suites do the same and don't use Macs enough.
> It makes sense to me that games on Series S get cut-back to enable playable performance, but I don't think the existence of a less-powerful GPU meaningfully limits the scalability of console titles on the bigger console.
It's not so much the existence of a weaker Series S that meaningfully limits console titles, but rather Microsoft's decree that games must have full feature parity on the Series S and X; they had to make a special exception for Baldur's Gate 3 to cut features on the Series S version entirely (split-screen co-op) for it to ship on Xbox at all.
The Series S exists as a way to try and entice people into the Xbox ecosystem by drastically undercutting the PS5 in price, but it _absolutely_ hamstrings the Xbox Series X because 100% feature parity is required between the two. We have literal proof it's why some games aren't on Xbox (or wouldn't be without Microsoft bending the knee and making exceptions), pretending it's not a millstone around their neck this gen is absolutely foolish
As someone who used to daily a Microsoft Sculpt and has tried the Moonlander... I would say it is much much more specific in who it is good for out of the box. If you want tenting but also don't have giant hands, it's not a good fit imo.
I don't think my hands are tiny, but because the thumb cluster is used as the tenting leg, in order to achieve a comfortable tenting angle, I had to give up using most of the thumb cluster because I simply couldn't reach it without moving my hand, which defeats the point. There are solutions to work around this (namely the tripod pucks or printing additional tenting legs), but it feels like a fundamental design flaw with the moonlander that should not be there given the premium price.
Also as an aside, I hate that they went with rattly as hell costar stabs for the red thumb keys, they're awful on a keyboard in this price bracket.
I'd really recommend something like the lily58 (there is a variant called the lulu that has tenting legs available) or if you're feeling daring with going smaller, the corne over the moonlander.
> VS Code has one as far as I am aware uniquely-implemented feature -- remote editing -- which is absolutely invaluable to me as a freelancer with many long-term, infrequently-updated projects.
To be that one guy, Emacs has had remote editing (without even needing to install anything on the remote server, unlike vscode) for forever with tramp mode. But other, more accessible/modern editors having it is definitely nice because it's such a handy feature
Everyone always brings up Emacs with regards to VS Code's remoting features, but I have yet to see anything that supports that it is anywhere close to VS Code.
With VS Code, I can develop across Windows, Docker, Linux, Linux running on WSL, and macOS with zero configuration aside from setting up SSH connection configs and installing the remote extensions with a button click. All the extensions work seemlessly when remoting. My settings also automatically sync by just signing into GitHub.
With Devcontainers, I don't need anything to develop except Docker and VS Code. I simply pull down a repository, open it in VS Code, and then VS Code sets up a container with all dependencies and configuration.
No, Emacs does not have this experience.
And I don't know the technical reasons why VS Code installs on the remote server, but I think it's important to note that you're not just editing remotely but developing remotely.
To also be that one guy, emacs has had this with the ssh method in TRAMP basically since ssh existed. (Not the devcontainer stuff, it has something similar, but it wasn't till LXC/Docker got popular that emacs could do it that way. At least on Linux) I agree, it's amazing and great that more people are finally using this methodology, but certainly not new to VSCode
Personally zero configuration is not a selling point for me for a professional tool I rely on to do maybe the majority of my work.
I think it’s reasonable to not hold hours or even days of setup and learning against a product I’d use in this fashion. Even a tiny 1% productivity benefit obtained after configuration and learning earns me about 2.5 dev days worth of benefit every year. And if I expect to use the tool for a decade that’s almost a month.
Even if emacs can handle the remote editing side I doubt the remote debugging experience comes close to what vscode can offer with very little effort.
I do all my development on remote supercomputers and the ability to remotely debug multi-process Python and C++ applications running inside containers across many servers made me love vscode.
I guess Tramp mode must be the inspiration, to some extent.
But the VSC approach allows me to customise the tool environment within the remote extension, including going as far as using different SCSS processors and language servers, but is managed through essentially exactly the same interface as the local.
(It's also inherently multi-user; changes are reflected in each machine connected to the remote, which makes it really easy to move from a work to a home machine, or a desktop to a coffee-shop laptop.)
This is what I meant by uniquely-implemented. I often find that the most visceral critics of VSC or adherents of "natively implemented" code editors haven't the slightest awareness of this feature.
Still -- thank you for your comment, it gives me one more thing to investigate for those times when tools fail me.
Yeah, I certainly didn't mean it as a slight against VSC. (I am very much an electron hater but VSC is an exception because they obviously put in the effort to make it work as well as it does.)
Much as I love Emacs I do mostly use VSC these days, and I do tend to forget the extent of what remote editing capabilities it provides since I haven't had much reason to use them in a while.
Yes -- sorry, my comment about critics may have come across as aimed at you, but it wasn't!
I was thinking more of all the other times this has come up in the past and I have to say, "you understand it's not just a text editor with network access?"
It has pretty much unique capabilities, and as another commenter has said, it's even remarkably agnostic as to the _kind_ of remote container. For example you can run the editor on Windows with the remote as WSL, and it really blurs the boundaries between them in a way that cannot possibly be a coincidence for Microsoft.
My god the increasing services push is awful; I used to be an Apple Music subscriber but left eventually because at launch it was a clusterfuck with personal libraries, just destroying metadata and deleting 'duplicates'. And I now have to use a 3rd party music app to listen to my local library on my phone because the system one likes to pop up a fullscreen ad for Apple Music what feels like every time I open it.
I like my Apple products but this services thing is truly destroying a lot of the good experiences they can provide.
I haven't maintained a Vim config in a few years now (more of an Emacs man now), but I do remember using Goyo in college. Looking back at it, I think it might scratch your itch as far as Vim plugins go, it even allows you to resize the area on the fly.
Goyo is one of the plugins I experienced as brittle and cumbersome. IIRC it creates the centered text area by creating 9 windows. The outter 8 to center the one in the middle, which is used to edit the text.
In my attempts to use it, that created a bunch of issues.
Funny, Firefox on Mac sure doesn't integrate with the native text to speech, or offer it's own without plugins as far as I can tell. Gee it's almost like all browsers aren't exactly the same
Having tried both Craft and Notion, I think your comparison is absolutely leaving out a number of factors in favor of the web-first solution.
Granted, maybe I have my own biases towards native applications, but to not list the performance and native system integrations as benefits of desktop over web seems criminal to me.
>- You code once, it works everywhere.
I realize this may be a controversial opinion, but this was a stupid dream when I was a kid, and it's still a stupid dream now. Write once, run everywhere means you write a piece of software that sucks everywhere.
>- There is nothing to install, no updates to download.
Ah yes, because everyone loves change. Especially unforecasted change right under their feet, with no way to revert to a previous version. No downsides here!
>But... Electron can provide all of that! So, it's mighty tempting to start with a web app and then pepper in some desktop functionality later by wrapping your web app using Electron.
It certainly is tempting, but the easy way out is seldom the right one.
It's a very common thing that I see Electron apps overriding or not implementing native behaviors. Right click menus, menu bar items, common global shortcuts, none of that can be taken for granted in an Electron app, but mostly comes "for free" in a native app. You can certainly get some of this in a web/Electron app by using native forms and fields and not writing custom CSS/JS monstrosities for everything, but that so rarely seems to be the case these days. Why is Teams so special the right-click menu shouldn't act like the right click menu in Explorer, or Firefox? Why does slack use a native right click menu for messages, and not one when I right click on a channel in the sidebar?
>Some of it is intangible like "feels more solid".
Some of these "intangible" benefits are certainly hard to quantify, but it can absolutely be a death by 1000 cuts type thing if behavior you're used to in literally every other application suddenly no longer works in an Electron app. For example, I have a global keyboard shortcut on my mac to Enter/Exit Full Screen mode. It doesn't work in Notion. Why? Because Notion (and other Electron apps like Slack) call the menu option something different. And yet... If I assign a keyboard shortcut to that different action, it works in Slack, but Notion just silently eats the input like nothing happened. Small tiny things like this are table stakes for applications feeling good, and when one application doesn't work like the rest of your system, it feels bad. This is absolutely exacerbated when you have a website as a desktop app because it's trying to trick you into thinking it's a real application.
Why do users no longer seem to care about desktop applications? It's because most of the people making them stopped giving a shit long before users did, and users are just rolling with the punches. No one is happy that everything is slower now though. Non-technical users may just not know how to explain why they're frustrated with everything.
