natbobc

It’s typically called notarization but in North America it is often supplemented by a witness depending on the class of document. Many documents don’t even require that.

Had an acquaintance that worked in strategy have to explain something similar for the Netherlands. They thought they could just cut everyone and be off the books no repercussions.

I’m not justifying it but I don’t think it was a problem on American soil yet… and just more “not my problem”. Totally shortsighted.

DOGE probably didn’t help matters but the problem started to rise in 2023. My gut reaction was “damn that DOGE!” too but they didn’t start with cuts until 2025. So it likely just exasperated an already growing concern. This is the same kind of stuff anti-vaxers don’t get. We left South America out of the equation so when the circumstances of migration and feeding changed so did the status quo of a “screwworm free” line in the sand. Other peoples problems can quickly become everyone’s problem if left unchecked.

And that is what pixel tracking is for. :)

Is entirely context dependent. I can agree in some scenarios but when it’s a utility or gov site that I can’t really avoid it’s less straightforward.

If this has a wifi antenna port would be very useful for marina wifi if you’re sailing around.

The article is comparing 2 scenarios that have other explanations: a fire sale of a large fleet and Tesla which has an image problem because of its leadership.

I’m not saying the article is wrong I’d just like to see broader representation (Chevy bolt, lucid air, etc).

A vocal minority are freedom loving. A significant number are hooked on consumer debt. I feel like any sweeping generalization is going to be wrong… especially when referencing the USA which is basically 50 countries and has a population exceeding all of Western Europe.

> I am a backend developer using Spring Boot and Java.

If your goal is speed to market use what you know which is Spring Boot and Java.

If your aim is to learn something new then go with Django or sprinkle in some Kotlin incrementally (eg tests). I don’t think it’ll matter in the long run which you choose.

Conflating I want to learn something new with I want to deliver quickly will give you a suboptimal outcome for both.

Feels like a bad point in the curve to try and sell them. “Oh our internal hypecycle is done… we’ll put them in the market now that they’re all worn out.

Probably that’s the scenario. You want something simple and narrowly focused. Advanced and infinitely configurable isn’t always a virtue.

Looks like a release about 2 weeks ago but otherwise not sure.

I find it mildly devious when numbers are inflated by changing the period from seconds to days.

Aeron and NSQ have slightly different design principles. Which can easily be identified in their feature list. Aeron’s origins are exchanges for fintechs and focus on predictable low latency with a tight standard deviation. NSQ puts heavy emphasis on being a distributed broker less message queue. Performance alone probably isn’t a good basis to measure their utility.

It’s all swings and roundabouts has been since the broad adoption of computers. I expect in a few years time when everyone’s forgotten the pain points that drove them to decentralize there’ll be a big move to centralize again. Someone will get a gold star for coming up with the idea and being able to demonstrate the “cost savings”. Of course it’ll completely ignore the general disruption to all of the product teams as they adapt to the new world order but what’s a company without a little busy work.

Everything’s benefits and tradeoffs. With this model there’s a clear ownership model. I’m not suggesting it’s right for everyone but it is a trend we’ve noticed with a number of clients over the last 2-3 years.

we have hundreds of clients most on k8s or openshift. Many of them are shifting to smaller team or division oriented clusters so that they can move at their own pace in consuming capabilities, tools, security practises, etc. It also simplifies distribution of operational expenses, yea there’s tools out there to help with that but it’s a whole lot easier to hand someone a sub-account in AWS and call it a day. Additionally it reduces your fault boundary. It isn’t as sexy as saying you have a 5000 node cluster with 100k+ pods running but it can make life a whole lot less stressful when it comes to upgrades and changes.

Phone autocorrect… thanks!

Comparing a single function to an entire ecosystem is crazy. Making an LTS imposes a skew of compatibility and support to all downstream vendors as well as the core team. The core team has done a great job on keeping GAed resources stable across releases. Understand there’s more to it than that but you should be regularly upgrading your dependencies as par-four the course not swallowing an elephant every 2 years or whenever a CVE forces your hand. The book Accelerate highlights this quite succinctly.

I would even go so far as to say free users aren’t customers in a platform like this. There’s no revenue model and if it’s “run without constraint” you get some fun scaling problems but those types of issues can sometimes lead to optimizations that keep the system online in the face of many small apps but doesn’t necessarily cover the case of a large resource app.

Thanks! Was faffing with it... the "help" isn't very helpful on how it formats. Sadly can't edit now. :/

