mlthoughts2018

I think you are probably confused. There are many beta features in Kubernetes and they are enabled by default. For a long time, very critical features could remain beta for years, such as all of Ingress and all of CronJob.

- https://kubernetes.io/blog/2020/08/21/moving-forward-from-be...

One of the big issues with the GKE SLA is that your organization must only consume Kubernetes from the Stable channel, but given the large amount of enabled-by-default, critical beta features, many (probably most) production deployments of Kubernetes rely on non-stable channels intentionally for the sake of critical beta features that have been de facto production features. In my company for example, we must run a slightly older version of Kubernetes and upgrades are very slow, so we are way behind the stable channel with no way to upgrade fast unless the stable channel supports all sorts of enabled-by-default beta features and older versions. So we could never run a hybrid cloud with GKE, it would violate the SLA restrictions from first principles. This has created a nasty, painful rift in my org between the on-prem Kubernetes and the cloud (essentially useless) GKE Kubernetes.

Beyond this there are other features that are critical and uncovered, like multi-region ingress for example. We operate some very very large data ingestion services for customers and we absolutely need a higher SLA uptime on it than what a single region offers in GCP. So we have to operate multi-region ingress, but all of the non-Anthos solutions are no longer supported by GCP, and void out the individual region SLAs. It’s madness.

On top of all this, Google does not actually publish clear lists of features that are or are not covered by the SLA. The way it’s worded relies solely on the Kubernetes alpha / beta / GA channels, but nothing actually ties Google legally to that. They can arbitrarily define the SLA terms to mean whatever they want it to mean at any time. While you likely can’t avoid a cloud provider with that freedom, at least you could expect them to actually publish and document it.

> I’ve also always been able to assign permissions to a user, group, or service account. When have you not been able to do so?

Please check again in my comment. I mentioned specific examples (user-based, not service account-based, workflows in Dataproc, for example), where it’s not possible in GCP, as in the product itself disallows it. It’s not an issue of me or you or anyone being able to create IAM policy or service accounts. It’s an issue that different products within GCP fundamentally disallow some auth workflows (like Dataproc cluster creation being fundamentally disallowed for user-based auth workflows) that then force you to manage multiple different auth flow patterns even within the same user workflow (for example, user-based auth flows for GCE VMs but impersonating service accounts for the exact same steps for a Dataproc cluster), leading to much more overhead, more inscrutable errors, more round trips through security approval. The issue is the poorness of the product design, not some general inability for a user to figure out a service account.

If you can provide the same proof of work features using less energy, you can demonstrably make a lot of money. Can you show me the evidence of that and the specifics of how to get the same block validation consensus security with less energy consumption?

Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython.

The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python.

Using extension modules is just a time-tested, highly organized, modular, robust design pattern.

Julia and others do themselves a disservice by trying to make “the whole language automatically optimized” which counter-intuitively is worse than make the language overall optimized for flexibility instead of speed, yet with an easy system to patch optimization modules anywhere they are needed.

You claim Pixar adds value while Bitcoin does not. That’s a mammoth claim in need of extremely amazing evidence to take seriously.

Your response is deeply unreasonable. Here’s a quote from Stephen’s thread,

> “ Unlike other economic activities, the bitcoin scheme produces absolutely nothing for all this waste. It is a pure speculative activity of people gambling on the random movements of prices and the only output is simply shuffling numbers around in a computer at insane cost.”

That is nothing but complete grandstanding decoupled from reality. It deserves to be criticized with pejorative language because Stephen’s comments are so wildly extreme, inflammatory, and totally disconnected from facts or reality. It meets the literal definition of a rambling screed and needs to be called out as such.

That is a radical claim to make with no evidence and huge evidence to the contrary.

Uhh no. Stephen is not discussing BTC energy usage. This is sanctimonious, moralistic grandstanding that presupposes “Bitcoin bad” as a moral absolute straw man to set up a nasty, useless screed railing against it.

