nrvn

I am the one who had been using g suite before it became google workspace for more than a decade.. Last year I changed my email provider, cancelled workspace subscription and deleted the google account only to create a new one with the same email address as a normal user. Used google takeout to transfer all valuable assets out.

I lost access to literally nothing! SSO binds your email address as the primary account idenitifier in all known to me services. Does not matter what IDP you use to “sign in with”.

I find this twitter thread misleading. Unless the affected account was using @gmail.com as their primary identity.

Buy a domain and set up email on custom domain. backup emails periodically outside of the provider to be able to switch easy if needed. Same applies to other data stored in SAAS of any kind. This is the rule of thumb if the risk of losing access to tour primary IDP is critical.

Assess the risk and act accordingly.

This!

Unfortunately, the term “reproducible” can be interpreted in many ways because there is no strict and complete definition. People and projects bend it to their liking.

Your approach is correct.

https://www.bootstrappable.org/

Should I freeze my plans to migrate from `poetry` to `uv` at "${WORK}"?

Exactly my thoughts immediately after reading the word “just”. Also, PITR.

The whole article is tongue in cheek. And I struggle to find any comment here that would actually verify and confirm (or not) the results of the author.

So here I am, random hacker news links verifier.

Scrolling to the image below "So, for example, grabbing it here does not work:" text and reproducing the issue with a small caveat: just moving cursor 1 (ONE) pixel right turns the cursor into the "diagonal resizing mode" cursor. Overall, the resizing area of the window corner is comfortably bigger than the author draws. Dragging empty space outside the rounded corner is weird but what isn't in today's user interface designs?

All in all have never experienced difficulties resizing windows in macos.

Miss the times of windows 95/98 and macos 9 (as some other commenters here) when OS UI was designed by humans and for humans and everything was explicitly clear including the area for window resizing.

Exactly. You can “have a vision” to accelerate full speed and hit the hard wall and just before going full throttle you are offered an opportunity to enter an open door around the corner which you have never even thought about. And that door helps you discover a new vision, that might stick for lifetime.

Also, while the original advice about “vision” sounds reasonable, it also sounds a bit dogmatic. The filpside of “career vision” is “tunnel vision”. And life is not deterministic, it has a much more probabalistic nature. Hence, curiosity and open mind.

Not being able to give granular permissions to folders is not the problem of an app which regardless of being open or closed source may be compromised. Remember that the risk is zero if and only if you avoid the risk, i.e. in this particular case do not install Obsidian.

Macos:

- does not have a granular permissions model as far as I know;

- deprecated sandbox-exec that allowed to achieve the above;

- macos appstore is a very strange phenomenon, I would not put much trust in it by default.

Obsidian:

- has a system of community plugins and themes which is dangerous and has been discussed multiple times[0]. But the problem of managing community plugins is not unique to them. Malicious npm packages, go modules and rust crates (and you name it) anyone?.. you are on your own here mostly. And you need to perform your own due diligence of those community supported random bits.

Obsidian could hugely benefit from an independent audit of the closed source base. That would help build trust in the core of their product.

[0] https://www.emilebangma.com/Writings/Blog/An-open-letter-to-...

Website with background-color: #FDDB29 talking about color choices.

Irony at its best.

One of the worst things about Environment variables among others discussed here is the implicit and opaque nature of them. Majority of applications rely on them in the *nix world. Even if more explicit and obvious ways of configuration files or remote services (consul/etcd, et al.) and command line arguments are supported env vars are traditionally supported as well.

But as mentioned in the article it is just a global hashmap that can be cloned and extended for child processes. Maybe in 1979 it was a good design decision. Today it sometimes hurts.

For example, kubernetes by default literally pollutes the container’s environment with so-called service links. And you will have fun time debugging a broken application if any of those “default” env vars conflict with the env vars that your app might expect to see.

https://kubernetes.io/docs/tutorials/services/connect-applic...

They are ubiquitous and we are living in the world of neo-conservatism in IT where legacy corner cuts are treated as a standard and never challenged (hello /bin, /usr/bin, /lib, /usr/lib)[0]

[0] https://askubuntu.com/a/135679

Design system as any other human-built system requires to be documented and described in order to maintain integrity where the integrity will be described in clear terms via foundational principles that the rest of the system is built upon. I am surprised to see how some things in today's world fall apart despite in mere seconds despite enormous amount of prior art and experience and lessons learnt.

