Very happy about this move. Nuclide’s remote development capabilities were way above anything else I’ve tried (Sublime, IntelliJ Ultimate, VSCode, remote SSH mounts, etc).
It’s the only solution I’ve found that really allows you to browse the remote filesystem as smoothly as you would with your local drive (including when you’re also changing the remote files outside the IDE), degrade functionality as needed when the connection isn’t great (using caching appropriately), and immediately recover when it comes back. The only cost to pay was a bit of setup server-side (installing watchman and opening a port, if I remember correctly). I really hope they can bring the VSCode experience to the same level!
What is missing from vscode for remote development? MS released their remote development extensions earlier this year, and everything from browsing to searching feels native.
Do you happen to know if it works for vagrant VM's? Because having a file system mismatch (symlinked dependencies in vm, IDE doesn't recognise them) is a bit of a pain point for me right now, it would be really fantastic to find a solution within VSC.
Not sure, but it works by storing files on the remote server under ~/.vscode, and this is where all the normal code files are stored. When you connect to a remote system it loads these files over ssh.
Yeah, same rxn. I tried vsc's remote dev stuff to try pair-programming w a friend in another state, and was surprised and delighted at how well it worked. It was effortless and frictionless.
Indeed, I remember trying to switch to IntelliJ locally (with SSHfs on the server), a couple of times and always going back to Nuclide because of the lag with sshfs, whilst working there. Nuclide had a lot of problems, but good support for remote dev wasn’t one of them.
From what I've used internally, the remote development bits are already better than they were under Nuclide. Adding and managing multiple remote repos/working copies is a breeze.
Dired/Emacs has already had everything you're talking about for a long long time. There is even support for remote "inferior shells" in Emacs - notably for python.
If you're concerned with how guilty each individual consumer in a country should feel look at per capita emissions. If you're interested in stopping climate change effectively look at total emissions.
Well if you're concerned with effectively stopping climate change a quite important part of your calculation is where you can actually persuade people to address the issue. That's a complex calculation, but I think it's far more credible that you can get the policy supported in the US and then enforced internationally through treaties and negotiations with the support of Europe than trying to do a tour persuading China.
It’s certainly notable how she never directs her anger at China or India, but reserves it for Western countries only. She has a very white-centric view of the world.
Multiply the per-capita numbers by the sizes of the country and you see that in terms of total emissions China is the most critical player. Worse, per-capita emissions are strongly correlated with consumer buying power so the more China's economy grows the more it's per-capita and total emissions are likely to grow.
It's important to reduce emissions everywhere, but China is the key player to watch.
I assume you're looking at overall CO2 emissions rather than per-capita emissions.
I’m looking at the page I linked. Per-capita is basically irrelevant, the issue is the total emissions under the control of any one government. Or should China not act until they match the US per-capita but with 3-4x the population?
Further the US and European trends are already downwards. China’s is dramatically upwards.
> Further the US and European trends are already downwards.
US CO2 emission trends are downwards because the US stopped burning coal. In the same time, they've switched to natural gas produced by fracking. Fracking leaks methane. Taking methane and CO2 emissions together, US greenhouse gas trends are stable and not downward.
> the issue is the total emissions under the control of any one government
Total emissions definitely matter (no need to give speeches in Palau even if per-capita emissions are much greater than in the USA), but considering this number without regard to the population size is completely unrealistic and insensitive.
For China's overall emissions to get to the same level as the USA, that means a Chinese citizen would be expected, on average, to emit less than half of what a US citizen emits.
Would you expect a Chinese citizen to only eat half of what a US citizen eats, just because there are more people in their country ? Of course not.
China's trend is dramatically upwards because a big chunk of the population is still getting out of poverty. Of course CO2 emissions are increasing.
The ecosystem doesn’t actually care whose feelings are hurt, you know. It’s a weird argument to make. China is the single largest emitter of CO2, plastic waste in the oceans, etc etc. Yet we expect them to do nothing about it until 2030 at the earliest, but just stay on their upward trend. Which is about the same time as the ecosystem collapses entirely according to AOC. But we mustn’t be “insensitive” about it!
Well I suppose they could split their country, that would lower the emissions of the individual parts and might bring them down to the US level easily.
(Not that they'd be interested in that, but still.)
Definitely depends on the platform. On Linux it's probably great, but on macOS at least, I've yet to see a GTK app that doesn't feel super clunky. GTK breaks lots of expectations about how things should behave on macOS (shortcuts, standard menus, buttons, etc). Gimp or Inkscape are good examples. On the other hand those are examples of what a "native" app is expected to look like:
This is something I've always wondered and still can't find a good answer to: why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps? Are the official Apple frameworks just that easy and pleasant to work with? I hear devs complain about ObjectiveC all the time, so it can't be their language choice. Or is it another example of Steve Job's reality distortion field, but applied to the entire MacOS application developer community?
why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?
One is developer culture. Going all the way back to the earliest Macintosh days, Apple has always had detailed guidelines about how the one true way a GUI app should look and feel. And the importance of following those guidelines gets drilled into you from your very first Hello World program. This leads to all apps on macs to look both good and consistent, giving developers a lot of inspiration to draw from when they write their own apps. Windows and Linux simply doesn't have this culture ingrained into its developers. It also helps that Apple really only has one GUI framework at a time that it pours all their effort and focus into while Windows and Linux always have at least 2 or 3 competing frameworks that never get quite the attention they need.
Another might simply be financial incentives. Anecdotally Mac user care more about what their apps look like than Windows and Linux users, thus the financial incentives to put in the effort to add the final polish to your apps is higher, since it probably affects sales much more than it does on Linux and Windows. Also (and equally anecdotally) Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
> Apple users seem far more willing to pay for small useful applications from indie developers so more indie developers put more effort into producing small useful and beautiful apps for Mac.
This rings true to me as well, but why is this the case? If we roughly assume that Mac users are 1 order of magnitude fewer than Windows users, they must be >1 OOM more likely to pay for these kinds of apps to generate this impression.
I struggled with this puzzle for quite a while when I switched from Mac to Windows. Utilities are simply not comparable, either in design, functionality, or simple quantity, for a market which is (on paper) both much larger and much older (if you restrict your view to the OS X era).
As an aside, it totally makes sense to me why Linux utilities are numerous and awesome, but have (usually) poor graphic design, because that Bauhaus-esque function over form describes how I prefer to work, too.
> This rings true to me as well, but why is this the case?
Because the Apple macOS ecosystem already has an coherent design at the point where I (as a macOS user) would hate to bring another app that breaks the coherence.
Also Apple's official apps are generally much better than the MS ones or Gnome ones (see IE vs Safari) which makes the expectation of users higher.
IMO Apple really made a great, healthy ecosystem around the macOS.
I suspect a lot also has to do with the business opportunities available for developers on the different platforms. First of all, there is a near-limitless number of companies out there looking for Windows desktop developers to work on various inhouse apps.
Secondly, there is a lot more money in the business and specialist app market for Windows. I worked for 3 years at a company developing a Windows application. We charged $5k a year for a license plus a good 50-500 consulting hours to adapt the application to our customers business. That was a solid business targeting a niche market, and there are countless companies like that around in the Windows space. Those opportunities don't really exist for Mac developers. Most people specializing in Windows desktop development end up working on stuff like that if they don't end up at Microsoft/Adobe/Autodesk etc.
If I was to start a company trying to develop desktop applications for Windows there is no doubt I would target business customers willing to pay $1k-10k rather than trying to sell $10-100 to consumers. If I was targeting Mac users I would probably target the $10-100 consumer space.
> "... why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?"
While that was the case ten years ago, honestly the macOS app ecosystem is mostly running on fumes at this point. There's few people coming into AppKit development, and iOS developers seem to have an irrational fear of putting any effort into learning the desktop paradigm even though the API is largely the same.
Apple is making half-hearted efforts to fix this problem by introducing two new GUI APIs on the Mac. "Catalyst" is a porting layer that lets you put iPad apps on the Mac desktop. The look'n'feel of these apps is pretty much as clunky as you'd expect. Then there's "SwiftUI" which is a new React-like runtime that spans all Apple platforms. SwiftUI is in its early stages and will take years to catch up with AppKit's functionality.
At this point Mac desktop development is effectively in a limbo: no one wants to start new AppKit projects because Apple is strongly implying that it's deprecated (although they don't seem to know exactly what it's being replaced with). So it's pretty much Electron or Qt on the Mac now, unfortunately. As an AppKit developer since 2002, it breaks my heart a bit.
> honestly the macOS app ecosystem is mostly running on fumes at this point
I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s. There's significantly more Mac users now, and there's orders of magnitude more developers with experience developing for Apple platforms.
Maybe most devs won't venture outside of iOS to try Mac development, but 10 years ago the few long-time Mac devs were (by necessity) putting their Mac projects on hold to work on iPhone apps.
> because Apple is strongly implying that it's deprecated
Lots of iOS developers are writing blog posts claiming things like this, but every single Apple app on the Mac is written using AppKit. You can't deprecate the technology behind your entire platform.
Maybe 15 years from now SwiftUI will have replaced AppKit as the dominant way to write UI code on the Mac, but generations of apps will be born and die between now and then.
> "I don't have data, but there's no way that the Mac developer ecosystem is worse off than it was in the 00s."
I don't have hard data either. But ask any old Mac developer on Twitter whether they're doing better now than ten years ago, and I bet a majority would disagree.
For one thing, the rise of mobile app stores has destroyed the perceived value of software. A $50 app now seems very expensive to most, whereas it was mid-priced back in 2008. Yet the Mac App Store has failed to bring in the mass audience that would compensate for the lower unit prices.
> why are MacOS apps so damned beautiful and plentiful compared to linux and windows apps?
This is entirely subjective. Several of my colleagues use MacOS and I find their interfaces overcrowded and clunky compared to my minimal linux setup. What is "plenty" to some, is "clutter" to others.
You've not seen the Linux desktops of some of the guys in our Unix Ops department. If you're allergic to clutter, you'd have a seizure.
I can't criticize. I paid for every square inch of the screen of my 27" iMac at home, and darn it, I'm going to put something on every last one of them.
While I respect your opinion and personal taste, it is not shared by the majority of app users. If it was, linux apps would dominate and webapps wouldn't.
I think it's mainly the macOS widgets that look good, thus making it easy to build a good looking UI out of those components. You can't make a nice looking UI if the very building blocks you have to build that UI are ugly.
> Not sure it has much to do with the developers at all.
Harsh but fair. I keep thinking that if we just make good app development easier, we could bring some of those well designed apps back to the native desktop instead of losing them all to the web. The reality, as you pointed out, is that the underlying technology is irrelevant. This is a marketing issue.
> Are the official Apple frameworks just that easy and pleasant to work with? I hear devs complain about ObjectiveC all the time, so it can't be their language choice.
I've found the former to be quite true, though QT comes close. I actually quite like ObjectiveC, but Swift is clearly superior and has had great uptake in the iOS/macOS community.
Well in Finland you get a discount if you have committed crimes before.
There are cases when a person had raped someone and during a leave from the jail he had raped an other victim. The jail term for the second offence is less than usual due to the first sentence still not being fulfilled.
Yes, in the US and most of continental Europe, multiple charges are usually first summed, then sentence determination is done by court order and then penal enforcement rules kick in after the verdict (2 years sentenced does not always mean 2 years served). A 1000 years' sentence has a greater non-parole duration than a life with parole; it is likely that he will serve life with no parole.
IANAL, though.
At least in France, this article says that for similar concurrent charges (not sure how similarity is determined), the most important sentence is picked. So, max instead of sum.
It’s nice to see a bit of Safari love around here. Some sites occasionally break, but I really like the macOS/iOS integrations. SMS code autofill on desktop Safari (via Mac <-> iPhone communication) is pretty awesome.
It’s nice to see a bit of Safari love around here.
The one thing I cannot stand is that fucking URL/search bar (I detest these things in general, but Safari has the worst implementation). Most implementations (e.g. Firefox and Chrome) will encode the space and go on their way, meanwhile Safari translates a space into a search unconditionally — because clearly I want my wikipedia viewing history to end up in my search history FFS. I'm also not a fan of view source opening in a dev tools frame versus a new tab/window like Chrome and Firefox.
Speaking of the dev tools, I was just poking around and saw this in the console:
Interesting as I'm running uBlock Origin (which is, admittedly, more neutered on Safari). I know I've disabled that prefetching before, but I no longer see any options to turn it off. Speaking of UBO, Safari loves to claim UBO will increase energy consumption and slow down my browsing (HA). I wonder if the "disable plugins to save energy" option means that Safari will kill uBlock whenever it feels like. :/
>If they already have your phone, you're already pwned.
No, that's not what GP means. If the attacker manages to get malware on the Mac, for example by exploiting a browser 0day, then the attacker can simply circumvent the 2FA by making the Mac fetch the 2FA code. The user won't notice it.
Or just remote drive your session. Token exfiltration isn't required if you can do XSS or say script injection via browser extensions (and exfiltration is more likely to hit anomaly/fraud detection)
I noticed this the other day and was very pleased.
Also, if you have touchID then you can use it on safari to autofill login credentials. I just wish safari had an active plugin ecosystem like firefox (or chrome) does.
When my bank sends a login token via SMS, Safari can also copy the token out from iMessage and autofill the value - which is quite convenient, but also a little too much for my preference.
If you just want to compile a TeX document without drowning your hard drive, I heavily recommend Tectonic (https://tectonic-typesetting.github.io/en-US/), which behaves more like a typical development tool.
On macOS:
brew install tectonic
tectonic mypaper.tex
This will automatically download the exact set of packages needed to compile the paper, and cleanup any intermediary files generated during compilation. And it's trivial to upgrade and uninstall.
Note though that this Tectonic is based on a fork of the tangled XeTeX sources (i.e. not the actual WEB source code but the machine-generated C translation) as of some past date. This is a very weird choice probably due to the author (understandably) not being able to make sense of the mess of TeX sources to figure out what's the actual source code. As a consequence, already it has begun to diverge; for instance it does not contain the \expanded primitive that was added to XeTeX last year. Overall, Tectonic seems to have many good ideas, but suffers from being not too familiar with TeX itself and the TeX ecosystem.
#/media/File:Transmission_v2.92_on_macOS.png){kind=link}
[1] https://en.m.wikipedia.org/wiki/Turing_test