> The LWN site has been improved in a number of ways, with features like articles in EPUB format,
This is the single biggest feature that makes me keep my subscription going. The convenience to read longer form offline on my ebook reader makes me wish all other long form content websites would have the same.
Do they offer a facility for automatically mailing the epub file to a specified e-mail address (I'm thinking the Amazon Kindle conversion e-mail) --- that might push me over into a subscription.
Not a PDF, the ePub --- each Amazon Kindle has associated with it an e-mail address, which when a file is e-mailed to it, will be automatically converted and loaded (once the sender is white-listed) --- that way, each new issue would just automagically appear.
At first I thought it was this Hy[1], oh well one can dream.
> Hy4 preview came out slightly ahead of both GLM 5.3 (2.99 vs. 2.92 average, 46.8% wins / 12.8% ties / 40.4% losses) and Kimi K3 (2.99 vs. 2.94, 51.2% wins / 7.9% ties / 40.9% losses).
This is extremely impressive if true that they are able to beat both K3 and HLM 5.3 however an someone who doesn't know anything about this space. How much better is 2.99 compared to 2.94 or 2.92? This difference to me seems very marginal. Or is only meant to say that they are in the same "category"?
I would guess such a small difference is within the error margin so "roughly equal" I think is fair to say but different models are good at difference things in practice. It is about the same size as GLM 5.3 at about half the price (cached price even less). I believe it's on the intelligence/price pareto frontier.
I have tested their Hy3 a bit and it feels okay. That one went from preview to release in less than three months with a substantial increase in benchmarks. But who knows how this space looks like in three months from now.
> My friends tell me the job is basically managing AI agents and reading Pull Requests. That sounds like hell, and I’ll try to avoid it for as long as possible.
It really is not that bad when you are in a company with a good culture. Leadership is gonna be AI piled everywhere, but imho that's how you learn where to use (and not to use) the technology.
Most places I know that have strict on-premise/air-gap requirements are just investing in on-premise AI and open source harnesses instead. The only ones that don't are the typical places that are slow to adopt technology in general (usually because they can afford to due to historic moat).
Most places that must do things on-prem also have strict requirements and long deadlines.
LLMs can be nice sometimes, but not necessary. Internal teams with "not invented here" syndrome currently working on that stuff are ultimately wasting money until the dust settles a bit more.
Those long deadlines have nothing to do with implementation. It's the game of telephone and accountability bottlenecks. You still want to retain your most experienced devs and give them plenty of time to work. Writing the code was never the bottleneck. A good dev team has balanced experience of the business and the code, not just the code, and certainly not the kind of code an LLM generates. Most of the decisions by those devs happens outside the codebase.
I can only tell you what we see across our customers, which are exactly the on-premise crowd. We are building a ChatGPT/Cowork competitor focused on on-premise needs[0]. While we cover most things outside of the coding side of things, I know that all of them are also embracing coding agents, typically with your usual open weight coding models hosted on-premise.
Sure, the slow behemoths that you talk about exist as well, but I am seeing many companies that have successfully turned compliance into just another kind of process that isn't slowing down the product development lifecycle. And within those process steps they are also able to leverage AI to speed up e.g. review processes.
I interact with plenty of companies - not a statistically relevant amount, but dozens. I'd put this at about 50% right now. I certainly deal with a not insignificant number of meat proxy CEOs, which is highly annoying for the people worrying about the details. But it's not impossible to work with. I just accept the overhead and hope it gets better.
I disagree. Having to work with the clanker is hell on earth. I'll do it if I have to, because I need to eat, but I hate every second I have to put up with those stupid things.
I too have enjoyed vibing some random shit on the side and not having to beg people to build features I want anymore, but knowingly shipping subpar agentic code at work still kills me a little. (Well there’s no pressure on me to ship, but as a self-respecting guy, I hesitate to say I’ll need 5-10x time to really get to the quality I want when 1x time already gets something working, except for really critical components.)
There has been so many projects that I never have had time to do that I've been able to acxomplish thanks to agents.
Setting up more precise automation for my home assistant, expanding android apps with features tha maintainer didn't want to add but I wanted to have, having agents troubleshoot issues in my homelab servers, writing apps from scratch to meet my needs. Ahh, I love it so much.
If you really want to be lazy, use a terminal file manager (I prefer lf[0]) it helps avoiding the cd && ls dance. That way, your history only contains commands you actually would want to rerun.
jj looks very interesting and the hipster in me wants to adopt it, but my muscle memory is wired to Magit, I am not even an Emacs user, but I reach to it just for doing git stuff. So far none of the frontends for jj comes close.
I had that exact problem, but I've been working on a fork of another tool to try to improve the situation. It isn't a clone of magit, but it has a basic form of the same type of command interface, with a lot of the same benefits (easily seeing the tree of nested available commands and activating them with single letters, seeing what's going on with your repo live, WYSIWYG, and editing it with those commands). It's single-handedly allowed me to switch from git to jj without feeling lost
As someone that constantly reached for some sort of GUI/TUI tool to work with git repos, I can understand the hesitation. The normal git CLI is sufficiently opaque and my interest in it is sufficiently low that those tools were really the only way I could work done efficiently since they made the arcane ways of git a bit more evident.
The curious thing for me is that with jj I find that I don't ever really reach for a GUI/TUI anymore. At first I did try a GUI, but then I realized that the vast majority of what I want to get done conceptually didn't require it. So most of what I do now is just using the jj command line and very rarely do I reach for any sort of other tool.
The exceptions to the GUI/TUI use are resolving conflicts. For me being able to see the conflicts side by side and much more interactively choosing which I want is still more comfortable than simply hand-editing the file. And I also find I'm searching or chatting with an LLM anything I want to do something a little more advanced and less common, like rebasing all my feature branches on the most current mainline branch in one command... jj has a rich set of functions and pattern matching which I haven't (and may never) take the time to learn. But the majority of day to day interactions... just me and the command line. I would never say such a think using git by itself.
JJ works on top of git, so you can still use magit for hunk selection. I tried this approach and once I grokked JJ, I stopped needing to fuss over hunks and parts of hunks. Magit is good because git is clunky. As someone who said exactly the same thing as you for a year, I encourage you to try JJ with jj-mode.el.
As a heavy magit user prior to jj, I can attest that I've just felt much less need for it in the wake of jj. Things like JJ's split being interactive and a lot of the commands having really neat short forms has meant that for me, as attached as I was, I still found myself benefiting so much that I switched.
Fun name: seems like a reference to “Magit” both syntactically (being a portmanteau of “Magit” and “jujutsu”) and semantically (majutsu meaning “magic” in Japanese).
You can use git frontends for Jujutsu just fine, I use lazygit a few times a month out of habit, it all works well. I use jjui for the rest of the operations.
If you are using vim in the terminal pressing alt send an escape sequence when followed by another key press. So to go out of insert mode I usually press alt+ one of h/j/k/l
I can just give you my view. I've been a TWM user for >10 years than switched to niri via some of the sway/hype land scrolling plugins.
My problem with TWMs was always that depending on monitor size you can open 3-4 windows in a set layout (be it the tradional spirals, or H splits...) before you have to do "manual" window management (i.e. move windows into tabbed layouts, move them to new workspaces,...). So for me that generated a friction, where sometimes I just wanted e.g. to quickly open a terminal do some things but keep the rest the same, but not knowing if the terminal becomes permanent. I other words in TWMs I found myself having to know what exactly I want the window for all the time.
SWMs get rid of that friction, I just open a new window and it gets pushed to the right, while keeping windows at the perfect size and if not I can easily switch between the 3 sizes I want (never found I needed more than fullscreen half screen, third of the screen). So I simply don't have to think what I want the e.g. terminal for (something long term or just quick try) before I use it. While it sometimes makes finding the right window a little more messy (the overview really helps though), I find I end up more organised, because I keep related windows in the same workspace, while on TWMs I ended up with 3 or 4 workspaces just for temporary terminals (which made finding the right one often very messy as well).
> For Vim users, I also suggest enabling Vim mode in Zsh. It makes editing commands much faster.
I am also an avid Vim user but I disagree. The default readline is perfectly fine for single line commands (you do have to know your way around some basic commands though C-a/u/k/l/w...). To edit long commands in $EDITOR you can always do C-x C-e in bash/zsh (M-v in Fish). As a matter of fact everytime I pair program with my colleague I always think he is editing those short commands slower than I would have because he has to change modes all the time.
Changing modes is a single key stroke away. That's hardly a reason to be slow.
Readline settings depend on what you're already used to. If you're comfortable with vi key bindings, then being in normal mode, navigating with `w`/`b`, deleting a word with `dw`, deleting up to a quote with `dt"`, etc., are all done with muscle memory, and should be much faster than learning the equivalent Emacs bindings, pressing unintuitive key chords, or opening the command in an editor. I don't like opening an editor since it's an interruption, and it hides the output of the previous command.
I wish I could have the full power of Vim in my shells. For example, I miss the delete between characters binding. `di"` or `di'` are great for modifying argument values.
I like to re-add the readline binds after enabling vim mode, and then I only leave insert mode occasionally. C-x C-e really is great, though, I think I do tend to reach for that if I need to do a big edit of a one-liner.
There is a lot of talk about AI replacing humans, but how is this sustainable?
reply