rvdginste

JetBrains Rider is a perfectly fine IDE that works on Linux. Way better and way more powerful than VSCode and Monodevelop. And in my opinion also better than Visual Studio (though I didn't try 2019 and 2022, Rider does everything I need).

Since that book is over 20 years old, is it still relevant and useful?

As a developer, I find it a bit embarassing that I started using Emacs in 2000, that at some point I even read my email with it, and that I never took the time to really learn emacs-lisp. Still, some day I will. This book might help me. :)

Dell Precisions have both a trackpad and a trackpoint and feature 2 times 3 buttons (one row on the top and one row on the bottom of the trackpad).

I think that old Thinkpads always had a middle button because it was used combined with the trackpoint to scroll.

That may be true about the ~500MB RAM, I did not measure it or anything and I agree: if you want to go for <100MB RAM you'll need to look for something else. I actually used i3wm (with separate programs) before on my older computers, but I was pleasantly surprised by KDE performance and decided to stick with it.

> The usability of KDE aside, it's not exactly the most lightweight interface.

I wonder if that is still true. I switched from MATE to KDE several months ago and from what I read, KDE invested a lot in optimization of their code (both cpu performance and memory use) in the last couple of years. I switched to KDE on all of my machines. The oldest one it is running on is a Thinkpad X200t with a Core 2 Duo (SL9400) and 4GB RAM (with SSD), and it is running fine when using it with chrome, okular, krita, ... I thought they were kinda forced to focus on optimization because of the development of plasma mobile.

Obviously, it'll still be beaten by LXDE, but compared to Gnome it should perform a lot better nowadays than some years ago.

I don't really care about the noise to know what the computer is doing. I prefer a silent computer, because I really need silence to be able to focus my mind on something. (And it might seem inconsistent, but I do love clicky mechanical keyboards and their sound does not bother me.)

But regarding 'feedback' from the computer, there are other options: laptops typically have an indicator light for hard disk activity, to indicate whether the battery is charging or whether the laptop is receiving power, or a slowly pulsating light to indicate that the laptop is in suspend-to-ram mode. Also I remember that long time ago, when every laptop came with a replaceable battery, that the batteries themselves often had indicator lights so that you could easily see whether a battery needed to be charged (1). Some laptops even had some indicator lights twice: one on the inside of the screen that is visible when you're working on the laptop and one on the outer shell of the screen that is visible when the laptop is closed (2).

I love that kind of thing, because to me those indicators are often useful. Maybe not everyone is into that or cares, but I'm also the kind of people that likes to have a cpu load monitor somewhere on screen to know what is going on on the computer.

(1) The battery indicators I remember from the iBook G4 and old Dell laptops. There was a button that you could press to indicate the remaining charge with some leds. While charging the leds would be blinking and indicating the charge at that moment.

(2) The indicator lights on both the inside of the screen and the outside, I noticed on the Thinkpad X200. I also discovered that the dock for the X200 actually comes with an extra charging port for a battery. So while you're working on the dock, you could externally attach a 2nd battery to the dock to charge it. I really appreciate the attention that went into these kinds of designs.

I discovered Doom Emacs a couple of months ago and it made me use emacs more often again. Doom Emacs is well made and makes configuration of emacs a lot faster and easier. I've noticed that a lot of file types have support from an LSP server and setting that up is also easy.

Long time ago, I used to read email using wanderlust on emacs. I remember I really liked it, it was very powerfull in handling email and it had really good imap (and offline) support. The only drawback was related to handling html email. Back then that was not that much of a problem because I used it for a lot of mailinglists which were typically text only, and the remaining email was often sent in both a text and a html version.

Anyone using email in emacs and has a good solution to deal with html email? Both receiving and sending? I kinda remember reading about people writing email in markdown and have it converted to html when sending it out.

The X200 officially only supports 2x2GB, but seems to work fine with 2x4GB, as long as it's the correct type of ram (single-sided if I remember correctly). So I need to find the right type of ram and it's something I plan to upgrade, but didn't get to it yet.

