softirq

Side note, but I hate that we're moving to a world where coding costs a subscription. I fell in love with coding because I could take my dad's old Thinkpad, install Linux for free - fire up Emacs and start hacking without an internet connection.

We're truly building walls everywhere.

The "owner" could be multiple directory levels depending the hosting service. Gitlab lets you have arbitrary sub levels. The owner of the files also isn't necessarily related to the owner of the repo on Github.

GOPATH actually made me realize that the

~/src/$host/$owner/$repo

organization structure makes a ton of sense for every project and as long as you organize all of your languages into this one tree, everything just works.

Which is terrible UI. Let's force the user to turn a flow they could do at any time by clicking a single button at the bottom of their desktop into a context switch into another window, followed by the same button click. Or know about the Magic Keyboard short cut, then type in multiple characters, then press enter. So in any case we're turning a single input into multiple inputs just to open a commonly used app.

No it's not, for several reasons:

1. Average users primarily use mouse based workflows.

2. Super isn't discoverable.

3. It confused users coming from other DEs.

4. It actually takes more keypresses than clicking a favorited app on a dock that is always available.

Overall it's less discoverable, less efficient, and not baked into the mind of computer users who are coming from almost any other bistro.

Every DE is designed to be used in a distribution. I think what you are trying to say is that GNOME is designed to be "finished" by the distribution, which is a completely made up idea. Show me where GNOME says you need to finish the DE yourself during integration. GNOME is designed as a complete DE, the reason Canonical/System76 change it is because it's poorly designed for new users/casuals, which is their user base.

You just linked to studies that directly support my point:

"On the other hand, new users generally got up to speed more quickly with Endless OS, often due to its similarity to Windows. Many of these testers found the bottom panel to be an easy way to switch applications. They also made use of the minimize button. In comparison, both GNOME 3.38 and the prototype generally took more adjustment for these users.

“I really liked that it’s similar to the Windows display that I have.” —Comment on Endless OS by a non-GNOME user"

GNOME has come a long way, but its stubborn insistence on not having a desktop with a real application launcher remains a huge usability misstep. GNOME's marketshare is the desktop, and so the initial value proposition of a hybrid UI seems very much wishful thinking, while the keyboard based workflows it seems to want to enable are better served by tiling WM such as Sway, and do not make sense for the "default" WM that is picked up by casual converts who are used to a point and click system. Overall it's just a confusing mess for new users, which Canonical/System76 rationally get rid of (which is probably a majority of the GNOME user base).

So why does GNOME continue down this path. Is it a fear of being "just like everyone else" by using a tried and true dock/application bar? Is it a desire to not be the front running WM and be more "niche" to power users? I still don't really understand their decision making process.

Meanwhile the CEO of Nvidia is telling the world that people don't need to learn to code and we'll all be out of jobs soon.

Chess is a bounded, non-moving target. Think about the difference between chess in the 1970s and today, and compare that to the same time period with programming. Chess is a single game whereas programming is a federation of tools, protocols, and standards that are ever evolving. They're not comparable in any sense.

The post is about the demise of coding. I'm only responding to the topic of the discussion.

You can say that about any field. We could invent the elixir of immortality tomorrow, but is that a realistic expectation? The CEO of Nvidia is a smart guy, he's pushing the hype train because his business is riding the wave. But you have to separate hype from an empirical view of what we can actually do today with these tools, versus what hasn't been delivered and is being oversold.

No-code isn't a new concept, and there's a reason why all past attempts have failed, or why people still pay web developers despite the existence of tools like square space. Nothing about the LLMs of today suggests they have solved the no-code problems or will radically displace coding. They generate bad, oftentimes incorrect code for well trodden paths, while struggling to solve novel problems or work in private or unique code bases. They do not easily keep up with new trends or tools. They do not offer the type of semantic understanding that is necessary to work in a logic based field.