As they say, YMMV.

My personal journey:

2010-2014 - sublime text

2014-2017 - vim and later neovim (bunch of plugins to resemble IDE-like experience)

2017-2024 - jetbrains (intellij idea with language plugins mostly)

2024-now - neovim (with lazyvim)

I tried helix in 2023 but it did not stick. Do not remember details but remember the final impressions of having to train muscle memory to “awkward” vim-like key bindings and dealing with various annoyances and bugs. End of trial and error I left it as a terminal $EDITOR for quick and adhoc tasks while doing all the heavylifting in intellij. Ditched it finally when vim muscle memory and hx muscle memory made my brain short circuit several times in a row.

Now I am back to neovim and it is surprisingly as productive (when equipped with proper plugins) as the beefy jetbrains IDEs.

That said, helix looks promising. Maybe it’s the next big thing, who knows)

To honor the memory of this noble man I am using a single bladed razor.

I used the following sources to create an RFC template (and promote the document culture across the engineering documentation):

- https://www.industrialempathy.com/posts/design-docs-at-googl...

- https://github.com/rust-lang/rfcs

- https://github.com/kubernetes/enhancements/blob/master/keps/...

- https://blog.pragmaticengineer.com/rfcs-and-design-docs/

Hint: tailor the process and template structure based on your org size/maturity and needs. Don’t try to blindly mimic/imitate.

The image attached to this blog post is a stock photo of a nude pregnant woman. Absolutely nothing sexual.

maiesiophilia (pregnancy fetishism), maschalagnia (armpit fetishism)…

cybersecurity 101:

- know your threats

- assess your risks based on identified threats

- backup 3-2-1 strategy (3 copies of your data on 2 independent storage places with 1 copy offline and offsite)

- "build the world from scratch" plan with the assumption that all infra is completely and irreversibly destroyed.

- assume you have already been hacked but you don't yet know about it. Build your indicators of compromise based on that simple assumption.

Observing how some "groups of people" act in a totally ignorant fashion is amusing.

also a great guide for building production-ready containers using uv:

https://hynek.me/articles/docker-uv/

this is my new fav for running small executable scripts:

  #!/usr/bin/env -S uv --quiet run --script
  # /// script
  # requires-python = ">=3.13"
  # dependencies = [
  #     "python-dateutil",
  # ]
  # ///
  #
  # [python script that needs dateutil]

In my org I have enforced linear history, squashing all commits into one in PRs and roughly following the rule from [1]:

If the request is accepted, all commits will be squashed, and the final commit description will be composed by concatenating the pull request's title and description.

One less thing to think about.

Less is more, not vice versa.

[1] https://go.dev/doc/contribute#review

Synonym search is rocket science. It will take 20 years after they figure out n-gram search (i.e. “srceen time”, “cellluar”, et al.) and keyword search (“Set charge limit”)

And it applies to all apple operating systems.

Basic UX is not sexy nowadays.

I have been using the "bare git at $HOMEDIR"[0] approach for several years.

Benefits:

1. no extra tools.

2. one off task for setting up the git repo and alias `dotfiles='/usr/bin/git --git-dir=${HOME}/.config/dotfiles --work-tree=${HOME}'`

3. all files are where they are, no symlinks, copies, etc.

Caveats:

1. $HOME/.gitignore just ignores everything because it contains a single "*" char[1]. So adding new files must be done with dotfiles add -f ~/.newfile to track.

Refs:

[0] https://www.atlassian.com/git/tutorials/dotfiles [1] - https://github.com/nrvnrvn/dotfiles/blob/main/.gitignore

exactly. I am surprised by the amount of comments in this and similar threads praying for github to add more complexity to an already over-complicated and fragile solution.

CI must be local-first and platform-agnostic.

you are not alone... https://socket.dev/blog/curl-project-and-go-security-teams-r...

I believe there must be some "Murphy's law" or something with a name for that situation. When there is an established system and process there will be people geniunely using and it will work 100% for such people and bring value to all parties. And then there will be people "gaming the system" (for instance "security" "researchers" using CVE created by them as a personal or corporate KPI) and abusing other legitimate players. It is like patent trolls but better fortunately for us.

Fortunately for all people of reason, the system itself gets patched. Maybe not in the best way possible but still. Two examples:

