A software developer and Linux nerd, living in Germany. I’m usually a chill dude but my online persona doesn’t always reflect my true personality. Take what I say with a grain of salt, I usually try to be nice and give good advice, though.

I’m into Free Software, selfhosting, microcontrollers and electronics, freedom, privacy and the usual stuff. And a few select other random things as well.

  • 4 Posts
  • 1.1K Comments
Joined 5 years ago
cake
Cake day: August 21st, 2021

help-circle
  • Thanks. Yeah, I’ve never looked into code quality of many tools I use on a regular basis. So far, rsync has served me well. I’ve been using it at work, at home, for larger amounts of data… Without major hiccups. And we kinda need something like this. It’s a bit of a shame how many essential software projects at the foundation of many things struggle being maintained. My distro has openrsync in the repository. Seems just that that software project is also a one-man-show.

    (Btw, Firefox Translate for the win, I don’t really need a big LLM to translate stuff.)



  • Yeah, there’s several silly metrics for management to judge programmers. It’s mostly because management needs some oversimplification, because they have no clue what programmers do all day.

    Most common one is “lines of code” (LoC) written in a day. Of course you’re making the company more money if you write more code. That’s your job after all, right? Right??? …Of course that punishes people who write efficient code. Who think first and then come up with a smaller, better to maintain version.

    It’s similar with speed. But just tell the programmers what to do! It’s easy to get 80% the way with 20% the effort. That’s how it always works. Your programmers can do that, just write it into the project specification.

    But to be honest, the major time factor isn’t writing code. It’s all the project management. Misunderstandings, specifications which change over time. Additional requirements after the fact. That’s the major time waster in software projects. Typing down the code takes time as well, but it’s usually not where projects go sideways.

    And use some good frameworks. Leverage someone’s wisdom. Also a major time waster if you wrote code for 2 weeks and find out you’re using the wrong framework and need to start over.

    (Oh boy, and please don’t take the advice to send in half-baked PRs. Yeah, that might look like you’re done sooner. But that’s gonna waste somebody else’s time. And it’ll inevitably return to you and then you’re gonna put in some more time anyway. And you’re gonna waste some more time on arguing about details, changing around stuff… Just get it done on the first try, without any additional back and forth. And returning to each problem three more times. That’s the way to move quick. The outlined way is again how to make management happy. They LOVE to see a PR early and then a lot of activity in the comments. Looks like it’s complicated and people are very busy. But they’re most likely only adding noise and unnecessary back and forth. It’s just… if you just get done with it, quick and without any fuss, nobody will notice.)




  • Difficult to tell. I don’t see anything too obvious or offensive in the commits. They also write like a human in the associated pull requests. Not sure what Claude’s role is here. Also the added code comments are kinda on point, use contractions… Not really what I’d expect from an AI.

    Is there more info on this? A blog post or some statement by the project? At first glance this doesn’t look to me like other vibe-coded projects.




  • Sorry, I’m a bit low on time right now, so I can’t give it the attention it deserves. But from a quick glance… I like it. The user interface looks appealing and easy to understand. I didn’t check if adding peers works on a tech level, but overall I think the design is right. It’s probably straightforward enough for the average user to understand. I also like how there’s links to documentation, explanations what it does and the ideas behind it. I think that’s roughly what makes good software. Be genuine and honest to your userbase. Tell them what they can expect. Give them documentation to read more if they like. Otherwise make it as simple and straightforward as you can.

    I mean I just thought I’d drop some ideas. Of course you do you. Seems you have a bigger vision. And we/I understand it’s quite involved. You’re doing a lot. All of that for some broader idea, and there’s a lot of detail work to be done. I like talking about things like that and following what other people (who have some sort of vision) do. I see how it’s a lot of work. And several things you’re doing simultaneously.


  • Uh yeah. That is more information… Sorry, I’m not that familiar with Snaps. It looks to my untrained eye a bit like the report on the Snap itself, maybe it advertises to support running in strict confinement. Which it could… but doesn’t do. (Alike the other channels, which you could install, but didn’t… It’s kind of buried with that kind of information.)

    It’s confusing at least. And the user definitely wouldn’t expect it from that wording. So I’d view it as a separate bug as well. And dropping confinement without notice would be the third thing, I’d consider a bug.)