LLMs are nothing more than an alternative take on auto-complete, a feature that has been around forever and doesn't radically change programming. It will speed up good programmers to some degree and probably lead to bugs and more bad code from everyone else.

This is yet another hype cycle overselling a modest advancement in technology.

The genius of ebpf is allowing for pluggable policy in a world where the kernel API is very slow to change and can’t meet everyone’s needs. Whether it’s how the kernel handles packets off the wire, how it controls traffic, scheduling entities, or instrumentation, ebpf lets you provide logic rather than turn a bunch of knobs or use a bespoke syscall that only handles one case. It also moves the processing logic to the data in the kernel rather than having the kernel have to do expensive copies to and from userspace.

ebpf isn’t really novel beyond the interfaces it provides. They are just kernel modules that have been vetted and are sandboxed. Inserting executable code has been part of the kernel since forever in module form and kprobes.

Most companies completely missed the point of SRE/PE/DevOps and keep them on separate teams doing sysadmin toil work and oncall thrown over the wall by engineers who are only concerned with feature deadlines. They regress them back to sysadmin duties and get none of the value of a true SRE program.

SRE should always be a subtitle for a SWE and not a separate position, and they should always be embedded with SWEs into one team either building products of infrastructure. The shared ownership and toil reduction only works if you have these two things.

All this said, I think the regression is also due to the fact that real SREs are rare. A solid SWE that also has deep systems domain knowledge, understanding how to sift through dashboards and live data, and root cause complex performance problems is a master of many domains and is hard to find.

I've had a lot of trouble with commands in Warp going haywire because of how much magic there is in creating visual blocks, and it looks like Jet Brains is taking it one step further. The reason terminals are great is because they are dumb, standard interfaces where you can have full access to any system, local or remote, and directly execute binaries and interact with a command language like bash or zsh.

I feel like this terminal is counterproductive. It adds visual niceties at the cost of dumbing down the power of the terminal and removing terminal feature that will be confusing to regular terminal users. It really doesn't have to be this complicated to be useful.

Yes it is. Watching a 3D movie on an entire wall in bed next to my spouse is mind blowing.

Macros are easy to spot, the whole point of operator overloading is that it's a trojan horse. It might do simple addition, it might do a heap allocation and talk to a printer.

I disagree, consider a generic that is constrained by std::ops::Add. If you want to write generic functions with this type, you have to contend with types that might do simple addition or do allocations with potential side effects.

This is an extremely common issue to deal with when creating a kernel, which is, again, why levels of indirection in code and hiding context only makes life more difficult for a systems developer. The kernel may need to enable accelerators, switch between arm and thumb, enable an fpu, clear cache lines, etc. A lot of decisions will be made by the compiler, but based upon parameters passed in at build time, and a lot of it will be arch specific code interwoven in assembly. And there are tons of times when a compiler will generate things you don't want, forcing you to add pragmas and so forth.

See my other comment about the necessity of clarity in a systems language. Also in my opinion readable code is code that is easily understood with as little context as possible. Operator overloading is the opposite, it hides behavior based on the types of the operands. Instead of thinking, that * will turn in to an smul, we now have to check for and read the implementation of * for every type. A function makes it clear that there is a call site and the types of its operands, and the name can more clearly convey the meaning of what is to be done than *.

What you are referring to as readability is actually terseness, which I think is a lousy metric to optimize for, especially for systems software where correctness is important and people will read code a lot more than they will write it.

When writing systems software like a kernel, clarity is far more important than ergonomics. The basic operators aren't functions, they're translated directly into opcodes based on the types of the operands. Operator overloading allows them to be either opcodes or functions, and if you think about the amount of work that goes into a function - saving registers, creating a stack frame, pushing addresses, multiple branches - versus a single opcode, as a kernel developer you really don't want this to be hidden behavior based on whether something has been overloaded or not. In the best case the compiler will optimistically inline multiple instructions, in the worse case it will call a function before you've even set up a stack.

