sjellis

Yes, it's about confidence levels.

There will always be known differences between staging and production, e.g. service names, networking.

The point about staging is that it lets you run risk-free tests on a set of things, in a way that give you confidence about the things that are the same as production. The fact that a set of things works in staging is never an absolute guarantee that it will work in production.

If you are in the position of needing to ship releases rapidly, and you can't run meaningful tests in the available time, then no, it's not useful.

> Mozilla's marketing portraying itself as the white knight of the open web is tiresome and contradicted by past behavior. Pocket is still installed by default, and remember the Mr. Robot scandal?

Here, the perfect is the enemy of the good.

Firefox is the only Web browser that is not owned by a giant for-profit company with a vested interest in controlling your computing platform.

Yeah, I would note that not only is the Bitwarden code Open Source (if you want to self host), the commercial service has a free account option, and the pay options are about $1 per month per person:

https://bitwarden.com/pricing/

I am very happy with Bitwarden as a product. It does everything that I want, and I like the UX better than the other password managers that I tried.

The fact that it is Open Source code that has been professionally audited also gives me an extra level of assurance.

IMO, Bitwarden is underrated as a password manager. It is fully-featured for personal use, easy-to-use, low-cost and is audited open source code.

This announcement addresses a major limitation of Bitwarden that was holding it back. It should also help with Bitwarden's other limitation: the company is currently very small, and needs to grow to reduce the bus factor.

I would say that it can be both. Large organizations like Microsoft have so many different people and teams that there isn't necessarily a group-think. On the contrary, different teams will have different priorities, and keeping people aligned is a really hard job.

The thing that bothers me about Visual Studio Code is that does conform to the general Microsoft rule of enabling telemetry by default. IMO, this is not good practice, and in some cases it seems to have been encouraged or mandated at a senior level. We should not have aggressive data collection in the world's standard desktop OS, or compilers baking vendor instrumentation into C++ binaries by default.

I really like VS Code, but am definitely wary of the way that it intermingles open source, proprietary code and remote services. For that reason, I use the VSCodium build most of the time.

You definitely need to take responsibility and read the documentation for each extension that you decide to install. You may be surprised.

I would also disagree with the article and recommend that you disable telemetry, unless you specifically decide that you want that copy of VS Code and those extensions to send data. I understand the value of telemetry data, but I think that turning it on by default is unethical: software should not be written to automatically transmit data to remote systems without explicit user consent.

This "open core" model has been used for a long time, and it might work for commercial vendors that have large products with a plugin architecture, but it's a constant source of friction and inefficiency. Not everybody can or will be able to pay, and introducing licensing and payment systems complicates everything.

To be fair, Raspbian is meant to support first-time users. They have explicitly said that they want to produce something that works for the widest range of hardware.

Competition is not a bad thing, but I'd definitely recommend that people check out Sourcehut.

Sourcehut ticks all of the boxes for a well-run project: Open Source, good engineering, sensible financial plan, excellent maintainer who works well with others, and constant, sustainable progress.

Sourcehut is also accumulating lot of support for niche things that other providers don't support at all: e.g. it is a Mercurial host as well as a Git host, and the CI supports BSD OSes.

Yes, this is one of the reasons that I decided to use Joplin: it's Open Source and cross-platform. I never want my notes to be locked to one or two platforms.

I would definitely recommend Weinberg.

Don't be put off by the fact that his books are self-published, and the covers aren't great. He is brilliant.

It has to be said: if Apple published their source code, we wouldn't have to rely on reverse-engineering and speculation.

IMO, the power of shell is really the ability to leverage command-line tools (e.g. git, curl, jq) with very little code. These tools are very fast, well-tested, feature-rich, and often easy to install in a reproducable way.

IMO, The inflection point where you should stop using shell is very low, though. The Google style guide for shell recommends that you should rewrite scripts once they are more than 100 lines, and I think that it probably too generous.

The only one that I found questionable was item 5, because they specify Puppet, which is a legacy server configuration system that is not particularly great for cloud anything. Ansible or Terraform would make far more sense.

Kubernetes addresses a bunch of infrastructure concerns, so IMO it's more equivalent to learning a new cloud platform (AWS, Azure) than anything else. People who already know one or more cloud platforms, and are familiar with the kind of issues that come up with distributed and HA systems on cloud (e.g. networking, secrets management) may find Kubernetes much easier.

