skydhash

> Code signing, yes, but not for organization verification

They don’t do organization verification, but they do verify where code comes from. You may be sure that packages are built by alpine, which made sure that the dist files comes from the sources that the maintainers added, and the latter ensure that the sources are correct. In truth, it’s a very small circle of trust.

> You want them to make code more simple and elegant by themselves, no other direction?

No, he wants a project where AI is used as a major help, but the result tend towards good code, i.e readable and well abstracted. Even if the cost is high, just an example where you can extract the best practices of using AI coding.

> But now the cost of writing custom tooling has changed. These custom tools might be sloppy because vibe-coded but we wouldn't have them otherwise

There’s a lot of good tools out there that are not used, either because of ignorance of their existence or lack of expertise. An hour of config can pay real dividend later.

And sometimes you just use some unix utilities and hack a bash script while testing things out.

> Let’s say you have an incident, and you need a resolution. Do you send out the AI for the hunt and fix it within 5 minutes, or spend 30 minutes going around, figuring out the problem yourself?

Let’s say you have an incident, and you need a resolution. Do you spend 5 minutes tinking, then solving the problem or send out the AI for the hunt and spend 30 minutes grappling with hallucinations and non-sensical output?

The 5 minutes I’ve seen is usually by someone that will send the complete output to someone else to decipher, while saying they have figured it out. Then they’ll turn into a meat proxy between the team and the agent.

In real life, for systems where incidents that require such rapid responses, you usually have fail-safes an killswitches. When you were designing your system, did you put in place alerts and monitoring to mitigate risks?

> these randoms assuming foreign banks accept every human is really funny,

Did I imply that? Creating a bank account in my country is an adventure on its own. If I got 50 USD in my wallet, I can exchange it somewhere and pay for food and whatever. My crypto account requires a computer, an internet connection, and someone willing to take it (no one around here).

My wealth may be decentralized, but my body is in one location and pretty vulnerable to the 5 dollar wrench. Putting some emergency money in a foreign bank account and a bag is a much better option if I wanted to flee a country.

It always about “we solved the bottleneck in coding”. But the slowness was not about typing, or finding docs. It’s always about ensuring screwups don’t happen.

> "Resisting" is like refusing to use a shovel at your ditch-digging job

If they come to me with a cartoon-like contraception that comes straight from Acme, you can understand how reluctant I am to not be blown up like Coyote.

Emacs called it “point” which is not as far. The cursor is just the visible widget.

> does the sourcing and information then become more valuable? Or are we going to finally be ok with ambiguity as humans?

I think they do become more valuable. Who said something and who believe it is equally as important as what was said.

Not sure why a solution is even needed. If I had to compile all the resources I had consulted for something like C programming, they wouldn't amount to a single shelf. I would say the same thing for research where the amount of sources is still very low. It's kinda reminded me of the big paper manuals and books before the internet. I don't think the whole library of congress was needed to write UNIX.

So AI being a source of truth and information is not a something that important. It's a generator and we should use it as such, getting it to map domains and repeating patterns. It should not be used as an encyclopedia or oracle.

> even though the question could have some minute detail that was different, or perhaps there was some recent change in the landscape that meant an answer in 2020 would be different from one in 2013.

I would generally classify those as “homework” questions.

> There are a few big projects that redirect the compiler output and attempt to print only one line per output file, so when all goes well there is much less output text, but with those it is usually more difficult to debug failures.

Why? If you use something like tee(1), you can get the full log in a file and then filter line according to what you want.

> Compiling any big software project produces far more text output than can be stored in any pty buffers.

The reason of my skepticism is that, according to your statement, reading a source file, then writing the compiled object file is way faster than a few printf through a kernel object in memory. Even for the terminal consuming the characters, parsing, and displaying the lines should not be a computation hog for most terminals

There's a wealth of packages and the documentation for emacs-lisp is quite extensive. It's not some esoteric language. But what I'm talking about is that the code for the packages can be quite simple and readable.

> Is anybody here consciously trying to keep their Emacs configs/setup "lean", minimalist, as small as possible?

I tried but most of my config is just variable settings (with the use-package macro). I don’t really have custom code there. If I do think about a feature, I tried to build a package instead (like one for bridging subsonic and emms).

Most of emacs is lisp. The actual C part is quite small considering the capabilities of the system. Lisp being what it is, it’s moslty about domain knowledge than language expertise.

> A reason why the terminal emulator speed is important for me is that I frequently compile big software projects and I find it unacceptable for a compilation to be slowed down by the low speed at which the compiler output is displayed on the terminal window

I’m strongly skeptical of this as pty are character devices and buffered. Programs and terminal are very loosely connected.

You can rewrite all of the cli utils to fit your preferences. There’s no hard standard for piping (some utility pipe binary) and bash is not a requirement either (a shell is just a program).

No need to push it to people. Do it for yourself and create your community around it.

Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.

We should follows the real world model and design constant interfaces instead of wishing for a changeable one. It’s not like there’s a multitude of tasks people wants to do constantly.

You can install stuff--with tic(1)--inside your user account (you do have one, right?) and be happy that way.

This days I don't really care about the terminal I use. It's xterm on OpenBSD, konsole on Fedora KDE, terminal.app on MacOS,... As long as I can use cli and the few TUI software I use.

> It's totally fine for basic UNIX tooling, but pretty painful if you're trying to make nice interactive TUIs.

The latter seems always to be about aesthetics, not about UX.

> I just try to spend as much time as I can in a terminal

GUI are useful, but I spent so much time trying to find the perfect ones while I could quickly draft a quick CLI script for my specific problems. These days, I focus on finding libraries and utilities that solves the core of my problem, then wire them up in a way that solves my workflow. After a while, you just find that most of your computing needs are solved.

What about reliability and simplicity? First, what is your definition of productivity? Does it leans towards more output or more value.

I used Balsamiq for that. The “pencil” render of the shapes make it obvious to not discuss aesthetics issues and only focus on flows.

It’s like discussing a fully rendered concept art. You will get lost in the picture. And there’s always the slight suggestion “it’s already looking so nice, why think harder”. Which is why sketches and roughly painted thumbnails are best for brainstorming. Easier to think out of the box that way.

Same with demo. Do a rough wireframe or something with default bootstrap style and it’s way easier to target the meat of the problem. Not so much on a full site

Speaking of screen waste, I think 4:3 is way better than 16:9, especially for laptop screens.

I’ve replaced the android headunit with a buttons and segmented display one (kenwood) because it was just horrendous. Now, it’s easy to switch sources, skip back and forth, and adjust volume with minimal looking. Tactical feedback and location memory is great UX.

I have my iPhone 13 in a $10 cover for years now. I don’t like the bump, but I don’t think it’s a scheme to buy covers.

Also my favorite smartphone was a motorola with a cloth back (ballistic something) and a metal frame. No cover was needed for this one.

It’s pretty much the same. If product has no new ideas and the software is working well, then only light maintenance and monitoring work is left.