I started with this and still prefer it from a functionality stand point but the one use case where it falls apart for me is when you have an internet connection with occasional lag spikes.
This could be a variety of scenarios like working remote on bad ISPs or cellular or a crappy VPN but all that matters is when it acts up it will cause lag, or dropped connections depending on severity. Too many interruptions while trying to focus.
For this reason I keep everything local and use an rsync wrapper over my build system that streams output back. The added delay for each command disrupts workflow less than it happening during editing.
While air purifiers are a great idea I just want to put a warning out there about the current state of air monitors.
The current summary is that most of them are wildly inaccurate with false positives and you might just be better off checking your outdoor air quality from the EPA using their app.
Would love for someone to provide a better recommendation.
Gdocs doesn't go without it's issues. Switching from GSuite to Office365 made me want to rip out my eye balls. The online version of word is awful comparatively and depending on always having an installation of word doesn't work in all contexts.
Gsuite in general is accessible and works well for Collab.
And of course Teams is on a whole different dimension of pain.
While I think most people will agree it's not a dead end tech stack and their will be companies hiring for decades to come there's a element of truth here that isn't being discussed.
From what I can see Microsoft stack is used mostly by enterprises that are not engineering centric.
For all of the largest engineering centric companies that pay top of market only one heavily uses Microsoft....and that is Microsoft. Furthermore most VC funded startups also tend to shy away from Microsoft stacks. (Exception being parts of Azure compatible outside of the MSFT stack and other polyglot tools like VScode)
So while I don't think you need to worry about employability I wouldn't recommend investment in the stack to new graduates. Obviously my perspective is limited so I'm curious to hear counter points.
We vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.
Forgive me if I'm wrong but I thought supercomputer time was usually not allocated to embarrassingly parallel tasks. While they certainly can do those tasks well they're a waste of a distributed system with expensive, high bandwidth fiber connections between nodes.
When I spent (a relatively small amount of) time working with one this was the main thing the director drilled into my head. Use it to solve large, parallel problems that require lots of intranode communication of intermediate results. Embarrassingly parallel problems can be solved on cheaper hardware like GPUs.
The point of UBI is not to reduce the economic output of smart people. In fact, in some sense it could improve since bright minds could reasonably deal with loss of income while pursuing entrepreneurial endeavors. Think of all the smart people wasting their life in a do-nothing job for security that we could liberate to follow through on their best ideas.
At the same time not smart people or disadvantaged won't be ignored or fall through the cracks. Over time as productivity rises through automation we can ramp up the UBI and make sure all human life is valued and give people real opportunity. Even with a UBI that doesn't require you to work to live doesn't preclude a capitalist persuit of resources to make your most grand ideas come true. Let's just make sure we tax externalized cost appropriately.
Will some smart people choose to not work eventually? Sure, but if our automation can support them, who cares?
I think Yang came up with an eloquent phrase for this - UBI is capitalism that doesn't start at 0.
I think you might have missed the point of the article. In various different ways it says that machine learning is capable of solving many problems better than traditional software designed by a developer. It says that it's akin to a new software programming paradigm or language. From this context, right now we're still all working in Assembly or C, and higher level languages are being developed that will allow us more productivity if we continue to build out the tooling and infrastructure.
I don't think he's suggesting your OS is going to be an ML model, but we will be surprised at how many problems they solve better than trying to do everything in a more manual way. I think this is pretty intuitive. Our programs used to say "Move this byte to this register" but now they say "Toggle this button". Eventually they will just say "Learn to produce results like this" with the same reliance on the developers who build the infrastructure as we have today for our compilers and interpreters.
https://shield.ai/products/nova-class