> I can’t imagine we’re alone in the scenario. There is no way our small company could justify purchasing the enterprise licenses we routinely suggest our customers purchase.

This is probably the norm for smaller partners. You could use Open Source alternatives, or other cloud providers, so Microsoft have to offer a better or a more convenient package.

It's worth a moment to give credit to the long defunct Stateless Linux project:

https://fedoraproject.org/wiki/StatelessLinux

This was imagined a decade ago, but the technology and the market weren't ready then. I am really excited to see it as an actual product.

They are also adding per-application isolation of settings:

https://blogs.gnome.org/mclasen/2019/07/12/settings-in-a-san...

Flatpak is one piece of a broader design to secure Linux workstations. It is also intended to work in conjunction with Wayland and the in-development Pipewire. These lock down video and audio respectively, so that shared resources can't be misused by applications.

Manager Tools is amazing: the single best source of practical guidance for managers that I know.

I really like the concept of this book. Your choice of topics is interesting, because it's so ecletic.

Yeah, AppImages are not really comparable to snap and Flatpak, which both address this issue by managing shared sets of libraries as well as applications. Flatpak calls these sets of libraries "runtimes", and snap calls them "base snaps". The metadata for each application declares one runtime or base snap that it uses.

This ability to easily provide different userlands to different applications is one of the critical advantages of these new application formats.

The TinyGo project are implementing a Go compiler on top of LLVM, to use Go on very small devices:

https://tinygo.org/

The Go language is defined by a spec with compatibility guarantees, but beyond embedded systems and WASM, there don't seem to be a lot of use cases for alternate implementations.

Microsoft have been very good at figuring out which features they need to add for developers, but the actual experience of using Windows is not great.

Part of the problem is that they are adding stuff without taking anything away. My Windows development machine manages to be both overstuffed with multiple shells, run-times etc., and have quirks or issues with almost everything that I care about. I just want a Bash shell, Python, SSH and a package manager that all work.

Getting a FastMail subscription over a decade ago really has been one of the best tech decisions that I ever made. They are a great mail provider, and I am very happy that my money helps fund work like JMAP.

"The next best thing might be infrastructure that makes the deployment easier but no one's really interested in investing in infrastructure tech without some tangible reward."

Almost every OS vendor is investing in deployment and packaging, because it's perceived that users now expect either zero-install or app store experiences.

The issue is that most OS vendors are incentivized to make themselves gatekeepers and insert themselves into the delivery chain, for financial or security reasons. That always causes conflicting requirements. It's interesting to look at Flatpak, which is not built to privilege an OS vendor, versus almost anything else.

"Software as a Service is impossible to pirate and generates continuous income rather than a single upfront fee. That’s all you really need to know to understand why there is less and less desktop software coming to the market these days."

The other reason is platform control: there's continuous tension between the desire of each OS vendor to differentiate their platform and make applications part of the desktop experience, and the desire of application vendors to be able to deliver to any customer using the minimum number of platforms.

SaaS vendors will build mobile apps (1-2 platforms), and desktop applications in Electron (kind-of 1 platform) as service clients, but I agree that they are not incentivized to build local-first applications.

"Using a brand name in place of the actual name of the feature seems like going a step back to me."

It's a sign of massive success, too. Like "Hoover" now being a synonym for vacuum cleaner.

"I'm honestly confused at how much effort people spend on .vimrc and .emacs files to get poor versions of narrow slices of functionality that comes out of the box with the most basic of IDEs."

I think that it's the other way around: people don't want to lose the editing experience that they already have by switching to another environment that might have some other benefits. For some people, that means an environment that they've tuned to their own requirements over years, and for others, it's just the core interaction model.

For me, I like modal editing, and the Vim commands are now automatic, but I have no attachment to any implementation of these, so I use the stock Vim on CLI, and VS Code with the Vim extension everywhere else to get modern features without losing the aspects of Vim that I really care about.

I think that Buffalo is actually the most credible replacement for Rails that I've seen:

https://gobuffalo.io/

The lead developer is a ex-Rails developer with a very keen sense of what made Rails successful. One of the reasons that it's still pre-1.0 is that it won't ship until the plugin architecture is good, which speaks to the point of the article.

You don't need advanced syntax in the server code to write Rails applications, so Go may be a good fit for a Rails replacement.