HN user
What withinboredom meant is that running processes in containers don't add overhead vs simply running them outside of them. That is mostly true because of the way that containers work in linux through cgroups and namespaces, which means that you would only be limited by what your hardware would already be able to run before running the processes in containers.
Since finding out about Kowloon walled city, I have been fascinated with it. Most cities have sections (usually older parts of them) that are maze like, and they are often my favorite parts of those cities.
It reminds me of the hive cities of Warhammer 40k.
Another analysis of Kowloon I enjoyed is this one by the architect Dami Lee [1].
[1] https://m.youtube.com/watch?v=WLn_QTFVZgE&pp=ygUFIzJhYWI%3D
I prefer using markdown files in a repo and generating my website using a SSG, because I find managing plain text files and a simple CI/CD pipeline to deploy easier to manage. The tooling for writing is my editor of choice, deploy is a git push and I don’t have to run a server or long running process. I can also easily migrate to any type of hosting more easily. I can see someone who is more used to Wordpress for example finding your workflow easier. It really mostly comes down to personal preference and what tools you are used to.
My understanding is that this is usually done by companies that need to implement delegated authorization which is the bread and butter of OAuth 2.0. By starting and implementing their authentication flows with OAuth2, you can support both delegated authorization and native authentication where your own apps are simply OAuth clients with some special casing. That isn’t absolutely necessary since you could build authentication separately from OAuth but then you would still need those OAuth2 flows for delegated authz eventually if you do.
I have found 1 to 2 week leaves not unusual. I am taking a month off this year after not taking any ptos around the holidays other than the mandatory ones for the last several years. I think I have seen summers to be much more common for long time offs.
I am in Canada.
Here is the github repo for httpyac [1]. Not sure why it's not part of the httpyac org that hosts the site.
To add another data point, I also moved on from Postman a while ago. Similarly to several commentors here I had found it to have become bloated, slow and buggy imho. In my particular use case, I found the urlencoding when using oauth1 to be pretty buggy. It would sometimes not work on certain headers it generated.
My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia which doesn't seem to be much better in my opinion.
I recently found httpyac[1]. It's a cli and file based http client similar to the IntelliJ HTTP client, but has plugins, hooks and allows scripting through javascript blocks. It seems to have everything I need but I haven't used it much yet. It also already supports gRPC.
One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request. Postman did provide some of that but that's one area I wanted more from any client I looked at. I could of course simply wrap curl in a script but at that point, I will be maintaining my own jerryrigged version of an http client for my team.
The use case would be the same as the one covered by jdbc and odbc. That is creating a standard interface to connect to databases at a lower level than the orm. This could then be used by an orm or query builder to communicate with the database. That’s how for example I can use Spring JPA and if I write either fairly portable sql or use the crud repository methods, I can connect to multiple different sql databases by simply providing a different jdbc URL.
How to handle the differing syntax of each databases would be handled at a higher level, by the query builder or orm. The orm could decide to let the user decide for themselves whether to write portable sql or not and fail at runtime, or like diesel in rust, enforce the useable features through its types.
In my experience that is something that is currently missing in the rust ecosystem. Each library seem to have its own connection logic and if I want to write a program that could run on different databases in rust right now, I have to write different code to connect to each database I would like to support.
Diesel has been serving me really well but I currently need to choose a specific backend when I am building a query, and implementing the above dynamic style of connection would be quite cumbersome to implement. It would be nice if we could choose another a standard sql backend where I would only be able to use a subset of features supported by most sql databases and build queries against that. Hopefully the RDBC project could help with something like that.
I think he makes some valid points. At first I was a bit ticked off that he is redefining what operating system means somewhat. But he is right in many ways and what really counts is the user experience(End user and developer). What mainly defines the user experience is the environment and GNOME is one. He touches on more than that and he does not leave out what is lower on the software stack. His confidence in the vision they have reassures me a bit that the linux desktop is still on the right way.