This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others.
Of course I hear plenty of people complaining that apps on top of hypertext is a fundamental mistake and so we can't expect it to ever really work, but the way you put it really made it click for me. The problem isn't that we haven't solved the puzzle, it's that the pieces don't actually fit together. Thank you.
> An even more significant improvement would be electrified trains, which can accelerate roughly twice as fast as those with diesel power...
Can someone comment on why this is? My understanding is that the existing diesel trains use diesel generators to power electric motors.
My questions are:
1) Does "electrified" mean pulling power from a third rail?
2) Whatever it means, what makes "electrified" twice as fast as diesel-electric?
I can see the value of examples, but in this case I appreciate the post largely for its universality and lack of examples. On reading it, examples from past and present experience spring immediately to mind, and I'm tucking this away as a succinct description of the problem. Maybe I can share it with others when more concrete examples come up in future code review.
A principle takes skill the apply, but it's still worth stating and pondering.
> In other words it’s easy to make a difference as a high performer in a low performance organization.
And yet, the big takeaway for me is that to be a high performer it isn’t enough to A) know what needs to be done, or B) be able to do it well. The key is C) figuring out the incentive landscape.
His story of carving out his own job only to find he had no support from the board is what I’ve tried before. In my low performing organization, I thought I could be a high performer by knowing what needed to be done and doing it well. Everybody I directly worked with loved me and thought I was highly effective, but I never made any lasting change like this author. I didn’t understand the need to skip way up the levels until I was already burnt out.
> The WolfsBane Hider rootkit hooks many basic standard C library functions such as open, stat, readdir, and access. While these hooked functions invoke the original ones, they filter out any results related to the WolfsBane malware.
I took this to mean some things like a simple “ls -a” might now leave out those suspicious results.
I wonder how much of that growth is because the bags themselves are so much thicker/heavier now. It would be interesting to compare count vs. weight.
It looks like the new, thick bags are 5x thicker than the old, thin ones (0.5 mils vs 2.5 mils) [0]. 11lb is a lot less than 5x 8lb, so the per-person bag trashing must be drastically lowered, unless weight and thickness aren’t correlated.
This was my first thought on seeing the title as well. My entire life I and every family member I can think of has used plastic grocery bags for our little bathroom trash cans. I don’t even know what the options are for “real” bags of that size, having never shopped for them. Time to learn, I guess.
That said, this could still reduce my plastic use. The old, thin bags were sufficient. The new, thick bags have been overkill since day one. Given that the frequency with which I take out the trash didn’t change when the thin bags were banned, I’m sure I use quite a bit more plastic than before the ban. Maybe bags sold for small trash cans are thinner, and I’ll go back to pre-ban levels of use.
Yes! When I started using Kate on Linux ca. 2005, I was coming from Notepad on Windows and couldn’t believe how nice it was. I believe it was my first experience of syntax highlighting.
And Amarok! I haven’t thought of that in a while. Losing Amarok was my single biggest regret when I became a Max user. I’ve not used anything since that came close.
At my day job we’re heavily invested in Leaflet for historical reasons, but toward the end of last year added Maplibre as a layer on top of it via the excellent https://github.com/maplibre/maplibre-gl-leaflet. This has allowed us to begin transitioning gradually instead of being forced to jump all at once.
It’s hard to beat the simplicity of Leaflet, but neither it nor OpenLayers can handle Mapbox Vector Tiles in a performant enough manner, so Maplibre is the future for us.
I was not aware of Microsoft’s involvement. It’s great to see some big players using it too!
I'd love to see your macros if you have them online somewhere. I've lately started spending lots of time notating music in LilyPond and am seeing the need to build tooling along the way.
I started a personal folk song collection using ABC notation. For simple tunes ABC is fantastic, but now that I'm doing more choral/four-part works, I'm reaching for the more powerful tool. Yet there seems to be a huge gap between ABC (simple things done simply and in one way) and LilyPond (do literally anything you want following any format you want, dropping into Scheme as necessary). Ease-of-use/quality-of-life tooling to fill that gap is appealing.
P.S. I'd also love to hear the story of your music publishing venture. It sounds intriguing!
This approach is very appealing, but when I put my SRE hat on my first concern is observability. Has anyone implemented tracing for Postgres with a span for each procedure call?
When I put my dev hat on, I want the option of attaching a debugger and adding breakpoints. Anything there?
Oportun | Remote US/MX | Senior/Staff Site Reliability Engineers
My team is looking for hybrid engineers who are comfortable with both infrastructure and code to support a massive modernization of our tech stack and processes. But more than good tech, we need good listeners: technical leads who can bridge the gaps between product, engineering, and operations to create solutions that meet real needs and make us more effective as a whole organization, not just modern for the sake of modern.
Bonus points if you’ve read the Google SRE books.
Our tech stack is Java/Groovy, a rapidly increasing amount of Kotlin, some Python, Angular+TypeScript, AWS, Ansible, Terraform, EKS/K8s, MySQL/MariaDB+Galera, MongoDB, ScyllaDB.
To answer your question, yes, this happens. The cybersec team tried to "poach" me a while back, and more recently I was asked by the VP of Cloud Operations to leave my technical lead role within engineering and become Sr. Manager of SRE (I accepted).
Speaking of which, what caught my eye in your post is the problem you identity with how SRE is usually practiced vs. what it was supposed to mean. My mandate in this new role is to update our practices and technology to make our software more reliable, and I'm shooting to accomplish that specifically by tackling that problem. In my opinion, there's a reason why the term "SRE" was coined, and it all centers around shaping the organization, _not_ the technology. In an organization with properly aligned incentives, the technology should follow. (Of course it's not entirely one or the other—tech can feed into incentives and help shape the org as well.)
I'm doing my best to carefully guard the term "SRE" here and educate people about its meaning because the ideas and philosophies it brings to the table are precisely what will allow me to deliver what I was asked. If this resonates with you or anyone reading this, send me a message. We're hiring.
I think you've hit the nail on the head. In a previous job I tried to outsource "DevOps" to Rackspace, only to learn the hard way that if you can outsource it it's not DevOps—_increasing_ siloization is the antithesis of DevOps. But this is also the point where I think SRE is most compelling. Rather than trying to build an organization around "you build it, you run it", SRE recognizes the need for specialization while deliberately striving to align incentives between the various parties via SLOs.
This summer I finally hopped over to the DevOps side of the house as a manager, having always been a software engineer. My mandate from higher ups is to reform the team to start practicing SRE, but I think it's really more about reforming the whole organization. In every way possible, I'm trying to build a team of people willing to "be the change" like you say. But I also hope that SLOs, as a formal way of agreeing on priorities, will grease the wheels a bit.
> And often, it's not a technical solution.
Absolutely. In my experience, it's almost never technical. If you can structure the collaboration so that correct incentives apply, any technical solutions required come naturally.