It doesn't sound like a great situation to be in. It sounds like the founder has strong opinions. I suspect he subscribes to Trunk Based Development[1] and Continuous Delivery[2]. He also likely wants to follow the practises that "leading organisations" follow in "Accelerate: State of DevOps Report"[3]. You might find it beneficial to research those subjects prior to discussions with him.

  1 - https://trunkbaseddevelopment.com/
  2 - https://continuousdelivery.com/
  3 - https://cloudplatformonline.com/2018-state-of-devops.html

Agree in many cases you can do this however with point 2 the removal of a function(s) is literally the aim. The accretion of functions benefits legacy systems however its tradeoff is potential harm to users new and unfamiliar with the library. Accretion creates a cognitive overhead (even if only minor) for both the maintainer and new users. Maintainers when they return to code to update and modify behaviour. New users when they seek to understand the library through documentation, examples, and usage. I don't think it's coincidence that a number of languages and libraries acknowledge this by having "one correct way to do X".

Using a concrete example relating to security; libressl maintained much of the API surface that OpenSSL provides. In essence they aimed to provide a "drop-in" replacement. However there were whole families of algorithms and functions which they deemed "unsafe/unfit" for purpose (e.g. FIPS algorithms). I think that's a perfectly valid exception to the rule. It acts as a canary in the coal mine and you have options; fix your code or defer upgrading.

I would advocate for thoughtful deprecation cycles over ossification of poor APIs and algorithms.

I think the reference might be more in relation to OSS tooling such as docker, kubernetes, and a lot of the other stuff in the CNCF project catalogue which is often VC backed start-ups with OSS codebases.

To be fair I think most of the OSS languages are Cathedrals. Golang recently had an uproar over dep (community lead initiative) vs vgo (core committer). Ruby seems similar. With the recent departure of Guido as BDFL I think Python is the exception.

The low number of commits is somewhat intentional in that they actively avoid providing too much functionality in core and relative to Go which has the might of Google backing it there's fewer people with hands on who are incentivised based on innovation. It would be nice to see more frequent integration of commits from the community but ¯\_(ツ)_/¯.

there was freedom I feel Ruby had that Python didn't which allowed Ruby to successfully go from 1.8 to 1.9;

* Ruby had better dependency management. Python's only recently introduced Pipenv which provides a standard approach for managing development and prod dependencies. VirtualEnv's been around for a while but didn't handle scope.

* Ruby wasn't used as extensively as Python in stuff like system libs and start-up scripts so system packages weren't constrained in the same way.

* Ruby's ecosystem was more focused around web development. Rails in particular was fairly early in adopting new versions of Ruby within about 1 year of the release of Ruby 1.9. Django on the other hand was about 5 years before it had it's first Python 3 compatible release.

* "microbenchmarks" generally got better with Ruby releases whereas Python 3 seemed to have gotten worse from what I remember. I don't think microbenchmarks are terribly useful out of the context of an actual application but many people use them as indicators.

* subjectively I think the Ruby community was more committed to unit testing which made "fearless upgrades" a little more palatable.

I agree with the principle that you shouldn't arbitrarily change API's. I disagree if it is extended to being an unbreakable contract. There are specific scenarios where people should consider breaking changes most of which fall under some for of improving usability of the library;

1. improving/providing secure defaults. 2. reducing the API surface so that usage is more evident. 3. refactoring that eases maintenance. 4. improving performance where appropriate. 5. probably others I haven't thought of.

In RFC style I would say it's a SHOULD rule rather than a MUST.

I have enormous respect for Alex et al that are maintaining Clojure at Cognitect. From my observations there tends to be few changes in core which is reinforced by a fireside chat with the guys at Cognitect showing the level of Java code churn over time has continually decreased. Everything has benefits and tradeoffs. The benefit of this lack of churn is a stable foundation but I think the tradeoff is that there aren't as many eyes on that code and the depth of familiarity required to improve the code for legibility, maintainability, performance, and security is lost with lack of intimacy. Much of the Java code is undocumented and at times can be hard to follow with unused variables and little if any tests available to validate behaviour. It's delegated much higher up the stack.

During the release of 1.9 there were some issues relating to spec, libraries, and build tools in the pre-release versions. So I'm not sure I would say the rule is followed to the letter such that you can consume Alpha releases are safe. It was prerelease candidate so no biggie. I know there were some discussions on the mailing list of a formal security audit of the Clojure but I'm not sure where that went but I'd be interested in seeing the results.

I mentioned in another comment but many countries have free data for WhatsApp plans which kind of entrenches their position. They might lose out eventually but it won't be overnight.

In Argentina many cellular plans include 30 days of WhatsApp for free on pay-as-you-go plans. Even if you lapse your payment for the 30 days you still have WhatsApp texting. Interestingly audio, photos, and video don't work.