julenx

Additional context on the kernel guidelines:

- https://github.com/torvalds/linux/blob/master/Documentation/...

- https://lwn.net/Articles/1049830/

Got the same email. After reading the subject, plus the first paragraph:

  > I'm writing to you as the founder and strategic director of Infomaniak because something important has just happened, and it concerns you directly.

All in all the final message is great but the way it was communicated not so much.

In Mac I use:

   defaults write -g NSWindowShouldDragOnGesture -bool true

The article explains Zig's stance in further detail, but the quoted part on its own caught my attention because my reading of it is rather "pro human communication" instead of "anti-AI".

I believe the detachment gets exacerbated by the fact that others are simultaneously modifying the codebase at speeds that doesn't allow you to keep up. Depending on how the codebase boundaries and ownership are defined, this directly impacts your ability to reason about the whole system and therefore influence direction.

Code quality aside (n.b. there exist many bad quality codebases before AI), a risk I perceive as an industry is we are making the logic of our businesses dependent on a few big players.

Given the output speed, it's practically impossible for developers to keep up, which directly impacts maintenance: the knowledge that would previously reside in-house, now is becoming dependent on having codebases pre-processed by LLMs.

I hope in the near future local LLMs will gain traction and provide an alternative, otherwise we are in the risky path where businesses are over-reliant on a few big companies.

The same people that pursue economic incentives are who I hear speaking about number of lines produced by developers as a useful metric. I sense a worrying trend toward more is better with respect to output, when the north star IMHO should be to make something only as complex as necessary, but as simple as possible. The best code is no code at all.

Some employees in the company might understand the emotional impact, but companies themselves would only look for certainty in protecting what belongs to them, which will hardly align with fairness or emotions towards employees in a situation like this.

I'm seeing this cultural pattern where developers have started accepting LLM output with very little scrutiny. This ends up code that works on the surface, but most of the times problems are not addressed at their source.

Creating these wrong things is only cheaper with LLMs. Since developers now spend less time and effort to create that wrong thing, they don't feel the need validate or reflect on them so much.

The risk is not the tool itself, but the over-reliance on it and forgoing feedback loops that have made teams stronger, e.g. debugging, testing, and reasoning why something works a particular way.

Thanks for sharing! The link to the PR looks like a wrong paste. I found https://github.com/simonw/tools/pull/181 which seems to be what was intended to be shared instead.

Wir haben angefangen, unsere gesamte Infrastruktur zu kopieren. Unsere Daten befinden sich nun auf Servern sowohl in der Schweiz wie auch in Deutschland und Norwegen. Wenn nötig, können wir die Systeme in der Schweiz innerhalb von kurzer Zeit herunterfahren. Ich hoffte immer, solche Schritte nie einleiten zu müssen. Aber das Umfeld in der Schweiz ist für uns zurzeit zu unsicher. Wir hatten keine andere Wahl, als unseren Wegzug zu planen.

They started to copy the infrastructure, and the data is currently in Switzerland, Germany, and Norway. They can technically shut down the systems in Switzerland on short time. He (Andy Yen, CEO) always hoped they'd never need to take such steps, but the environment in Switzerland is too insecure for them at the moment. So they had no other choice but to plan their way out.

  > Also I don't like that React requires installing Node and compilation tools, this is a waste of time when making a quick prototype. Vue can be used without Node.

[1] https://react.dev/learn/installation#try-react

  > I don’t see enough value in the added complexity and the increasingly complicated API surface.

In terms of the complicated API surface and the difficulty to grasp newer concepts introduced with the app router, it continuously reminds me a couple lines of the Zen of Python[0]:

  > If the implementation is hard to explain, it's a bad idea.
  > If the implementation is easy to explain, it may be a good idea.

I was able to pre-order the book just fine — it didn't prompt me for any promo codes.

The multi-process Firefox project was called Electrolysis: https://wiki.mozilla.org/Electrolysis

For vanilla state machines there's also @xstate/fsm. In their docs[1] you have a feature comparison.

[1] https://xstate.js.org/docs/packages/xstate-fsm/

Well, it's also wonderful they speak Italian!

If you are descending at 40-50mph you have to remove your hand from your hood in order to see your map.

Well you don't have to, you can switch to the map screen before starting the descent. If you are willing to change screens while descending, the blame on safety is not on technology, but rather on your own decision to do so.

On this note, it's fascinating to see how the influence reaches the coat of arms and the flag of Saint Pierre and Miquelon, which includes the Basque flag or Ikurriña.

[0] https://en.wikipedia.org/wiki/Saint_Pierre_and_Miquelon [1] https://en.wikipedia.org/wiki/Ikurri%C3%B1a

With GitHub's squash + merge, clean history still depends on the person doing the merge, because when clicking the squash + merge button, GitHub places all commit messages in one large chunk of text, which devs are able to edit before confirming the merge, but it takes some discipline to do so.

In my experience, devs rarely pay attention to this, so commit messages end up as a big list of:

  * Ticket-1234 feature
  * fix
  * cleanups
  * fix
  * another fix
  * now the real fix

(edit: formatting)

If you close and re-open the app, eventually the ToS popup doesn't show up and you can keep using the app.

Thanks for clarifying, Lee!

Also excited about the Rust compiler! Apologies if this is far from reality, but by looking at recent commits in GH[1] it looks as though this has been rushed for a v12 release, so I was wondering how much of internal testing has this been going through before pushing it to the broader public.

[1] https://github.com/vercel/next.js/commits/canary

If roads are busy, it's worth noting traffic is created by motorized vehicles in the first place... plus, if slowing down is required to make roads safer, what? why is that a problem attributed to cyclists if usually (depending on which part of the world you live) cyclists don't have alternatives?

Nicely written article and very interesting read!

To be sure that there was as little background noise as possible, I ran all tests after a fresh reboot, making sure no unnecessary background processes, such as Windows Update, were running.

This made me laugh =)

In a more relevant note, probably worth pointing out to use production builds and running the browser in safe mode or with a clean profile (i.e. without any interfering extensions).

It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently.

I've been writing React code on and off since 2014 and I can relate to the pain: component creation and API changes in React (especially hooks) have meant quite a different way to do things, and in my experience this resulted in making things harder to understand across the board.

Life was simpler when `React.createClass()` was the only way to create components :)

Easier to remember: https://wa.me/<number>

Where `<number>` contains the international prefix without the `+` sign. Has worked for me in Firefox and everywhere else I've tried. This is a fb-owned domain btw.

For those who are curious, here's the source code of the original compiler written in OCaml (rustboot) https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216...

I haven't used JIRA recently, but as far as I remember the difference existed because they were rolling out a "new" editor, which was active when editing tickets, but wasn't available when creating new ones.

I remember this caused me some data corruption when editing a comment created with the old version of the editor using the new editor. It was a mess.

Out of curiosity, which post is that? I cannot find it.