If there was some legit discussion in it, that would be fine. There utterly is none.

It is so shameful for people to characterize resource use as “waste” like this. Not surprised to see more sanctimonious nonsense from Stephen Diehl, the same guy who thinks all us programmers not using functional languages are neanderthals still in “the bloodletting and leeches” era of software engineering.

This really is beyond the pale. Stephen sounds like a total crackpot here.

How much “waste” does Pixar’s renderfarm generate when creating artistic cinema that people want?

How much “waste” does Sony’s Playstation Network generate distributing games people want?

How much “waste” does the sum total of plastic surgery create?

I think alternatives like Litecoin and Bitcoin Cash are more likely to be adopted as a transactional tool in that case.

Bitcoin - speculation on digital store of value and solutions to hedge against fiat currency risks. The valuation model is to try to determine what X% of the global demand for store of value assets might shift towards Bitcoin in the long run. Probably nowhere close to the level of a fiat currency market or the gold market, but perhaps much higher % than it is today.

Litecoin, Bitcoin Cash - attempting to make crypto transactions common. Higher capacity, faster transaction processing. The valuation model is X% of casual transactions. X is probably never going to be an appreciable percentage compared to big transaction platforms like Visa or Mastercard, but it may grow steadily and find niche areas where the ability to quickly transact in a cryptocurrency is highly valued. This is likely to remain correlated to cryptocurrencies that act as a store of value because one main area for demand of casual cryptocurrency transactions will be hedging risk of fiat currencies. Eg if I live in a region with government currency instability, I’ll want to decouple my cash asset values from that government risk, and look to a platform where I can still buy toilet paper or bread without hyperinflation.

Ethereum, Polkadot, Cosmos - network effects and ecosystems of smart contracts. The valuation model is like an app store mixed with a cloud vendor. Much harder to state a clear valuation model, likely very volatile due to perceptions of “killer apps” and how much staying power they would really have, as well as the interplay with regulators.

I also have significant experience in all 3 and I couldn’t disagree more. GCP support & documentation alone is a dramatic reason to avoid GCP. GCS CLI utilities are supposed to be S3 API-compatible, but they are not. GCP keyfile-based access is a horrid anti-pattern, but the rules for human IAM user vs service account vs impersonation are not uniform across all products (eg, if you need developers to have ad hoc non-console access to both GCE VMs and Dataproc clusters, you have to manage two very different approaches to identity-based access).

GCP’s region-level SLA are poor for most products and over a window of a few years, they don’t actually meet their region SLAs. GCP has all kinds of nasty legalese about “beta” features that aren’t supported by the SLAs, and if you use them, you forfeit your right to claim credits after SLA-violating outages. For GKE in particular, Google’s rules basically exclude every aspect of Kubernetes you need to actually use it in production, which is a blatant attempt to force users into Anthos.

In machine learning in particular, GCP has horrible offerings that are massively over-priced and/or are 100% hype-driven (TPUs are a good example, but also things like running Kubeflow or Feast).

Google Cloud Functions and Google Cloud Run have such severe limitations to resource sizing, especially memory, that they are irrelevant, whereas by comparison Fargate is excellent for ML workloads. There really is no equivalent in GCP, since Cloud Run can’t handle large Docker containers needing high RAM, so you’ll just be rerouted to GKE where because of the SLA legalese you can’t actually use any of the tools you want. And then on top of this, configuring any type of hybrid open internet / internal data center service with Cloud Functions or Cloud Run is miserable. You need a full Networking team just solely to manage Cloud Function or Cloud Run service access, it is absolutely nowhere close to self-service for normal backend teams.

GCP is a miserable, miserable choice for cloud vendor. It is typically chosen solely due to being cheap in the short term and allowing bulk deals on GSuite, Ads credits and other deal sweeteners. It’s so stupid to choose GCP for these short-term deals, because Google absolutely will lock you in and raise prices for their garbage tools and poor customer service.