The standard library being designed to allow freestanding binaries makes Zig a much better language for systems software such as kernels, EFI applications, etc. than Rust.

Rust's addition of operator overloading is also a perplexingly bad decision. I don't think there is a single worse design decision in C++ or Rust than allowing someone to redefine what + means on some arbitrary type.

D is a real anomaly to me because it should have had the same trajectory as Rust, it vastly improved upon other systems languages at conception, the authors evangelized it, including at FAANG, and yet, Rust seems to have gained traction everywhere D failed to do so. Even in places where C++ has historically been shunned, Rust has some traction (Linux Kernel). I now believe that language adoption is just a product of the right news cycles and timing, and perhaps hype over the creators or a certain feature. I am sad we got Rust and not D. D is so much easier to grok as a C++ person, and I think Rust is incredibly verbose looking.

BBEdit is a phenomenal editor, and when I'm not using Vim, I'm using BBEdit. BBEdit has everything VSCode has, plus the benefit of supporting a small company that doesn't spy on you or want to own the developer experience. They just make an amazing native editor that's blazing fast at all times.

If you can afford it, buy a copy. BBedit is not just a great tool, it's a piece of history. It's like buying a classic car that's continued to be updated with all the modern niceties to make it both fun to drive and frustration free. I really can't recommend it enough.

I assume you're joking right? Vim/Neovim have already diverged. They have completely separate scripting languages now, config languages for the main config file, and Neovim has LSP support out of the box, removed cscope and a bunch of other built ins... They have about as much in common as Vim has with Helix.

Semantics. Some of the packages are included, all of them have to be turned on and configured, and hopefully the user already knows about use package and understands the syntax for customizations and keybindings. Of course, if they try to Google how to use these packages they'll realize that Eglot doesn't work with DAP, so if you want to debug anything you'll need to go download the third party lsp-mode and dap-mode, configure them, then realize everyone uses swiper, consul, etc. which you'll need to download and configure as well.

> but really the defaults are fine -- just old.

I assume this is just Stockholm syndrome. Every Emacs config starts by turning on the same minor modes hooked to prog major modes for simple stuff like bracket matching and line numbers. Every config sets the same early-init.el params to stop emacs from being slow. If the defaults were sane, everyone wouldn't be disabling and enabling the same stuff in their config. The defaults are not sane precisely because people complain that changing any of the defaults for a 30 year old editor in 2024 is tantamount to open source treason.

I think a lot of people would argue that Emacs is also slow and bloated, but makes you, the user, program most of the functionality you get from VSCode or JB out of the box. Want fuzzing finding? That's a package. Want git integration? That's a package. Want LSP? Also a package. Want to have sane defaults? Go look at 20 different init.els online and cargo cult a bunch of elisp. And after you've made your own Emacs stew spend, the next 14 years stomping out bugs and ignoring the things it still can't do, like run a multi-threaded tramp so a bad connection doesn't freeze your entire editor.

I think the people who switch from editor to editor that requires 0 config actually saved time and money by just doing their job rather than configuring their editor, and this is coming from a Vim user. Emacs is a black whole where "free" time gets sucked in never to be seen again. The big difference is as a Vim user I only had to configure my editor, you had to configure your entire operating system including Org mode.

I also am not sure about the whole Vim thing. On reddit, Vim has 3x the number of community users as Emacs and Neovim. I think Vim is still by far the most popular text based editor, but nowadays I think VSCode is unfortunately here to stay because Microsoft knows the value of having a captive developer audience.

Do you see when the last commit to that project was? Slack really did murder IRC and open chat protocols. Allowing an IRC bridge for a limited amount of time was a genius trojan horse.

I really meant it when I said that AI will kill Emacs. In the future every application will be connected to a backend inference engine to act as the primary or close to primary interface to the application. A calculator that can't run prompts is going to be like using an abacus in a few years. Same thing for Magit/regular git.