It's not about being profitable. They could even maybe launch it below cost and that might help people even if it costs them. The parent talked about marketing. And people using something and benefitting from it, and then recommending to others is probably one of the best forms of it.
The optics are bad if you try to profit unreasonably. Launching something to help people become more productive, and making reasonable money out of it doesn't have bad optics.
There are plenty of firms not terribly worried about the optics right now.
I don't mind naming one particularly gross one - Knightscope is busy spamming about how "Security robots are immune from disease and work 24/7". I'm sure they practiced defensive patter about resilience until they could say it without smirking.
Without knowing much about the team I really doubt this has much to do with remote work. It seems like a smart move to take pressure off team deliverables in general right now for a host of reasons.
It's a mix of many things. Our teams all working remote for the first time and dealing with the same issues all people are dealing with. And then also at the same time if we put pressure on external developers with breaking changes or new bugs then it doesn't seem the right thing to do for users and developers at this time.
Local schools are leaning heavily on chromebooks. They have checked them out to students without computers. Adding an os update to this would contribute to the chaos.
Except when they move the launch bar from here to there or hide scrollbars or make any of a million other changes that cause your screen to no longer resemble the screenshot you're trying to learn from.
I updated a couple weeks ago and every tab was discarded when I tabbed away, reloaded when I tabbed back. It's better now. I can only imagine the problems that would cause for a school with a couple hundred of these checked out.
install session buddy from the chrome web store. it saves your tabs automatically, & even restores sessions containing a mix of tabs & web "apps" accordingly.
Provided they go right. If the entire team is adapting to a new way of working it makes sense to hold off on new releases while you make sure you've got everything working right.
IIRC my school district (in WA state) pinned Chrome OS versions for a long time because the state standardized testing software required a specific Chrome version. Not sure off hand if that's still a problem.
Stress can impact the human immune system and reduce our ability to fight off an infection, on that note alone it's worth adding some more slack to these important but not truly essential releases.
I switched my local "lab" setup from minikube (which was in use for a long time) to kind recently. The main reasons were
None of us run on Linux which means we're all using VMs for our containers and we all use Docker Desktop for various things. That meant we're running extra local VMs for no good reason. With kind I can just use the one vm for all the container things.
But the real reason for the actual switch was I just kept running into things that minikube couldn't do and Kind could, as well as having things I had decided to ignore like the fact that minikube does everything on one node which is 100% unnatural for kubernetes and I had multiple cases where this setup blinded me to problems that would occur in a real cluster.
3) I've also found I prefer the configuration/customization approach of kind over minikube though admittedly that's kind of a small thing.
Ultimately I find kind is a better simulator for the purpose of prototyping future cluster changes as well as use as a local "lab" for diagnosing services in a "production like" environment 100% under your control.
kind was originally built for developing kubernetes itself, as a cheaper option for testing changes to the core components.
it wasn't really meant to compete with minikube et. al, but complement for differing usage, but you may now find it useful as a lightweight option with a slightly different feature set.
it's also the only local cluster that is fully conformant as far as I know, because conformance tests involve verifying multi-node behavior, at the time minikube did not support
- building kubernetes from a checkout and running it
- docker based nodes
- multiple nodes per cluster
These days they've gotten more similar, we're both shipping docker and podman based nodes.
I think one of the most interesting things about kind is that the entire kubernetes distro is packed into a single "node" docker image, it's very easy to work with fully offline.
I really wish you had used a regular service definition when testing KinD. The omission reduces the usefulness of your comparison. I want to choose a local k8s cluster that is as close to production as possible. And I want my local deployment configs to be as close as possible to production.
You say that "ingress in kind is a little trickier than in the above platforms" with no explanation.
For me, use Docker if you want k8s started up every time you start Docker, and easy ingress. I don't love having a cluster always running, so I'm keeping the k8s function off by default.
Use kind if you want multi-node clusters, and a production-like simulation of your environment.
Use minikube for a straightforward dev experience, where you have control over k8s version, resource allocation, and don't need meaningful configuration of the control plane.
That is pretty neat but it is nice to have a tool that had it built natively, rather than having to search through 30 different provider flags with Minikube. Hopefully there documentation has gotten better but I'd generally trust the innovation behind the Kind tool than the Minikube devs who are late to the game.
you can simulate multiple nodes for example, if you want to experiment with node selectors or test having a multi-node setup, it's quite easy with kind
I tend to recommend minikube to new comers as it provides easy addons like ingress, image registry, load balancer via minikube tunnel. You can run minikube with 2GB
Easy when only dealing with one node.
Once your familiar then I will recommend Kind when you need more than one worker node and test scenario that require multiple nodes or if you know your way to install and configure addons yourself
Yeah I can think of several times when I or someone else came prepared to a remote meeting with a PowerPoint. Of course that took more work, but the product would often be reused and shared long after the meeting. Not only that, a higher quality work conveys the idea much better.
Indispensable for who? Perhaps designers? As an engineer I spent 5 years working remote and this has never been an issue. We just never needed—or even considered—drawing things.
Even now that I’m not remote all we use the whiteboard for is bulleted lists which easily can be done with notion or google docs
I'm a software developer and I always find that grabbing a whiteboard and drawing diagrams or other such information is very useful when trying to agree on a solution (or even agree on the problem). I work remotely and very rarely see the rest of my team in person, so the clear benefit (to me at least) of in-person whiteboarding in those situations is very stark.
Yes, you could probably accomplish the same thing by writing up a proposal spec document (which you'll need to do eventually) but the downside of doing that during the drafting stage is that it lengthens the feedback loop and not everyone will read such a document thoroughly and leave a thorough review. In-person whiteboarding is usually much faster and everyone in the room is almost always on the same page.
Disclosure: I am the lead developer for the team that builds the 1Password CLI.
You're completely right about the use-case there. One of the things I think we missed the mark on was choosing to expose the full item JSON structure as the default. I think it is important that access to the full item is available, but I think it would have been a much better user experience if we had abstracted that in the default case.
What you've pointed out here is what we are currently working on addressing. Development of the CLI was put on hold for over a year while development of our SCIM bridge was ongoing (they're built on the same codebase). In the past few months, we have ramped up the entire team, and movement has accelerated greatly on the CLI. This is feedback we're well aware of, and we're working hard to address it.
Feel free to post in our discussion forums if you're still willing to have a more extensive conversation: https://discussions.agilebits.com.
Really happy to hear you are working on it. FWIW your products are so fantastic I'm definitely more critical than I would be if that wasn't the case. I hold 1Password to a super high standard.
I'll give it a spin again too as it's been a while since I tried it last and check out the forums!
I think it's a consequence of their internal data type not being specific to passwords. You can store some semi-freeform data structures in 1Password's database (e.g. notes, documents, account numbers, security questions, even binary files).
On the plus side, they did get a bunch of funding recently so hopefully they'll be able to devote some resources to it. They definitely seem like an organization that is pretty devoted to quality products.
