unixsheikh

I run several Arch boxes, a couple I believe is on 15+ years. One such installation has even been mirrored from one disk to multiple other disks and put into other machines, just because it was already set up as needed. Only once did a package I ran require manual intervention during upgrade, but as always, that was clearly described on the Arch website.

This also goes for Debian, FreeBSD and OpenBSD.

So many companies are doing what's "trendy and shiny", and it can almost look like it is becoming a de-facto standard, but they will eventually realize the mistake.

> We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option. (Doug McIlroy).

Sigh!

We have only negative experiences with frameworks and big layers. They solve problems quickly in the beginning, but they always end up causing problems. Years later, debugging strange errors, security issues, etc. The more layers you add the less useful and good the application becomes.

we use the standard library and a couple of slim and well written external libraries, such as sqlx and go-sql-driver.

I have written my own HTML form validator and custom error handler - once you get that done, web development in Go becomes MUCH easier.

We don't use ANY JavaScript on the front-end unless it is a minor custom enhancement to the UI (it must be able to run without). Everything is pure HTML and CSS.

However, I personally do find the HTML templating tedious, but I have always found templating stupid and annoying, this is not specific to Go. I prefer to write HTML inline in PHP (when I do PHP) i.e. the old fashion way. I hate templating in any language!

It's easy to make mistakes in Go HTML templates, make sure you test that part of your code well!

Writing big web applications from scratch is great though, and it's really fast in Go, faster than PHP, as long as you do it right! Documentation, documentation, documentation. Anyone who inherits your code, whether you're alone or on a team, needs to know and understand your thinking and rationale.

The main reason why projects fail when they build tailor made software is because of laziness regarding documentation.

The correct way is to regard missing documentation as a bug! Write the documentation WHEN you write the code. If you change the code, change the documentation right away, when you can still remember what you're doing and why - this is the most important part and why so many code bases are horrible to inherit. Missing or poor documentation.

Never use "clever" code, make code that is easy to read and understand. Don't worry too much about design patterns and philosophy, they mostly belong in the books and in theoretical discussions!

Web development in Go is not for everyone, it requires experience and thoroughness. The build fast, deploy and forget strategy - that most people use these days - doesn't belong in Go.

Go will reward you in the end with really good performance and very easy future maintenance. Nothing suddenly breaks because a third of the standard library has suddenly been changed in the next version upgrade, such as with PHP.

EDIT: Typo.

  Location: Europe/Copenhagen
  Remote: Yes
  Willing to relocate: No
  Experience: Senior 30+ years
  Technologies:
    * PHP, Go, Python, C, JavaScript, HTML, CSS, XML, JSON,
      SQL, Shell scripting.
    * Debian, Arch, Void, Alpine, OpenBSD, FreeBSD.
    * Apache, NGINX, MySQL/MariaDB, Galera, Sphinx,
      PostgreSQL, MongoDB, Redis, SQLite, OpenSSH, Git,
      Mercurial, DHCP, DNSMasq, Bind, Unbound, NTP, PF,
      iptables, ZFS, Btrfs, GlusterFS, NFS, Samba,
      OpenSMTPD, Postfix, SpamAssassin, Dovecot, GnuPG,
      rsync, ProFTPD, PureFTPd.
  Websites:
    * https://unixsheikh.com
    * https://openbsdrouterguide.net
    * https://phpthewrongway.com
  Resume/CV: Request via email
  Email: [job] at [unixsheikh dot com]

> Why on earth would we want to use 5 different encryption protocols in the browser? That's just pointlessly adding attack surface. What's wrong with HTTPS that means it's a bad fit for encrypting a DNS query? A DNS query is essentially at its core an HTTP request to a remote server, and HTTPS is already very good at encrypting HTTP requests. There's no need to reinvent the wheel here.

This is where you're wrong. A DNS request is far from the same as a HTTP request!

You don't seem to understand how the technology really works in the underlying protocol.

HTTPS is designed to encrypt HTTP traffic, it was never designed to be stuffed by other kinds of traffic. When you stuff DNS into HTTPS you not only get a destination IP in clear text, something you cannot get if you use DoT e.g.

Furthermore, DoH also completely ruins analysis and monitoring of DNS traffic for security purposes. Already DoH has been used in a worm to mask connections to its command-and-control server.

If you want to solve the obvious problems with DNS, you don't keep doing the same mistake over and over again by patching with the same half-baked solution.

DoH does not solve ANY of the issues it is set out to do! I have worked for a long time in the ISP industry, users gets tracked by source IP and destination IP mainly, and figuring out what particular website they have visited, even when the hosting provider has multiple websites running on the same IP, is so easy just by looking at a hash of the payload that it is ridiculous.

DoH is "fake privacy". Period.

Furthermore, the destination IP address is ALWAYS in clear text when you use HTTPS. Which demonstrates exactly why this is so wrong.

DoH - is fake privacy, it's nothing more than extra sugar on Cloudflares spying cake - and more funding for Mozilla.

Wake up.

DoH is DNS done completely wrong. It's the worst patch solution to a problem that should have been solved correctly long ago!

The amount of sheer stupidity that goes into the "modern web" is just mind bugling.

DoH does absolutely nothing that helps privacy since the destination IP address is always clear and DoH only obscures that which it never should have touched with in the first place.

I have just about had it with the IT industry and the modern web!