Ofc, git is distributed, so someone should have a copy of the repo, even if it's not updated.

Edit: disregard post, apparently it's just moved to the personal account.

> I moved actix-net and actix-web project to my personal github account. I will make decision during next couple days what to do. I don’t want to see the project becomes ghost of what it was. Maintainers must understand how everything work, but don’t anyone who does and those who could are busy with other projects. At the moment I am planing to make repos private and then delete them (will remove benchmarks as well), unless others suggest better ideas.

Green sources are becoming more and more cost effective because of lots of tax money went into them because people care about the environment.

Eventually there shall be plenty of more green alternatives that are more economically interesting than coal, but they only reached that place in refinement because environmental focused measures took place.

This was always the climate problem, neutral is not ex-climate stocks.. neutral was maths, just matching the index.

Pure indexing was not taking a climate position.

This is why this is so huge, they’ve reset neutral and are challenging others to do the same.

If they gain net inflows into their updated index products this will move fast.

They're just creating some new/modified indexes as far as I know. There are already more ETFs than individual stocks, I remember reading somewhere.

An e-ink is enough to program on emacs all day, but color highlights is a missing feature.

Maybe when patents expire, the tech will improve faster allowing for acessible color ones.

Exactly. Odds.

Both Fortune and misfortune can happen in the middle. This doesn't mean to stop practicing/learning/improving, it's just life. Be aware of these things, and look for opportunities. Also, remenber that because of this, some very skillful person might be underperforming just because of a bad day, be nice to them.

Alternatively: https://theoutline.com/post/2996/michael-moritz-china-essay-...

What a work culture.

What's wrong with sending emails or messages at 3am ... if you don't expect workers to read and/or respond to the message at that time (as opposed to the next business day)? It just means the messages sits there in the inbox until the next day. So what?

>and denying vacation times is nothing

I see nothing about vacation time. I saw PTO being denied - which may not be the same. Sometimes PTO and Vacation time is tracked differently, the latter being something guaranteed in your employment agreement, and the former being a perk.

It's a hard to tell where marelle ends and the config begins, since it's all just prolog.

What would be the benefit of adding a declaritive language into the mix over YAML?

Emacs is configured using Lisp. Because of that it is amazingly configurable. XMonad uses Haskell, which gives types to avoid lots of error cases.

The thing is providing an actually programming language doesn't remove anything specially if the same config can be written as cleanly.

And you would avoid "YAML templates for creating YAML", when you actually need to process some data (even if it's just for pre/suffix creation in names). Secrets retrieval is another thing that you also need to do and template.

Also, YAML is a terrible to parse language, with can give out weird error cases. Other languages compilers/interpreters are more mature.

And ofc, if you provide SDKs for your IaC tool, you should be able to use the language that your developers are more familiar with. Taking advantage of the good practices their are used to. Don't limit with "declarative languages". Use a programing language that make more sense, and leave data languages for data.

YAML is not typed and you can basically do whatever. The worst of all worlds.

The capability to readily define, store in libraries, and use reusable abstractions that apply within a configuration or across multiple individual configurations.

General purpose programing languages are getting more expressive by the day, why do we use data serialization languages instead for configs? it doesn't make any sense.

Configuration is code not data.

You know, once upon a time, we understood that declarative approaches to software engineering were superior to imperative approaches, when declarative approaches are feasible. Declarative approaches are much safer and easier to test, at a cost of only being able to express what the tool accepting the declarative approach can understand. Imperative approaches are strictly worse for any problem set where a declarative approach solves the problem within performance requirements. The additional expressiveness of languages like Pulumi is the last thing I want.

YAML is a horrible language for declarative system configuration because a) any sufficiently complex system will require you to generate your declarative codebase in the name of maintainability, b) generating code for any language where whitespace is significant will lead you to an early death, and c) stringly-typed languages are fundamentally unmaintainable at sufficient scale. But this is not an indictment of a declarative approach! It is an indictment of YAML.

> Configuration is code not data.

