aduitsis

It's sad that, albeit being a major contributor of open source code during the 2000's, Sun Microsystems was getting a lot of hatred from many quarters the open source community. Not sure how much that contributed to Sun eventually getting acquired, but I think when it happened the world was left poorer.

Previous job was at a University, 15+ years using FreeBSD for almost all services. We've had Jails, ZFS, etc for a good part of those 15+ years, which was a huge asset. Not that it was completely trouble free, but assuming that with anything else it would have been easier, is simply a delusion.

Why we went with FreeBSD in the early 2000s? If memory serves, the ports tree and the package management were completely blowing away anything else at that point. Nowadays it is considered given for any platform, but it was a great advantage to be able to compile packages reliably with your own options back in the day!

The fact is, FreeBSD is (and was for a very long time) a trustworthy and very stable platform to run services in. FreeBSD has a very deep philosophy of trying to minimize surprises, which means that most of the time you can focus on your real tasks instead of fighting what has changed in the last version. And Jails are still a major plus, at least from a certain point of view, since they are very easy to manage, copy, install, administer, etc.

Even today where Linux has catch up in all aspects, if you have a large set of services on FreeBSD, you'll invariably have to pay a huge upfront cost to switch everything to Linux and re-learn stuff all over again. It's not a question of freedom or open-source (FreeBSD and Linux are totally free and open-source, in their own way each), it's a question of overcoming the mountain to get across to the other green side. I'm sure it's exactly the same for Linux shops that would like to try out FreeBSD. Why should they pay the cost, if they cannot really get any significant advantage or profit out of it? So one basically sticks to what's known and trustworthy from before, since the investment has already been made and most people don't like doing the same stuff all over again.

You can find instructions how to create Ubuntu Jails inside FreeBSD.

There was an experimental Docker port for FreeBSD some years ago and it was actually working. I think it is mentioned here https://wiki.freebsd.org/Docker. However, it wasn't extremely useful as it didn't reach maturity, and because FreeBSD already had Jails. Which we were already using in production for the past ~15 years.

Unless your job is to teach Latin :). Quite a few schools around the world are teaching Latin or even Ancient Greek.

Are Latin and Ancient Greek dead? Ostensibly yes. But not useless. Besides teaching, there is a tremendous amount of books and texts written in Latin and Ancient Greek. To study them, one would invariably need to learn the language.

This. If you're paying good, practically everyone will come to interview for you, so your supply is inexhaustible. So you can afford false negatives.

This is supreme nitpicking, but the author being quoted about the term "metaverse" is Neal Stephenson, not "Neil Stephensen".

I love https://manytricks.com/moom/. Being available in the app store is a major plus from my point of view. And it has the usual tricks like keyboard shortcuts, etc.

I had installed Windows 3.0 on the 20Mb HDD of my Hyundai 16v (8088, 10MHz!) via 20 360Kbyte floppies :)

(edit, yes Windows 3.0 could use CGA 640x200 with 1 bit colour)

Your point is very well taken, but using Turbo Pascal to create an application with a TUI was surprisingly easy back in the day. You could just add some small boilerplate and you basically had something with a TUI running. So the entry barrier was extremely low, which had the effect of giving you a quick reward to motivate you to understand and build more advanced features.

Very nice! There is a certain appeal to having simple, versatile and robust systems such as a terminal emulator to build upon instead of complex APIs that require many many hours just to understand their asynchronous operation and complexities. Combined with Unicode, there seems to be a small renaissance in the area of what can be done in a terminal, which is both nostalgic and refreshing!

And, terminal emulators such as iTerm can nowadays display images. And vector or bitmapped graphics were actually a thing once. E.g. I believe xterm can still understand and display https://en.wikipedia.org/wiki/ReGIS graphics. Surely there must be better and simpler alternatives that I may be missing. Having an empty canvas and drawing to it without too much hassle is reminiscent of the era when this was done with a few lines of BASIC.

Thank you, this is great!

Slightly tangential, it's a huge pity that twitter suspended the account of the medieval death bot.

