HN user

yebyen

2,755 karma

[ my public key: https://keybase.io/yebyen; my proof: https://keybase.io/yebyen/sigs/Q4xYtntxlQX51bnJaCqx5ERBtsA-G0clfn1VJVEY2F8 ]

Posts7
Comments1,991
View on HN

I agree that it makes more sense to buy your Kubernetes on an organizational basis because one should not reinvent the wheel, and taking advantage of a commoditized service is only possible if you work with a competent broker.

However I am wary of the capacity of skills vendors to take advantage when you come to depend on them, even when their intentions are good and all ideals aligned. Being able to deliver the limited Kubernetes experience for yourself in low-stakes contexts, where you can depend on it because you know how it works, well enough to administer in a pinch, but availing that also in a pinch you're not the bottleneck to solve a problem, because you use the managed broker in all the places where it matters, feels like a sweet spot to me.

I don't want to pay money to a broker every time I spin up a new experiment for the duration of the experiment =/= I don't want to perform experiments.

That's where I see the disconnect that "Leadership" may fail to understand. You can provide a service at low marginal cost to take some of the load off your people, and that might also have the effect of stopping any experiments that fall beneath a certain threshold as "not worth the cost" - all because we settled on getting something for cheap that should have been free.

Then again, dodging all those diversions might have been a part of the strategy...

IMO "use something managed" gets reduced to "we shan't run Kubernetes on-premises" which ends up meaning "we won't learn anything about failure modes until it's too late to think about mitigating them"

Which might be in line with what you said about

80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.

But also, would at least have some potential to be solved and much more cost effectively, or maybe at least grown past, if they would just spend some energy on deploying Kubernetes internally; even if we can't or won't afford an entire team dedicated to doing only that, (and even if we commit to using only managed services for production anywhere and everywhere.)

In my experience the way some places reflexively avoid it like it's a trap to be stayed out of, winds up being a bit like a self-fulfilling prophecy "we're not doing Kubernetes" - I empathize with the person who you triggered, even if now we're up to two walls of text from just a simple comment, I feel triggered too.

It makes sense if you take in context that Flux, the most visible and well-known product of Weaveworks, is a donated CNCF open source project, and that companies like Microsoft, VMWare, AWS – can all engage with it directly, or by forking, or by building support for it directly into their own products.

How do you place a value on Microsoft building Flux into Azure Arc? I know it isn't worth $0 but do they actually need a contract with anybody (at Flux or Weaveworks) in order to go on doing that - no. They don't need one.

I still use it, shamefully, ex-Weaveworks employee - there is a fork I can recommend which has a live maintainer, actively interested in keeping it up:

https://github.com/rajch/weave/tree/reweave

If you use Weave net still, definitely follow his work and consider learning to build the image, so you can keep it ahead of CVE scanners. (You are using a CVE scanner in your clusters, right?)

Flux has a pinned discussion for nearly a month now, to be as upfront as possible, without being able to disclose anything that might be privileged information, but anticipating that the news would get out about our backer sooner or later (aiming to avoid 100 threads about the same topic)

https://github.com/fluxcd/flux2/discussions/

tl;dr: Flux is a graduated CNCF project and not going anywhere

a bunch of snowflake workloads by design (or bad design).

That's a really interesting characterization of WGE, and I can't say I disagree much (my personal opinion as an ex-Wyvern/OSS Engineer DX @ weaveworks)

Sudden? We finally archived the repo at the end of 2022.

https://fluxcd.io/flux/migration/timetable/

I was hired to support Flux v1 two years after the events you described, in the beginning of 2021 to go on supporting Flux v1 until we could get everyone off the boat.

(I worked at Weaveworks until last month, and I'm still a Flux maintainer! Keep the Flux talk in Present tense please! ;-)

Is this really the same 16 year old RubyFlow that authenticates against GitHub? I found a copy looking for the source but it looks like it is literally 16 years old, and I'm thinking there's just no way the OIDC flow has been standing intact for that amount of time without any update... really? :D

Tl;Dr: in the past, if you hired developers and made no money, you could choose to either classify that work as R&D or Maintenance.

From a business perspective it matters because R&D gets written off until it becomes profitable, but maintenance is for long-term on software that's in production, so you amortized the maintenance over 5 years if you see it that way, if you're making money now, but you wouldn't amortize the R&D because it isn't making money and that's just a way to get yourself a big tax bill with no way to pay it. It was an option. No longer, all one bucket now.

I'm probably oversimplifying but today, with the S174 updates in effect, you don't have this choice. If it's classified as either, it gets amortized over 5 years, unless it's developed outside of the country then it's 15. Either way it's a massive tax bill because you had to have revenue to pay the devs and that revenue gets taxed in the first year now, where you could have written it off before all this.

This leaves very little room for speculative investments in R&D that were actually quite incentivized before S174.

We called it an investment and showed no profit, paid no taxes (except for the payroll taxes, social security taxes, all the other taxes which you obviously still can't avoid through paying employees in whatever locality they are working based out of...)

So the net effect of S174 is (we seem to be observing) that organizations with large developer footprints are now figuring this out a bit too late and laying off some or all of that staff pool to try to dig themselves out of this before it's really too late. You can't invest in research unless it's gonna pay off this year or you have some sort of money tree to use to pay for it and pay taxes on it. That makes it hard to see as an investment unless you are able to become profitable today.

The worst part is nobody seems to get it in the food chain. My (former) boss is barely aware of this issue, my CEO hasn't brought it up, but I am laid off and all my coworkers are. We are nearly all software developers. I have to assume it's related, until I can find another software developer job that isn't going through the same thing.

I hate this. You're talking about S174 tax code changes, right? I'm here making a hard decision about whether to remain in a field of work that could be classified as either R&D or Maintenance, whether to move out of the country, or both – and we are talking about the same thing aren't we?

Yes, there is Lucee; I never used it, but when I was briefly asked to take on some Coldfusion work almost two jobs ago, I remember that I found it looked to be a vibrant and actively developed community, far different than what we were seeing of CF upstream that appeared to be on life support. I did not get into it, I'm afraid my manager thought I might like it too much and I was asked to work on something else about when it started heating up :( too bad for me.

I also remember coming across something called Railo that appears to have come before Lucee.

Well, I told you I knew it was a myopic view. I understand that investor can come back, and I know they might try their luck again.

I appreciate your frank response, and I'd be willing to read if you find the time to tell me what else I should understand! (If we got our tax policy in order... no, that's not where you were going is it!)

rent out their property

are paying property taxes

Call me prejudiced, but I went from renter to home-owner in the last half-decade and I don't see the rentier class as really contributing in excess like you do.

I live in a Midwestern city where many of the rentals are owned by one singular corporation, and there are several such corporations, and I don't know what all the properties are like. I have a myopic view because I've only ever rented one house in this city, and only ever owned one house.

So I'll give you my one anecdote, because it's all I got. Tl;dr: we're paying those taxes, even though we should be saving a boatload because of our primary residence exception, we're still paying more taxes than a comparably priced house that we used to rent. It's a much nicer house, but by the numbers I do not get the sense that property renters are paying more taxes like "they're supposed to be." (But if I became a rentier and bought a second home to improve, rent out, and maintain, then I would pay those boku taxes; sure!)

We paid almost $200k for our house, a steal because we bought it in 2020. It has appreciated by almost 20% in two years. (We're not selling, so that doesn't help us any.)

We rented a house before we bought this house. They don't maintain the property, they did re-rent it; I'm not sure if it's empty today, but they definitely kept the house full for the past three or so years mostly since we left.

It's in poor condition because they count on renters to maintain it, and the renters rarely have any interest in maintaining their rented property. So it looks like garbage and the assessed value is not likely to increase, based on there being no improvements.

But the property is valued somehow at $275k in spite of nothing having changed. The house I lived in when I was renting, has been listed for sale for the last month at almost 4x its tax-assessed value. That house was assessed at less than $40,000 when we moved in, the tax assessment is up to $75k, listed for $269k – they do not get any primary residence exemption, but their assessed value is less than half mine so they pay 14% less than I do in taxes. Do you think it will sell?

The rental house is paying less in taxes, but that house has been listed at 20% more than our new house is worth. It probably will sell for more than we paid, based on the potential for rental income; it has a marginally better location and 30% less sqft than our house, so there's no basis for that price. But I bet you that it will sell, for at least 80% of the asking price, and that assessment won't be updated for years "because that's how long it takes."

It isn't worth what they're paying/asking, unless they jack up the price and re-rent it again! (They will...) And they will never pay property taxes on a sale price or on a lease price, property taxes are based on an assessment value. An inflated sale price with no improvements does nothing for assessed value, nothing for tax revenue, it's wholly based on the rental price bubble that can stay inflated and keep going as long as we're a college town, (as long as college prices keep going up!)

I have one anecdote and to me it shows the bad pretty clearly. I'm not sure how clearly I explained what I perceive is wrong, but what I'm saying is they are really taking money out of our collective pockets and it's not going towards taxes.

I should probably just put the clown makeup on, I am not going to convince you of anything; if you're starting with the belief that sophisticated investors from outside of the community buying up houses and renting them back out to people in the community aren't creating a net loss while they generate a return on their investment, then you haven't interrogated the situation honestly.

Their (outside investors) return is axiomatically the net loss to the community.

If we (residents) weren't paying it out to these investors, then we'd still have that money here in the community, going into savings of people that live in the community, or getting spent in the community. You think they're going to pay taxes, and well, as I see it we just aren't set up to operate like that! Not at all. The law notionally taxes non-primary rentals or non-residences at a higher rate than residences, but for reasons I can't fully convey and don't truly understand, it typically, seemingly, doesn't work out like that.

Or, there's always been more than enough housing in many localities for the local demand, but those people are not buying houses because they've been priced out by sophisticated investors who are not local, are not especially interested in the long-term development of the locality where they are buying, and who will almost certainly not ever be a resident.

There is a whole gulf of room between "we are the incumbent and there is no viable alternative in any language for JavaScript developers" and "the Rust folks have done it, there's an alternative now and it seems quite viable"

I think it's about escaping local minima? You can always look at the biggest sink for performance and say "there's definitely something we can do better in there" but unless you have something objectively better to compare it to, you'd never be sure.

Imitation is the sincerest form of flattery. And knowing that of the hard problems you solved, someone else can solve them and in a different language, I think there's quite a bit of value to be obtained just through the competitive process that emerges when there is competition.

You can't fully have competitiveness without an actual alternative to compare yourself against. If the Rust folks can do the problem slightly faster by shaving off just 5% or less of the test suite, what all does that tell us about the theoretical limits of a solution when compared against the canonical version?

I have only limited understanding of the problem space, but I think there's always something intangible to be gained from having a quite similar implementation in a different language.

I think that was the point. If it wasn't clear enough that your ellipses are meant to be showing some thing that was elided, put them in a comment.

(In this case, the article used them as valid syntax and added a comment to clarify that this is indeed valid syntax!)

If that isn't what you were doing, and it still isn't clear enough, add some text to the comment about what the "intentionally omitted part" was that you covered by an ellipsis.

You can pass positional arguments because that's how arguments have typically been passed in the history of computing. You can pass keyword arguments because they are much less ambiguous to use when a method signature is changing; you never have any confusion about which method argument is missing.

You can pass positional and keyword args together in a way which is rigidly formalized since Ruby 3.0 because, at one point in history, you could pass a hash, you could pass positional arguments, and you could pass keyword arguments, and nobody was ever able to tell reliably what you were doing:

https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...

You can pass a block because in Ruby, a block is an object like anything else. And you can pass an anonymous block because in Ruby, the "yield" keyword is an idiom that's commonly used with anonymous blocks. The curly braces and the "do" keyword that are both common idioms in Ruby are nearly identical forms of anonymous block.

The throwaway answer to your question is that you can pass anything that is an object, and in Ruby since anything is an object, you can just pass anything! I haven't read the whole article, but I get the sense that I shouldn't read much into the clickbait headline, since it looks like this is a really thoughtful show or treatment of all the neat handy things that Ruby lets you do with various types of arguments, and not a hit piece! whew relieved

Fun fact, Ruby as a single-threaded language is probably the only way how most people experience it, but...

Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)

https://github.com/ruby/debug/issues/486#issuecomment-157531...

If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once (but that other fibers can proceed, in case you were trying to debug something - you know - actually concurrent - and you really don't want for the world to stop and wait on your debugger!)

For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"

I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!

My parents use these games and I started as a way to commiserate with them, because I have always played games but they only started using computers after I was already well and truly addicted to computers writ-large.

The Double U Casino used to have a team check-in, where you could send your team bonuses and they saw that you checked in with them. I know it sounds stupid, but this was a real way that I was connecting with my parents, and then they shut it down.

Incidentally the name of our team was Roman Catholicism, because most of the teams were full and this was one that was not full. Whoever started Roman Catholicism left the group, and eventually we became the admins of Roman Catholicism. It was a sad day for me as a part of my family when Roman Catholicism closed its doors.

I should call my folks! I think they still use the casino app, even without any money or social investment, they still enjoy it and I made sure they had nice tablets to use the app on. This is still working, even without the social aspect. It's still valuable to us, we game as a family, even if we're not always together.

Anyway, would you ban Roman Catholicism because they're believing in what is not really true? I think someone baited me into this position, I wouldn't even make this ridiculous argument except that all of this literally happened and I am not making any of it up. Casino app keeps family together, son calls his parents more often after they get disconnected by the oppressive dev team that shut it down. I'll be here all week, try the Clams Casino at the bar.

That's a bit different than giving the DNA + cost of sequencing + full identifying info, all signed sealed and delivered, wrapped up in a bow with fully authorized permission to monetize for whatever purpose and share with whomever asks. If someone else is going to the trouble of finding my location, stealing a sample, getting it sequenced, and correlating the data, then I suppose they earned the database record the hard way, didn't they!

There's a lightning talk version from GitOpsCon (at GitOpsCon/CDCon Vancouver - co hosted with OSS Summit later in the week)

But they are pretty much the same talk, except at CDCon, I hadn't written the Kubernetes operator so that it actually ran the Wasm module yet. At the end of the talk at OSS Summit, I show it running and I'm so glad you enjoy it! I will definitely check out your new ruby SDK :tada:

This blog article is great, I had a hell of a time integrating Wasm into Ruby, so much so to the point that I gave up.

I was absolutely going to call a function, pass it some HTML to parse (as a string), and return a number, but what I wound up doing is pass a directory with some HTML file in it, return a number as a string, and parse it. Because after struggling with wasmtime and wasmer until I could see it was not going to perform acceptably with a Ruby interpreter packed into the Wasm module, I found that further, it was seemingly impossible to call a function from in Ruby with any meaningful parameters without going through the system interface to the Wasm.

https://youtu.be/EsAuJmHYWgI?list=PLbzoR-pLrL6prBc8UnTQ9wI3B...

and

https://youtu.be/EsAuJmHYWgI?list=PLbzoR-pLrL6prBc8UnTQ9wI3B...

The article does a much better job of explaining these issues concretely, but if you're totally lost, you can hear my fever-dream version of the same ideas here. (I am a Wasm beginner.)

But if you don't have time to watch, tl;dr: I gave up, my Wasm in the end was called as a WASI, which I passed a filesystem context into rather than attempt to call any function at all, and I parsed the output from the system interface. Not too different than what it looks like the Extism example is doing. I will definitely be going through these docs as it seems likely to help me understand better what I've missed, and moreover that it has Ruby support right on the front page chef's kiss