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.
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.
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.
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.
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.
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.
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.
We're truly building walls everywhere.