Data > code. Data does not need to be debugged. The best code you can have is deleted code - deleted code does not need to be maintained, updated, or patched. Code is a necessary evil we write in order to build operable systems, not a virtue in and of itself.

    local webdir = "/www/site/htdocs"

    templates = 
    {
      {
        template = "html/regular",
        output   = webdir .. "/index.html",
        items    = "7d",
        reverse  = true
      },
      
      {
        template = "rss",
        output   = webdir .. "/index.rss",
        items    = 15,
        reverse  = true
      },
      
      {
        template = "atom",
        output   = webdir .. "/index.atom",
        items    = 15,
        reverse  = true
      },
    }

Allowing computation can alleviate some of those problems, whether it's done "declaratively" (e.g. prolog-like, as in cue) or not (e.g. like idealised algol with memory cells).

The main reason to avoid jumping to something like Python isn't that it's "not declarative"; it's that Python is impure, and hence may give different results on each run (depending on external state, random number generators, etc.). Python can also perform arbitrary external effects, like deleting files, which is another manifestation of impurity that we'd generally like to avoid in config.

tl;dr The problem isn't the style of computation, it's the available primitives. Don't add non-deterministic or externally-visible effects to the language, and it wouldn't really matter to me whether it's "declarative" or not.

That data you are talking about does need to be debugged, like Helm charts and pipeline definitions. Sure data is better, but config is code, not data.

Whether the generated declarative output produces the expected behavior on the part of the tool interpreting the declarative output is part of the tool's contract, not the generator or the declarative output. If you need to check the tool's behavior then either a) you wrote the tool or b) you're writing an acceptance test for the tool, which is an entirely different endeavor.

There's nothing that prevents you from writing a unit test that runs `helm template` directly to check whether a given chart with given values will produce a given set of YAML files.

Config is both. Config variables are data. The code that accesses and uses those variables is...well...code. they should be kept separate. Like any other code and data. Config isn't a separate special entity, it's just another part of the program. The data part should be represented as such and the code part should be code. Trying to combine them and create a special 'config' language is mistake.

These are people that by and large don't want to code, not saying that they can't or won't.

To be fair this has been in Windows shops, where scripting has only recently (last 5-10 years) taken off, so you've got a lot of windows admins that the closest they've been to code is Batch scripting with a bit of Powershell. This is a big change for them

As it happens i read about pulumi recently and I've put it on mt list of todo things, but I can't see that I'll be able to sell it to our team and our team is blessed (cursed?) with three former developers

I disagree. That's the stereotype that tool builders have of such people. Good ops people have always loved coding, or we wouldn't be living on the mountains of Bash scripts also known as "Linux distributions".

(Besides, people who don't like to code won't like writing tons of declarative markup either. So there is little point in the current approach either way.)

As to the declarative markup, for instance Azure Devops still doesn't have feature parity between YAML pipelines and classic pipelines, so while you could well be right about the same resistance to yaml, it's not, necessarily an issue yet.

I'm on a relatively new team kind of like that (it's not a former Ops team but most of the team was pulled from Ops/DBA/analysis teams, and fits the description, and it's not a really a DevOps but more of a Dev+Ops team) and the general reaction of the team to being introduceed to the AWS CDK has been “we need to move to that as soon as we can”, even from people who very vocally never wanted to be programmers. And that's with, in many cases, a couple months experience with both programming and YAML IAC in the form of CloudFormation.

The more things change, the more they stay the same.

The pendulum is swinging back towards scripting languages. But give it a few years, and we'll be railing against scripting languages for not being idempotent enough, and moving back to the latest version of YAML and XML (perhaps we'll go with TOML this time) with custom interpreters.

We have seen this half a dozen times already, between turing complete DSLs in ruby, to plain bash, perl, and python scripts. The other side are the DSLs written using YAML, JSON, and XML (and every other config language written in history).

I've only really skimmed their documentation, but the idea that calling 'new' against a VM class instantiates a VM in production seems to be to magical for my taste, and might be an indication that it's yet another product that targets the happy path more than what we tend to experience in production: failures.

As any Lisper knows, code is data is code.

Could you share some details on that? A quick Google search didn't reveal anything about major changes to the SDK.

https://aws.amazon.com/cdk/