Major Hayden

I feel like it's worth mentioning icanhazip.com [0] as well, since it's now run by Cloudflare [1]. Until recently switching to a custom CF worker, that's been by go-to for ages. [0]: https://www.icanhazip.com/ [1]: https://major.io/p/a-new-future-for-icanhazip/

>there is, the XPS has the best Linux support on a high end laptop, maybe ever. That's hyperbole if I've ever seen it. You can look at how many problems plagued Fedora on the XPS13 as recently as a year ago: https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/ The tl;dr version is that the guy spent so long trying to get it working properly that he ditched the laptop for a Thinkpad. And FWIW, Fedora usually has better support for recent hardware than other distros due to the up-to-date kernel. From what I gather, Thinkpads are the crown jewel of Linux-supported laptops. This is more of a dogfooding thing than anything else: kernel developers, Redhat employees, and other Linux users tend to use Thinkpads, which means they then spend more time getting support for Thinkpads into the kernel.

For those interested in following along on the process: https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/ With an updated BIOS and a bunch of patches, it looks like it's getting close...

I am working on a similar project. I have something working for my own needs and a few other families already but a long road to go before making something GA. You can waitlist at https://havenphone.com if you are interested. There were three major things I wanted to do differently from Tin Can: - I wanted to use off the shelf VOIP hardware so if the company ever went out of business I (and any of my users) had an escape valve or could just sell the hardware. - I wanted to have a code base I could open source. (not open source, yet!) - I wanted flexibility to offer ATAs (devices that let you connect any ol' "analog" phone)- some of my parent friends wanted cordless "DACT" phones, interestingly. It has been quite an adventure entering the world of VOIP. The SIP protocol has so many esoteric options (understandably given its history!) it could make TLS look simple. My most recent learning is this crazy protocol called TR-069 that ISPs use to configure endpoint hardware like home routers, cable modems, and VOIP phones. https://en.wikipedia.org/wiki/TR-069 Also, interestingly every cheap (sub-$50) phone and ATA I have tried has a built-in OpenVPN clients. Oh, and one more interesting thing Grandstream ATAs are able to be taken over by the Grandstream cloud service by just providing the ATA serial number and mac address on the back of the device- I did not love that workflow when considering long-term security. (: If you have $50 and some time to kill you can do it all…

Changing SSH port is far more efficacious at reducing nonsense than the Twitter poll in the article suggests: > "I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile."[0] > "In the time that I gathered 7,025 connection attempts to my SSH daemon on port 22 I received 3 on port 24."[1] Also, great top comment by 16s[2] in this HN thread, "Why putting SSH on another port than 22 is bad idea".[3] [0] https://major.io/2013/05/14/changing-your-ssh-servers-port-from-the-de… [1] https://danielmiessler.com/blog/security-and-obscurity-does-changing-y… [2] https://news.ycombinator.com/item?id=6615994 [3] https://news.ycombinator.com/item?id=6615734

It's absolutely possible to run an email server in 2016 and I encourage anyone capable to do so! Email is one of the bastions of the decentralised Internet and we should hang on to it. Every day more and more people are moving to Gmail/Hotmail/Outlook and while I do understand the reasons, it also puts more and more power into the hands of these providers and the little guy (us) gets more screwed (like marked as junk by default by them :< ) Having said that, here's my check list for successfully delivering email: - make sure your IP (IPv6) is clean and not listed in any RBL, use e.g. http://multirbl.valli.org/ to check - make sure you have a correct reverse dns (ptr) entry for said IP and that ptr/hostname's A record is also valid - make sure your MTA does not append to the message headers your client's IP (ie x-originating-ip), messages can be blocked based only on "dodgy" x-originating-ip (see eg https://major.io/2013/04/14/remove-sensitive-information-from-email-he… ) - set up SSL properly in your MTA, there are so many providers giving away free certs nowadays - SPF, DKIM, DMARC - set them up, properly, this site can come in handy for checking yourself https://www.mail-tester.com/ - do not share the IP of your email server with a web server running any sort of scripting engine - if it gets exploited in any way usually sending spam is what the abusers will do - last but not least - and while I loved qmail and vpopmail - use Postfix or Exim,…

Still waiting for Dell to fully support Ubuntu in their 2015 XPS 13 model. I made the switch from a Thinkpad after Lenovo burned me too many times. While the keyboard isn't quite as excellent it's still top notch and it's one of the best laptops I've ever owned. That being said getting everything working in Ubuntu has been a bit of a fiasco [1]. Luckily after some firmware upgrades and the new kernel in 15.04, a lot of issues have been fixed, but the laptop still does strange things waking up from sleep. The worst issue though is that audio still seems to not work in a dual boot configuration. The laptop can't produce sound from the speakers or headphone jack in both Windows and Ubuntu when booting between the two OS's. It seems the hardware gets put in a strange state by either OS and it takes two full reboots after switching from Windows<->Ubuntu to get the audio device to be recognized. Also HDPI support in Ubuntu is still a little lacking so the beautiful higher-than-retina display sometimes makes things absurdly small. I've seen a lot of progress on this front though. I really love this device but I'd be lying if I said I didn't miss the excellent out of the box hardware support for Thinkpads in Ubuntu. [1] - https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/