https://www.smithjournal.com.au/blogs/history/3011-this-medi...

My favourite small detail on the Mac, is how the clipboard interacts with the filesystem. You can select some text, drag it into the Desktop and it will become a .Clipping. Now, if you drag and drop that clipping into a text field (e.g. textedit), it will be as if it was pasted.

The vastness of the cosmos we are living in, is simply unfathomable. I'm not even sure we have the ability to really appreciate the scale here. After a certain point it becomes just numbers.

Drew, thank you kindly (and Netflix) for your contributions to FreeBSD. They do not go unnoticed.

I, for one, learned quite a few things too out of your presentation, which is here: https://2019.eurobsdcon.org/slides/NUMA%20Optimizations%20in...

Slightly tangential, I am under the impression that the CHERI project has actually identified security bugs and reported them back to FreeBSD.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

My point exactly, thanks.

Yes, sorry, let me be more clear, I don't understand why Go should allocate a small 2k stack (you are correct, the Go stack size has fluctuated through the years, nowadays it's 2k) and if it grows go to the trouble of copying it to a larger structure? Instead of just allocating a big stack that will grow lazily anyway?

Obviously the folks that created Go aren't stupid, far from it, so there must be a real and valid reason. But can't easily imagine what it is.

Obviously I'm missing something here, because I was under the impression that, regardless of how big the stack is, the pages are going to be mapped (in the data structure pointed to by the CR3 register) when accessed and no earlier. Unless the allocation of the stack makes sure that it is mapped in its entirety upfront and stack access cannot incur minor page faults, which may not be so outlandish come to think of it. Can you please provide some clarification here? Thanks!

Point 100% taken on the matter of having the right to repair and procure spare parts. Here in the EU, I hear there is a major push to introduce some meaningful legislation to establish requirement, definitely right direction.

Comparing Samsung with Apple is interesting, because Samsung is very competitive and will come to your door (so to speak) to sell its products, which I respect very deeply. In my country, Samsung official service is top, better than Apple probably. I've been able to go to the service unannounced, ask for a battery replacement, go for a coffee and come get my device back after an hour. For computers, Dell also has a very respectable name, to the point where people will prefer Dell solely because of this. But below that level, chaos really, you have to go and order parts from ebay most of the times.

I think the inability to repair Apple products is right on par with the rest of the industry really. My Samsung mobile phone is just as difficult to repair as an iPhone.

Also, when it comes to computers (I use a Mac), there is also another factor. Apple devices may be difficult (and expensive) to repair, but they are certainly popular, which means one can find plenty of online resources or even spare parts, where applicable. And, one can actually find a local store that repairs Macs and take the computer there, if throwing money at the problem is an option.

Quite recently, I came across a case of a Lenovo laptop whose user had somehow activated bitlocker and forgot the password. Wasn't interested in the files, they just wanted to be able to use the computer again. I tried to find a way to reinstall the operating system and, I kid you not, there was literally no obvious way to boot normally from a usb device nor Lenovo provides any meaningful documentation or, Heaven forbid, the boot image to reinstall. It was actually kind of difficult to even determine the model of the device, as there have been several generations with the same name, each with a different processor and efi firmware. It was almost as if the model never existed.