A couple of months ago, I bought a used Thinkpad X200t in excellent condition. I knew about the popularity of the older Thinkpads and libreboot, and I was interested in a tablet pc because I wanted to use it to read and make notes, so when I came across that X200t (in excellent condition and good price) it was an easy decision to buy it.

Its specs are low (256GB SSD, Core 2 duo, 4GB RAM, 1280x1024 screen), but I find it very usable for browsing, reading and annotating pdfs. It runs Debian stable with KDE Plasma (the pen works well with krita, okular, xournal). The battery is old but is still holding a charge for several hours. I thought the screen would be annoyingly small, but I noticed that it is actually just fine for most web pages. I like the old 1280x1024 a lot more than the nowadays popular 1366x768. I really like it, it's also small and easy to travel with.

What you can do with it, is however limited by the Core 2 Duo chip, and the amount of ram. It's not gonna run a heavy IDE, and as a developer that's a bit of a pity, but was also completely expected.

I just checked how much people ask for old Thinkpads X200 and X200t and they really ask a lot for them, especially for ones that are already librebooted. That's amazing if you realize that those came out in 2008.

> It’s code that’s much harder to get visibility into, harder to track over time, harder to reason about in the context of a larger codebase, and harder to measure and understand the performance implications of.

I think this really depends on the developers and their tools. I've seen at least one system that is built on the database using hundreds of stored procedures and triggers, and that was still maintainable. The reason that it was maintainable was that there was a code and naming style that was used consistently throughout the project, that each trigger and stored procedure was documented, and that the developers had a good tool to maintain everything.

Maybe in practice it's the exception, but good coding style can help just as it would help with code in a service.

> And for most cases, all this downside with little/no upside.

Well... obviously there is a very important upside and that is performance: you are executing code very close to the data and this can give you a big performance gain. If you execute business code on an application server, you have to first fetch the data from the database, then manipulate the data and then send the data back so that the database can store it. If you execute business code inside the database server, you don't need the round-trip (which goes typically over a network connection) and this can result in much better performance.

Personally I never built a system that relies on triggers and stored procedures. I'm used to working with an ORM and implementing business logic in the service. I do rely on database features (different types of constraints) to protect data consistency as much as possible. Still, at some point I would love to build a system that has its business logic in the database just to get the experience and to really know how that works. I also wonder how performant the language integrations (which might be more expressive than the default) are that database systems sometimes offer.

> And if we had a new spec for irc, would we need Slack/Discord/MS Teams/etc? They could then all talk to each other. We shouldn't be trying to reinvent the wheel, we should be using these older services in our platforms.

The reason we have all those separate systems is not that there are no alternatives: irc could have evolved with a new spec, but there is also XMPP (Jabber)... The reason is that all those systems like Slack/Discord/MS Teams do not interoperate with each other is that they are developed by companies that need to make money, and they want to force and keep users on their systems.

I think email is the only communication protocol that is still very popular and works across providers. I don't think it will disappear anytime soon. At this point, email providers cannot lock their users into their own system: no one can imagine that you'd be only able to email other gmail accounts from a gmail account or other microsoft accounts from a microsoft account.

I believe that this kind of issue is possible with most language specific package repositories. That combined with the fact that a lot of developers upgrade dependencies without giving it a lot of thought (newer is better) probably means that this will happen again.

Still, when I update packages on my Debian install, I am not worried at all about this kind of issue. That makes me wonder if and why Debian packages would be safer. I think that the following are reasons that I trust official Debian packages:

* it is a curated list of software: confidence in the quality of the software

* maintainers follow up on security issues: confidence in security issues being fixed in a timely manner

* packages are signed: confidence that package is created by a trusted maintainer

* trustworthy maintainers: not everyone can upload new versions of packages, it takes time to become a new maintainer

So it makes me wonder whether a similar concept of curated repositories for language specific package repositories would be useful or needed... am I the only one to think about this?

You can use database schema compare tools for this. You create a clean empty database using the new DDL and use the tool to compare that schema with the schema for the version in test or prod. The tool will then show the differences and can create a sql script to update the database in test or prod.

