I think a lot of people in enterprise environments do.
36 karma · joined August 4, 2013
But long before that, I believe there will be other noticeable effects. As someone working in a medium sized European company, with substantial investments across private infrastructures, AWS, GCP and some Azure, I can testify to that since last couple of weeks the Public Cloud Exit strategies around having services being prepared is a very hot topic. This concerns both existing services preparations as well as enforcing standards and configurations for new services.
Claude does seem to be explicitly blocking people living in GDPR jurisdictions to sign up. I don’t know what to make of that, but this statement from the first paragraph rings false.
Likely problems like these could be overcome, but preparing better input would probably not address the root cause of the problems with Siri.
> We have no reason to believe that the exposed key was abused and took this action out of an abundance of caution.
This is not verifiable, right? As the authentication method has no public and required revocation source, and given that the key, if having leaked, likely will be acquired by an authoritarian government, they can selectively MITM organizations and users that are not aware of this blog post.
As an example [of the contrary], I noticed Swedish Klarna among the partners that OpenAI revealed when announcing their plug-in API today.
Do you mean Google or GCP? We don’t see complaints about AWS because Amazon closes Dash buttons or Spark, and also Azure is not seen in any worse light due to Microsoft discontinues Skype and what not.
Can we name one remotely popular service of GCP that has been shut down at all?
How unacceptable.
This sort of implies that cash registers must be connected online to the tax authority or some governmental function in order to operate. That is simply not true.
As a minor detail but nonetheless I think makes a difference, the name of the other language was "Go!", not "Go". That makes the similarity in line with C#, C, C--, C++ and F, F#, F* and several others. Yes in some cases these languages are inspired by the others and in some cases not.
As someone who frequently talks to colleagues across timezones that are -9, -2, or +3.5 hours from me, where each of these have different dates for summer time, or don't have summer time, and meeting recurrences gets skewed etc, I don't see how asking about the current time off a location could be seen as "pretentious".
Still, my concern is that this is no longer a function of the technology, but by a service that is maintained by one company, limited to the coverage that they provide in different parts of the world.
At the end, the Kubernetes solution neutralized the choice of cloud vendor, at least from a software release and management point of view. From a security, availability, latency and a few other aspects the choice of cloud provider became less of an issue/equal challenge.
We have faced a few minor challenges when using Kubernetes. The knowledge barrier; The problem, as well as the beauty of Kubernetes, is that it takes on quite a comprehensive view of network management, service discovery, DNS management, deployments, container orchestrations, secrets management, system administration and much more. We use this as an opportunity for learning more than we see problems. But several roles (in the enterprise) need to come together on a pull request for a change, rather than having tickets and side projects. Switching to new features, like RBAC, TLS policy for AWS ELBs and generally keeping up with new features is another. The mostly excellent documentation has helped a lot.
Using Kubernetes, we noticed that latency of using the service was slashed to 50-80%, depending on the location of the end-user. This, however, we attributed more to the ability to roll out in more regions and auto-scaling. Of course k8s is not alone in supporting this, but it really comes out of the box.
A second effect we noticed was that by integrating the releases via Kubernetes, we reduced the time from the point of being ready in system test, to be passing our Release Readiness Check (yes we are an enterprise), and have user acceptance test environments and production environments being provisioned using about 15% of the manpower of our previous processes, and having releases being available in minutes and not in days (weeks), with enhanced visibility and maintainability. As an example, having the possibility to easy tear down or upgrade projects, with the right security and scale at all times (and no lingering volumes, load balancer pools or firewall rules)
For us, Kubernetes has brought a higher predictability of releases, and monitorability of the total solution. We did also switch a solution from one cloud provider to another, and might switch back. For the move we needed some labeling of services and management (referencing) of certificates.
I18n, not that important. I.e. likely your target audience is familiar with English. L10n, more likely to be needed for the ability to use a service.
As a European user, I need at least: (1) Have weeks count as starting on Mondays. (2) Have ISO-8601 / rfc3339 date and timestamps. (3) Decimal point and (4) 1000 number separators localized, time zone indicators, (5) UTF-8 support.
I reserved port 63 for whois++, that by the way rests fine where it is, in very few people's memories, during the same era. The motivation went something like 43 for whois protocol, 53 for ns, so 63 looks like evolution, though there were no aspirations to replace the name service protocol.
Certainly, in my experience and where I currently am, most of the texts that are published externally receives good editing, but many communications and documents are not, and 90% of the documentation is for internal purposes. This guide might just make the documentation a bit improved and more fun.
Also I appreciate the details about appropriate use of "$" or "#" for prompts, to name one. That is the way one would expect since at least the days with Bourne shell in the 80s, but I have not seen it spelled out.