- Openvex - this is my way as a project owner/developer/maintainer to declare that CVE-XXXX-YYYYY is false positive and why.

- context-aware vulnerability scanning (or exploitability scanning) - govulncheck is a great example of that. You run and it says, module X has vulnerabilities Y and Z but you keep calm because we have not found any symbols in your codebase using it.

I wish more scanners would adopt the second approach and projects like npm would greatly benefit from it. As you truly note you pick a random project and it will be 50% filled with ReDos or something that will be sitting in some nested dependency of eslint's dep tree that will never see the light of production environment's CPU.

That being said, any vulnerability reporting and obtaining a CVE ID bypassing the project's security policies and responsible disclosure procedures must be prohibited. As a maintainer I want to know about a newly discovered vulnerability in my code to fix it and then the kind person that reported it to me can proceed to MITRE with the report in one hand and fixed version in the other.

Bevy is young and changes quickly. Each update brought with it incredible features, but also a substantial amount of API thrash

Bevy is still in the early stages of development. Important features are missing. Documentation is sparse. A new version of Bevy containing breaking changes to the API is released approximately once every 3 months.

I would choose Bevy if and only if I would like to be heavily involved in the development of Bevy itself.

And never for anything that requires a steady foundation.

Programming language does not matter. Choose the right tool for job and be pragmatic.

what happened to the "$5 is just a cup o' coffee" argument? Are we heading towards the everything-for-$100 land?

On a serious note, there is no clear evidence that any of the LLM-based code assistants will contribute to saving developer time. Depends on the phase of the project you are in and on a multitude of factors.

I can't "shake off" the feeling that this whole MCP/LLM thing is moving in the wrong if not the opposite direction. Up until recently we have been dealing with (or striving to build) deterministic systems in the sense that the output of such systems is expected to be the same given the same input. LLMs with all respect to them behave on a completely opposite premise. There is zero guarantee a given LLM will respond with the same output to the same exact "prompt". Which is OK because that's how natural human languages work and LLMs are perfectly trained to mimic human language.

But now we have to contain all the relevant emerging threats via teaching the LLM to translate user queries from natural language to some intermediate structured yet non-deterministic representation(subset of Python in the case of CaMeL), and validate the generated code using the conventional methods (deterministic systems, i.e. CaMeL interpreter) against pre-defined policies. Which is fine on paper but every new component (Q-LLM, interpreter, policies, policy engine) will have its own bouquet of threat vectors to be assessed and addressed.

The idea of some "magic" system translating natural language query into series of commands is nice. But this is one of those moments I am afraid I would prefer a "faster horse" especially for the likes of sending emails and organizing my music collection...

from Go documentation[0]:

Committing profiles directly in the source repository is recommended as profiles are an input to the build important for reproducible (and performant!) builds. Storing alongside the source simplifies the build experience as there are no additional steps to get the profile beyond fetching the source.

I very much hope other languages/frameworks can do the same.

[0] https://go.dev/doc/pgo#building

This is essentially how separation of duties(and concerns) looks like. And this is how some of the good examples of projects work. Specific techniques and tooling and specific boundaries of CI and CD vary depending on the nature of the end product but conceptually you are absolutely right.

A lot of projects and teams have been successfully using all tools mentioned in both CI and local dev envs. Portability and reusability of this “glue” stuff is a nice indicator of engineering maturity and culture within those projects and teams.

Low pro teams and individuals will happily abuse any new tool.

Mature teams stick to local-first CI - i.e. be able to run pipeline locally - and then translate to whatever is being used in their build and test infrastructure.

It resonates with me wrt muscle memory and ubiquity of “standard tools” that come pre-installed in majority of *nix distros including macos.

But there is a big BUT! Lately I have to use grep/find huge nested dirs and found rg to be an order of magnitude faster. Had to get myself comfortable with retraining the muscle memory. Worth the effort.

Some of these new shiny tools are meh for my taste. Delta for instance. Or helix the editor. But it is personal. Overall I love the competition. It seems like industry once full of innovators and tinkerers is lacking some shake up.

Have never been using facebook. Gave instagram a short stint few years ago to remove it eventually because of too high ads/friends ratio in the feed. No problem in organizing social life.

FWIW, whatsapp provides excellent capabilities (well, for 2025 where only old timers remember phpBB and can compare to it) for local community discussions and meetups, interest groups, parent groups, whatever group discussions and coordination.