For my money both Azure and AWS are still lightyears ahead of GCP and I would gladly pay a premium to use either just to avoid GCP.

And in turn pollution might decrease, frivolous consumer waste might decrease, frivolous ad waste might decrease, people might turn to crafting and making their own home goods, and feel more pride and accomplishment, and the standard of return on investment to actually draw cash out of the mattresses would be higher, rather than building in a mechanism that stresses people into giving their cash over for hollow waste, and entrenching false “market demand” narratives around the whole destructive charade.

Those inflation figures, much like unemployment figures, are not really representative. If you take a basket of good that includes consumer discretion items like cheap tech gadgets, subscription music, staple foods, then these “balance out” the much worse inflation in housing, college costs and medical care, things which have a much higher quality of life impact.

I’n not making any claim on how this dichotomy relates to cryptocurrency speculation, but I do think in general nobody should be using CPI-based figures or traditional BLS figures at all, and anyone seriously talking about US inflation needs to be starting from the given baseline fact that “real” inflation (ie, excluding discretionary consumer toys, subscription services, staple foods) is much higher than 2%, and has been for a long time.

> "It would be unfortunate and detrimental to The Intercept for this story to be published elsewhere." --Betsy Reed

> So that is stating very clearly: No we won't publish it. No you can't publish it elsewhere.

You are just embarrassing yourself here.

> “Make of the story Greenwald wrote what you will. There's been plenty of opportunity to falsify it and discredit it.“

It has already been widely discredited by every major news room, including the Republican-leaning Wall Street Journal.

At this point, there is utterly no sense in which a person can believe the unsubstantiated allegations against Hunter Biden or the completely ridiculous found laptop story, other than literally supporting a fascist presidential regime.

What you’re suggesting is a deeply radical and extreme point of view that has been overwhelmingly dismissed by every credible news source. You’re taking a stance on both the Greenwald story and the Hunter Biden story that is wildly and ridiculously decoupled from reality, in a seriously extreme manner that deserves to be called out as totally debunked and inappropriate.

The Intercept definitely did not try to suppress anything. Greenwald’s accusation that it amounted to censorship was beyond ridiculous. He wanted to publish a hatchet job against a Democrat, based on shoddy, unverified claims and mediocre, unverified physical evidence. The Intercept instead wanted to uphold bare minimum journalistic integrity and even offered to publish the piece if Greenwald would edit out the extremist rhetoric, claims of widespread liberal bias in professional news rooms, and unsubstantiated speculation against Hunter Biden that was purely playing into the hands of a fascist Republican administration.

Instead of adhering to these basic Journalism 101 bare minimum requirements, Greenwald decided to throw a tantrum and call it censorship, when really it is plain as day to any fair-minded outsider that there was utterly zero censorship towards Greenwald, the Hunter Biden story was crap and major news rooms were right to ignore it, and The Intercept did nothing wrong in that particular scenario.

Greenwald is permanently wearing some kind of Democrat-hatred goggles that render everything he creates spastic and aligned with fascists purely to take the piss because he’s bitter.

I don’t think he could even see eye to eye with himself in the mirror at this point, he such an incoherent mess of poorly constructed anti-Democrat gripes.

I would trust Poitras’s take on this way, way more than Greenwald’s.

I agree we probably won't get anywhere constructive and your decision is respectable. However, I disagree that you are being interpreted negatively. You are being negative - it's not an interpretation, it is just the unquestionable property of your communication and the substance of your comments, especially insulting towards users of FOSS projects. There's no matter of interpretation, it just is negative.

Likewise, I don't believe I am speaking negatively or uncharitably at all. I think I have responded in good faith and with due self-reflection and that my comments are fair reflections of what you are communicating. Looking back, I don't see anything I'd change or any place where I wasn't engaging with polite, good faith responses to your negative comments.

I am curious what your take is on things like this article:

https://managingml.substack.com/p/the-myth-that-machine-lear...