We can laugh all we want for Apple's expensive and un-repairable devices, but the above nightmare cannot happen in the Apple ecosystem. You can even get the device to an apple store and they'll happily take your money and fix your device (if it's not severely damaged of course). This is not unique to Apple, e.g. Dell has excellent support and documentation. But this is a quality that is very important and yet it is often overlooked.

For popular packages this is not that common. For less popular packages, yes it can happen, because maintainers are almost completely volunteers. Some years ago I created a port, then at some point stopped being able to find the time to maintain it. Eventually someone offered to take over, and I happily obliged.

The ports Makefile framework is incredibly sophisticated, so one can find lots of examples and be quickly able create and test ports very easily, especially for packages written in C, C++, Go, Java, Perl, Python, Ruby, etc. Poudriere, which is the definitive bulk package builder used by FreeBSD pkg itself, is especially useful here. Ports that a have a billion vendored libraries are a pain. Ports are not allowed to download from the internet at build time, so all the vendor dependencies need to be known beforehand and be marshaled to download at the "fetch" phase accordingly. But eventually it all boils down to a very terse and declarative Makefile. What used to be a bigger pain, was the way to update ports in the ports tree, which used to require someone with access to the ports tree taking your new port and updating it. But recent news indicate that FreeBSD is moving to git and towards a model where port owners can each update their own directly, which will be huge. My personal opinion is that this will lower the ports maintenance bar significantly.

Also, for administrators, switching /etc/pkg/FreeBSD.conf from "quarterly" to "latest" pkg train of your version number (e.g. FreeBSD 12.x) will get you the latest versions of binary packages, as soon as their respective port is released into the ports tree. Quarterly is also pretty good, but you get only security updates and package versions tend to stay stable and change every quarter. I've administered systems switched to "latest" and seldom had any serious problems.

The Congress cancelling a deal to sell a 100 F-35s along with some of their parts being produced in Turkey hardly sounds like a weak sanction.

Google maps started from a position of being better and snappier than (then) Nokia maps. Today, it's almost impossible to use google maps while driving, the UI is simply unusable unless you can devote your 100% attention to it, and even then the results may vary. On the other hand, Here maps (former Nokia maps) has gotten better.

Oh, and my favourite google maps feature, announce the instruction to turn left or right while YOU STILL HAVEN'T PASSED the previous street intersection!

Incidentally, many services are now requiring a cellphone to send some one time password via SMS. Your phone number is something that you actually pay for and can transfer between carriers as you see fit. So in that sense, it's much more predictably controllable and, more importantly, under the legal jurisdiction of your own country.

Thank you, I meant non-optimal in the sense that using a (possibly free) email provider as a "backend" might mean that the emails are eventually accessible by third parties.

Having your own domain like that mostly shields from the provider locking you out of your email on a whim, but certainly doesn't help much with privacy.

I'm not sure this can work in general. You need some entity to forward and use the proper envelope headers for the mail to go through in the backend.

One serious problem is that email, apart from a means of communication, is also a means of authentication. Taking away a person's email address could easily mean that they will have to spend a tremendous amount of time changing it with various parties that have it in their records. At least those of them that can actually accept to talk to you (e.g. your bank or the IRS).

An non-optimal approach would be to actually own the domain name of one's email address and then use one of those providers listed there as the "backend" mailbox, by forwarding the "real" email address to the "backend" mail address. Most domain name providers will actually provide this kind of email forwarding for free. And it would be much much easier to switch between the backends. Or even use two of them simultaneously.

My sad thought is that today I'm probably never going to have the pleasant opportunity to be proven wrong by telling the kids to stop wasting their time on Fortnite :( .

Previous job, we were running almost everything in "normal" jails (as opposed to fat). We even stayed with ezjail, which is dead simple, because we were so comfortable with it and could understand how to manually fiddle with stuff when there was a need.

There are very very few things that cannot be told to bind to the real jail IP address instead of localhost. Most stuff will just work. And that's it. But there are also added benefits here:

* Parts of the filesystem cannot be altered, period. You update your base from your jailhost and every jail takes the change. That was an added security benefit.

* Pkg software can be individually installed per jail, goes into /usr/local. FreeBSD has already been brilliant in separating the base system from the third party software.

* For minor and major version bumps, we developed a simple set of steps and tools to upgrade a jailhost but leave the jails in their previous versions, maintaining multiple versions of base, like /var/jails/basejail104, /var/jails/basejail113, and so on. So the downtime is minimized, and each jail can be upgraded later in its own pace. This was a huge relief compared to having to upgrade everything only to find that some piece of software doesn't quite work correctly in the next version. And rollback is possible, by just copying the jail.

* Jails can likewise be very easily copied between jailhosts with a couple of rsync commands and some simple script.

Have used iocage and zfs and it is brilliant, but even without the benefits of zfs clone and snapshot, jails were (and I believe still are) a very pleasant experience to work with.