I've used this a lot with SQL Server and used the Redgate tools for that and that worked very well. For PostgreSQL, it seems there's a free tool from devart: dbForge Schema Compare [0]. I've never used it and have no idea how well it works...

[0]: https://www.devart.com/dbforge/postgresql/schemacompare/down...

I think only very few people can be really proficient in more than 3-5 programming languages (at the same point in time). And with really proficient, I mean both a good understanding of the programming language semantically, being aware and keeping track of newer features in the language and having good knowledge of the standard library of the language (and potentially other common libraries). If you are not proficient in a programming language, you cannot work efficiently with it.

Personally as a backend .net developer, I consider myself proficient in C#, I know some basic SQL, and some basic TypeScript and JavaScript. Earlier on I have touched Basic, Pascal, Haskell, Prolog, Scheme, Ruby, Bash, Java and C. I have worked with several different programming paradigms and I have no doubt that this made me a better developer. Still, I don't consider myself a polyglot programmer. Even though I was proficient in Java and C earlier on, nowadays I would have to search basic things all the time if I'd work with those languages again. So that would not be efficient at all.

In my opinion, the concept of a polyglot programmer is only useful if it means a certain level of proficiency in multiple programming languages and that requires a lot more than understanding the syntax of those languages.

I didn't know about Dillo's history, thanks for the info!

And what about Dillo?

https://www.dillo.org/

A really liked Galeon, a Gecko-based browser. http://galeon.sourceforge.net/

> The two footpads give operators full control over the trajectory of the robot, and allow the robot to make turns with a centripetal acceleration that exceeds that of most insects.

> In this work, the major innovation was adding these footpads that allow it to make very, very fast turns.

> Electrostatic footpads allow the robot to make turns with a centripetal acceleration that matches that of a cheetah.

I've used distcc in that way long time ago. I had an powerpc iBook (G4) and a x86 desktop (Pentium4). The desktop helped compile software on the iBook using distcc and a cross-compiler. It did work pretty well. I also used ccache in addition to that to cache build output. That was probably around 2005 when most (all?) cpus were still single-core.

Since I've been testing both on linux on an older laptop (Core i5-3317U, 10GB RAM, Sata SSD): Emacs + lsp (Omnisharp) is not noticably faster than JetBrains Rider. Both are slow and at times lagging on this hardware. In the end I just use Rider on that laptop since if it's lagging either way, Rider is still a more complete C# ide for me. My laptop from work is a Dell Precision (Core i7-7820HQ, 32GB RAM, NVMe SSD) and is more powerful: it's a pleasure to use Rider on that machine.

I studied engineering and got a degree in computer science. So I like to call myself a software engineer. At my job I do a lot of things: analysis, design, development, project management.

This! I did the same thing: read about the model for the commits, the blobs and the hashes. When you know that (just the basic data model, which is really simple), it's a lot easier to understand and memorise the different git commands.

In fact I often work with git using the tools that come with it: git on the commandline, gitk for the visualization of the history and 'git gui' for committing work. They might look outdated, but they work really well and are really fast.

There are a lot of modern graphical tools to work with git repos, but some of them introduce their own vocabulary in an attempt to make using git 'simpler', but this just ends up making everything more confusing.

My impression is that a lot of people want powerful tools, but do not want to invest the time to learn how to handle them. The Pro Git book is available to read for free online and after reading the first 3 chapters, you should know about the most important things for day-to-day use. Some people would do anything to avoid reading the documentation: they'd rather spend a whole day checking different guis that make things look easy and familiar instead of spending that time reading the documentation.

Personally, with git, I would work on one "work" branch with the 5 orthogonal commits in succession. For each commit that is finished, I would create a new branch and cherry-pick that specific commit on it. I would create a PR for those branches.

Once the PR (possibly with some changes still) is approved and merged, I would rebase my "work" branch on top of the updated master. Since it was an orthogonal commit, you'll typically see that the merged work just disappears from your branch during the rebase. If it really was orthogonal work, you'll not have any conflicts.

This is an approach I've used whenever I need to work on something that depends on other work that was not merged yet. You have a work branch that includes all the work, since you depend on it, but you want to offer smaller pieces as PR to make the review process more efficient.