It has been my experience too. Basically, ML / DS engineers are thrown under the bus for being poor general software engineers, but in practice it’s totally the opposite.

Nope, you are completely trying to misrepresent what your original post said. You said that you downvote other ideas because they (the ideas) are “dangerous”, here is your quote:

> “ I mean answers that are dangerous, vulnerable, misleading, or represent an extreme viewpoint as fact ("buhh object orientation is dangerous, you must write C++ using functional paradigms, it's the only way to make good programs")”

So you are claiming that an idea expressing “OOP is dangerous” is itself dangerous as an idea and that this danger is what merits your downvote.

Yet you’ve done nothing to explain such an extreme and unreasonable point of view.

I am an experienced ML manager in a large ecommerce company, and I mostly agree with you, and I can’t wait for this to happen - and I think people just entering college or grad school for ML should not fear it. It’s a good thing.

Right now, there is so much misunderstanding about what ML is, what resources it needs, and how it works that the corporate environment is very stressful.

ML jobs are well paid, but they are NOT fun. No one understands ML devops & the infra needs to enable tight experimentation loops. Existing observability and telemetry systems are wildly bad for model training, reproducibility or any form of online or semi-online learning. As an ML engineer you’ll have to take on huge workloads of devops, infra, tooling, data munging. I’ve seen more than a few brilliant ML engineers burnout and quit because of this.

As ML becomes better understood as a boring technology, and decisions around ML projects, team structure and especially ops support start to get more standardized, I think this will get better.

The pivot you mention means a thinning out of the headcount on the pure ML research side. But it also means opening up more positions in ML engineering, infra & devops.

If people choose their specialization appropriately and remain open to being less on the research side of this, then I think there will continue to be lots of opportunities for high-paying jobs, and people will know their required responsibilities more unambiguously and probably will be happier, rather than dredging through the endless series of bait and switch jobs that exist today, promising a focus on ML research but typically forcing you more into ML devops & data platform management.

> “ The idea that you have these programmers who spout mumbo-jumo all day, cost a lot of money, and seem to always be planning stuff behind your back is threatening, and this breaks their control over the means of production.”

That is a very bizarre description of ML engineers. In every company I’ve worked at, ML is a team or teams that partners with product managers and other engineering teams to learn about problems they need solved. It’s very systematic, boring, and tied heavily to those other teams as the leaders and decision makers.

First you look for high level value propositions, like automating a decision process, removing a customer friction point, creating key metrics where simple metrics are intractable, or various multi-modal information retrieval goals.

You identify opportunities in these kinds of high level areas in lock-step with product managers and other engineering leaders. Then you move on to identify sources of data that can be leveraged, and eventually (much later) you get to the smaller set of work training a model, validating with acceptance tests and hardening the implementation for safe production deployment.

If people are spouting “mumbo jumbo” and making big ML model decisions without lock-step synchronization with other stakeholders, that sounds like organizational dysfunction, not any type of issue with ML.

I also find it odd that you bring up “cost[ing] a lot of money” .. that’s very out of place among everything else mentioned. That seems more like insecurity or jealousy over the market demand for ML talent, and wanting to cut other people down rather than work with them or acknowledge the level of effort it required to get that level of expertise in ML.

Most commercial use of ML, including neural nets, is small data application-specific business logic. Think phishing / spam / fraud detection, anomaly detection, semantic search, image search, keyword labeling, classifying or segmenting customer data. These applications have well-understood business value propositions. Much, much less often the ML application focused on truly large data.

I think we might see a winter in super big applications like self-driving cars or voice assistants, but ML in general is just a boring, non-controversial business tool with hundreds of valuable applications.

You’ll still need statistical specialists to train and operate models and ensure systems avoid pitfalls like overfitting, poor convergence, multicollinearity, confounders, etc.

So I doubt this will have much impact on ML job market. Companies that invest in ML will continue to run circles around companies that don’t. You’ll just see the unjustified over-focus on SOTA neural networks die down and become just another boring tool in the toolbox like everything else in ML.