emphasis on "apparently simple" icanhazip.com looks even simpler on the face of it but there's always shenanigans behind the curtain: https://major.io/p/a-new-future-for-icanhazip/

I only need/want the Beefy Miracle https://major.io/p/bring-back-fedora-beefy-miracle-boot-splash/ The mustard indicates progress :)

icanhazip.com had similar issues. Cloudflare took over the project https://major.io/2021/06/06/a-new-future-for-icanhazip/ Fyi, dns can be used to obtain public ip from large companies, without the overhead of tcp and http dig +short txt ch whoami.cloudflare @1.0.0.1 dig +short txt o-o.myaddr.l.google.com @ns1.google.com dig +short myip.opendns.com @resolver1.opendns.com

Unfortunately, this seems to be the pattern that people offering the same service as you experience. Take a look at https://major.io/2021/06/06/a-new-future-for-icanhazip/, if you haven't seen it already.

https://major.io/2021/06/06/a-new-future-for-icanhazip/ Pretty interesting story about a tiny IP checking tool and how it sort of got out of hand sadly due to abuse. The solution? Major sold the site to Cloudflare for $1. But really kind of a shame overall.

This reminds of the journey of the creator of icanhazip [1]. He had created it and maintained it through several milestones _on his own_ until he could no longer carry on. Luckily it ended on a good note as Cloudflare decided to "buy" it. [1]: https://major.io/2021/06/06/a-new-future-for-icanhazip/

Yep, same here -- no AAAA record for v4.icanhazip and no A record for v6.icanhazip . The documented interfaces were ipv4/ipv6 though https://major.io/icanhazip-com-faq/ and {v4,v6}.icanhazptr.com have both A and AAAA.

There are other services he runs as well: https://major.io/icanhazip-com-faq/

Could it be two issues going on at the same time? UceProtect blacklists AS numbers (netblocks belonging to an org), CIDR blocks and individual IP's. They don't block domain names. Other RSL's do block domain names. If your website domain is hosted on DO but your email does not originate from their netblocks, then the blacklisting is occurring elsewhere. Did you get the email headers from a customer that is reporting this? You can analyze the headers to see who is flagging you. Are your emails generated on DO and you relay through another service (SES), but you are not obfuscating the DO header that your MTA injects? [1] [1] - https://major.io/2013/04/14/remove-sensitive-information-from-email-he…

Here are my notes to fix the overly sensitive trackpad on my Lenovo Carbon X1 (they'll probably only make sense after reading the links) from https://major.io/2012/12/28/handy-settings-for-the-touchpadclickpad-in… synclient "PalmDetect=1" synclient "PalmMinWidth=5" synclient "PalmMinZ=40" Or soft link to a file from /usr/share/X11/xorg.conf.d/10-synaptics.conf. To get middle-button scroll with trackpoint: From https://askubuntu.com/questions/578600/how-do-i-get-the-trackpoint-but… edited /usr/share/X11/xorg.conf.d\11-evdev-trackpoint.conf upated the line: MatchProduct "TrackPoint|DualPoint Stick" to MatchProduct "TrackPoint|DualPoint Stick|PS/2 Synaptics TouchPad" Sorry if they don't make sense, but the links are where I got my information, so they should help. The changes made a world of difference.

Note that finally, with 16.04, you can block the (ridiculous) auto start behavior of daemons installed via apt using systemd features: https://major.io/2016/05/05/preventing-ubuntu-16-04-starting-daemons-p… It's always angered me that packages start running before I have a chance to configure them... With some, like MySQL, it means if I want to change certain settings, I also have to clean up some other files before restarting the service or the package will not start. On CentOS/RHEL, this is never an issue.

Yup: https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/… iFixit gave the laptop quite a good score too: https://www.ifixit.com/Teardown/Dell+XPS+13+Teardown/36157

Why would anyone ever virtualize or containerize ping? In the real world, we use containers for largely the same things that we use virtualization -- the web server, the database server, the VPN host, and so on. The overhead is negligible to begin with- https://major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/ -but with de-duplication of a solution like vmware, approaches 0. Containerization seems like a massive win when you're trying to fit a bunch of stuff in a single Digital Ocean VM, etc. When you're running many machines in a data center, though, it becomes dramatically less valuable.

> Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled > but I do know people doing on-prem kubernetes loads that have had to... What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain. It's extremely practical: you can create very precise logic chains with systemd (if this and that, then...) > My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services. Maybe I can help you with that - I used to run a non systemd DHCP when I needed a rapid DHCP to reduce the TTFB for a specific configuration (read https://news.ycombinator.com/item?id=2755461 if you are not familiar with rapid DHCP) It did not require much effort, just "inserting" my own service in the dependency chain. Create a /etc/systemd/system/[email protected] with : (put the…

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure. I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time. The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems. [1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/