The talent they are competing for can work anywhere, and this untethering of geolocation is only increasing. The relevant market of candidates for large European cities is increasingly just a pan-Western talent market, and lower cultural salary norms are really hurting Europe, leading to brain drain and reduction of major tech hubs.

If you increase housing stock, there can be more cheap homes for new entrants in the market, meanwhile existing homeowners may still see significant appreciation on their home value, depending on lots of market variables.

Wanting affordable home ownership is not contradictory to growth of home asset prices.

I also think your argument about income inequality is not right. Achieving income equality by suppressing wages and paying below competitive market rates is nothing to be proud of - and largely for professions like SWE, it has absolutely nothing to do with income levels at the low end close to poverty, which is what matters when understanding income inequality.

We should be raising purchasing power and unlocking possibilities for people. That’s the real purpose of reducing inequality.

Otherwise we can just take the trivial solution: destroy all technology and return everyone to subsistence agrarian society. Near perfect income equality, near zero societal level wealth.

> The creator/developers of an open source project usually has a far better understanding of the bugs, missing features, etc of their project. They've spent months to years thinking about it.

This is a bizarre point of view. The maintainer has only spent time thinking about it from the point of view of their lone preferences and opinion. Users come from all walks of life and are in the weeds with many use cases or blocking issues or bugs that the maintainer would never realize or think of if it weren’t for the free effort gifted by users reporting bugs and requesting features. It’s far more bizarre for you to assert maintainers are in the best position to judge over and above users.

> Maybe there's a 1/3000 issue where a user gives thoughtful and meaningful insight into a new feature the project could have which the maintainer hasn't thought of, but the vast majority of issues are not that. The vast majority are users who don't understand the technical tradeoffs of the project, don't understand the maintainer's goals, etc.

This is exactly backwards.

> Again, if a user has a good idea for the project, the user should fork it and implement it. If the user can't, then they shouldn't be asking the maintainer to.

No they should lobby the maintainer to prioritize it for the existing project. Forking and doing it themselves should be an extremely uncommon fallback or hobbyist special interest, not at all a default.

> Projects don't have to be open source because someone wants bug reports from users who have no clue what they're talking about.

> In fact, if you listen to maintainers, the vast majority don't want that crap.

You seem to have some mix of a superiority complex / poor attitude towards users of OSS. It sounds extremely obvious that you aren’t suited to be a FOSS maintainer if you harbor these biases against users. Have you considered taking your projects down? It might be a benefit for all parties to not have to experience this anger / belittlement issue from you.

> Just because the author of the project does want people who find the project useful as-is to use it doesn't mean that they're inviting people who have issues with it to use it and complain.

Nope, the internet doesn’t work that way. If you want to post your software project for passive consumption, people absolutely have every right to complain about it. You don’t have to listen but they absolutely have full justification to provide their take on the thing you published.

> That seems to be your big disconnect. Users are entitled to nothing more than the existing code given to them in an OSS project unless the author explicitly adds additional expectations (such as having a contributing.md asking for issues or having a bug report button in the project or something).

It has nothing to do with being “entitled” to anything, for either party (users or maintainers). And this doesn’t matter if the maintainer is RHEL or some random guy that can spend max one hour a month on a project.

> I have to ask, have you maintained many open source projects? Have you seen things from both sides of the fence? What interactions have led you to have this viewpoint?

Given the vitriol in your comments and especially the really abusive language you use to sweep the entire class of FOSS users under an umbrella of being completely stupid and dimwitted compared to maintainers, I do not for one second believe you genuinely want to engage in discussion or debate whatsoever. If I shared my own personal experiences managing FOSS projects for two past employers, I think you will just find excuses to unfairly dismiss it, make sniping replies and take various pieces out of context as you have so far.

As a hiring manager, a large fraction (easily greater than 50%) of resumes that I see do list OSS projects and contributions as accomplishments and technical experience.

Maybe I just see an unusual slice of the OSS maintainer world, but it’s very common.

> Do they?

Overwhelmingly yes.

> Do you?

Yes, only users of a library or package really have sufficient context to articulate the pain points, bugs, and missing features. Users have to weigh up their own time and priorities too, so for users to give up their free time to put work into documenting issues / feature needs, that is a bunch of free labor given to the project maintainer. Any maintainer who sees bug reports or feature requests as a time drain instead of free product research is completely wrong.

> Odd, I don't need attention for my projects.

Then why are they open source?

> You explicitly spell out that maintainers owe user listening to them and helping them for their "free labor".

No, I never said anything like that, in fact I said the opposite. Maintainers are perfectly free to ignore users if they want. It would just mean it’s reasonable for users to see that as a shitty owner and express frustration about it. Maintainers don’t owe anyone anything, and I never said otherwise. But it’s perfectly legitimate for users to express frustration over badly managed FOSS projects, neglected feature requests, etc.

In other words, “if you don’t like it, leave” is unjustified, and users should express frustration. It doesn’t mean a maintainer is going to listen, but that’s beside the point. The original comment I replied to proposed that users are ingrates or should possibly be banned if they “complain” - that if they have a problem, it’s not the maintainer’s problem.

These are just wrong attitudes. Maintainers aren’t obliged to do anything. Irrelevant. Users should still complain and lobby maintainers to fix things, as that’s far more helpful and reasonable than “take it or leave it.”

> If said users indeed invest quality time and I as a maintainer feel like their presence enhances my project, sure, giving and receiving is a good idea! Now, we both know how often that happens :)

No, this is up to the users to decide, as they actually use the project. Users decide if filing a bug report, asking for a feature, or pushing back on a roadmap is needed, because it stems from the problems they experience as users. Of course the maintainer doesn’t have to care or even read it, but that would be horrendously undiplomatic of the maintainer, and users would have every justification to express frustration about it.

You did not explain how this is dangerous whatsoever. What about all those companies or teams out there using exclusively functional programming and succeeding? Their own experience would be evidence that avoiding OOP is good (as it has been good, demonstrably, for them). If they merely spoke from their own experience and attested to the good things that demonstrably came from avoiding OOP, you would consider that dangerous?

That’s a ridiculous perspective.

Again, it’s totally fine to disagree with them, and make solid counterpoints if you can, but calling them dangerous is completely ludicrous.

This makes you sound like a narrow OOP zealot who gets cranky when people point out the truth that any use case solvable by OOP is also solvable with at least equal quality and equal satisfaction of the constraints using functional programming.

Again, merely disagreeing is one thing, and raising pros vs cons of some specific OOP design. But to call it dangerous to suggest OOP may never be needed is just completely unreasonable. I question your understanding of the concept “dangerous” in that case, and if it were up to me, you’d lose downvote privileges treating people like that and misrepresenting their sincere, evidence based software ideas with a derogatory term like “dangerous.”

If it appears on a resume, it’s done for notoriety. If it’s fully anonymous and never appears on a resume, then I concede you are right in that case, but I think that’s an extreme minority of cases among the types of projects the thread is discussing.

The person who downvoted has to look out for themselves though. They may earnestly want to explain their choice so you can engage with their counter-points, but other observers on HN are extremely discourteous. Signaling disagreement usually just causes a flood of tribalistic downvotes or upvotes for in-group voting, as well as people disingenuously using the flag option, and spamming rebuttals, especially disingenuous calls for data or evidence or “citation needed” requests that aren’t actually in the spirit on engagement, just serve to DDoS real disagreement out of the conversation.

A silent downvote lets you avoid a lot of that, even if you respect the premise of the original post you downvoted.

Since when is avoidance of OOP an extreme viewpoint? Few pieces of advice have served me as well as that.

It seems fine to disagree - but if that is your standard of “extreme” or “dangerous” it makes you seem like a crank and makes your justifications for downvoting seem very biased and wrong.