World of Warcraft is a massively popular 16 years old game, and maybe one of the most popular games ever. Since its launch in 2004 it’s been changing and evolving into what it is today, which is something completely different to what it was in its inception. Given that a large number of people would like to play the Vanilla WoW, that is, the first version of the game before any expansion was released, Blizzard has decided to roll out a “classic” version with all the content prior to the first expansion. This expansion was released in late 2006, and since there have been many more. Before the company’s official announcement that they would be releasing this classic version, many requests were made for it by fans but they were turned down by Blizzard citing several arguments such as: “the vanilla wow doesn’t exist anymore since the codebase has continued to evolve” and “Vanilla wow would be looking back and we want to move forward”. However, a vanilla WoW paid server named Nostalrius, maintained by fans for fans gained such popularity that during its peak it had more than 100k players on it. Sadly, it had to be closed in 2016 after Blizzard sent them a cease and desist order. It would seem that from the whole episode the company realized that there was actually a market for a classic WoW and they eventually changed their mind.

World of Warcraft is a popular commercial subscription-based cloud-hosted enterprise legacy app featuring a low grade CRM system married to a highly complex logistics system in a standard 3 tier architecture deployed in a fully sharded configuration. Like many legacy systems, it has undergone significant schema mutation over the course of its deployed lifecycle in response to customer demand. Notably, it started out with a mostly-denormalized schema and, with the advent of improved database performance, a better understanding of the customer base’s requirement envelope, and feature creep, it has moved towards Codd’s 3rd normal form.

As with many legacy apps, some customers’ business needs mandate that they stay pinned to older versions of the app. Interestingly, customers have here asked that an earlier version of a cloud-provided app be made available 12 years later, which poses some interesting issues having to do with incompatible schema migration. Given that the app is also written in a mix of obscure legacy languages, the traditional approach of simply migrating the queries and schema together is technically formidable.

One established practice here is to create a proxy facade layer. In this pattern, you keep the interface to the legacy client application exactly the way it is, but create an intermediate layer which translates the db calls to and from the normalized format. This incurs round trip cost and bugs are common in edge cases, especially in frequently-undocumented minor shifts in API and field meaning, and especially given the expected low coverage of unit and functional tests in a 12 year old codebase. This technique is frequently overused owing to underestimation of the cost and time complexity of ferreting out the edge cases.

The other established practice is to perform a one-time wholesale schema migration, normally done either through an ETL toolchain like Informatica, or more commonly through hand-written scripts. This approach frequently takes more developer time than the facade approach, owing to needing to “get it right” essentially all-at-once, and having a very long development loop.

Whatever the technique used, schema migration programs of this scope need a crisp definition of what success looks like that’s clearly understood by all the involved developers, project managers, data specialists, and product leaders. Too frequently, these types of programs fail owing to incomplete specification and lack of clearly defined ownership boundaries and deliverable dependencies. The industry sector in which this legacy app resides is at greater than average risk for failure of high-scope projects due to fundamental and persistent organizational immaturity and improperly managed program scopes.

Also, they better not nerf fear, because rogues were super OP in vanilla and getting the full 40 down the chain to rag with portals was tough enough.

and this is why all kernel development is today done in Lua.

Hi, a Zotac user here. CPU is a bit slower than I expected, but overall I’m very happy with my setup. Zotac CI527 is cheap, well built, and silent!

It seems like the best Zotac fanless PC is the ZBOX-CI549NANO-P which uses an i5-7300u. The author of the post installed an AMD Ryzen 5 1600.

2 cores/4 threads vs 6 cores/12 threads.

Thanks for the link! A few thoughts:

Wow, Zotac is really bad at selling silent computers. They have a ton of models and I don’t see a way to see only passively cooled models.

The silent PC crowd are all about x86 at the moment. I wonder how ARM fares here. Are all end user ARM machines like Raspberry Pi? (Its CPU is too slow and it has bad IO connectivity.)

It feels like the K8s train replaced the OpenStack train.

LOL I couldn’t agree more. “systems-screwer-uppers” I hadn’t heard that before. beautiful turn of phrase!

What’s your preferred alternative? The walled, proprietary gardens of Apple or Microsoft? OpenBSD?

It’s a serious question, Debian Stable as a desktop OS is working reasonably well for me. I wan’t a unix-like system - No Windows - which offers broad choices of hardware - no OS X - and it should be free software - one of them. I’d switch to OpenBSD for most of my work, but I need stuff like docker for work and want resonable gaming support at home. I could switch between different OSes for different tasks, but why bother? Debian truly is “the universal operating system” for me, even with all it’s faults.

FWIW, I use FreeBSD on my Laptop. I know it is not ideal but I choose to do it and work through the pain because I can and because I think it’s good to support options.

Huh. Because my Linux desktop is peerlessly stable, bears no resemblance to anything Microsoft has released in the past thirty years, and is community developed and supported. I in fact find that the commercial desktop environments are unstable, unusable buggy garbage, and I’ve had the misfortune to have to use both of them fairly significantly.

Don’t confuse “Linux on the desktop” with “GNOME on the desktop” (or, for that matter, “intentionally using unstable software on the desktop”).

The microservices that are all the rage these days adds a whole new layer of challenge to understanding dependencies. While monoliths have their own challenges, at least all of the information is there to understand what is connected. I’m still not sure if this has been adequately solved.

A language being free from a many common bugs does indeed change the set of common bugs for that language. But that doesn’t mean that it is indeed free from many common bugs of the languages without those safety features. You absolutely do gain a certain amount of safety the stronger your type system is and that does provide a fair amount of value that shouldn’t be dismissed just because there are still possible bugs. Type systems in many cases manage to push the remaining bugs into the “spec”. Which has the benefit of allowing you to fix the bug by fixing the spec and then having a compiler tell that you have indeed actually fixed said bug.

For developers who can leverage this power it’s really useful and increases productivity. For those who can’t yet leverage this power it just feels like the language is slowing you down.

I wouldn’t say PostgreSQL relies on “owning” an entire machine, but if you want that, you can create node pools with taints, and then setup your PostgreSQL pod such that it can tolerate said taints. It will be the only pod allowed to be scheduled on that node. (I suspect you might still have some Kubernetes infrastructure running on that node, so I doubt you can literally remove everything, but you can certainly manage the allocation of pods to nodes in a fine grained way.)

Yeah you can be direct without being a dick. “I won’t merge something that breaks the kernel, please find some other way.” would have worked just fine.

The only thing I’m getting tired of is people pulling the odd email out of thousands and wringing hands over how mean Old Man Linus is.

Maybe folks should reflect on how, after 25 years of loud and blatant protestations by Linus, fucking morons keep trying to merge the same types of userspace breaking bugs.

Maybe, sometimes, a broader more accepting tent isn’t the answer.

Linux would not be what it is today if they would be “merge-first-fix-later” type code-conducted safe place for noobs to mess around in.

Nope. I think he’s great. And I’m very glad that he is stewarding the Linux project to this day. Whether you think its ‘nice’ or not, his management of the Linux kernel has produced superlative results - and sometimes, in the thick of the mob, you have to be an asshole to get people to work the way they need to work to continue producing quality results.

What I am sick of, is petulant snowflakes who think they know better than Linus how to manage the 1000’s of developers that want to have their fingers in the pie. The kernel doesn’t care about your feelings, and neither do 99.9999% of the kernels really important people: its users.

If a security vulnerability is introduced by design it’s still a bug. It just means the mistake was made at design time as opposed to implementation time.

In all sincerity here, what would it mean for a person to say, “I’m not going to tolerate this behavior?”

Linus would still own the Linux trademark. He’d still control the mainline kernel repo. The “lieutenants” that manage various areas of the kernel would still control those areas and report to him. It seems very unlikely that they would support a coup. (Anyone who had a major problem with Linus’ behavior wouldn’t have lasted long enough to get one of the top positions.)

As a user, you can choose not to use or support Linux. But as a user, you don’t get to change the way the project runs.

I think the most extreme option you’d have would be to fork the source code and try to attract both a large developer community and a large user base on the basis of running a more inclusive community. But there’s a chicken-and-egg problem to that approach.

There’s an implicit hypothesis that says, “A more inclusive community will produce a better kernel.” Let’s assume that proves to be true. Some users would switch on that basis alone, but most will wait to see practical benefits. Since it would still take time for a fork to produce tangible benefits, you’d have to attract developers and users with the promise alone. We have a small set of cases to examine, where a major open source project was forked with the intention of creating a better community. It appears that the majority of users will hang back with a “wait and see” approach.

I really don’t know what kind of negative feedback anyone could apply to Linus that would have an effect.

This behaviour would violate the code of conduct of any sensible project.

Maybe you should run a kernel made by the CoC crowd. I’ll stick with the foul-mouthed guy.

And Direct3D. But for an electron app it really is minimal: only 145.3 MiB on disk.

A “minimal X app” generally means an app with a simple and straightforward interface, not an app that fits in 64kb.

I mean, you sort of need a browser to render markdown.

first, there was the dark ages of managing your own dependencies. Then came the new age, where people began relying on package managers and upstreams to handle dependencies for them. This was revealed as a false dawn. Package managers and upstreams are no better, and frequently far worse, at managing your dependencies than you are. Now we are tentatively exploring other alternatives, in which it is possible to lock down dependencies. This is probably not working either. Simple solutions may not be forthcoming.

There is a AppImage daemon that is supposed to update appimages if they embed a special manifest.

What I personally like about AppImage is that it’s much simpler than using the package manager; download a file and run it.

On the other hand, yes it’s true, with appimage you don’t get all those nice updates of dependencies being shoved into everything you run on your computer. But docker has stopped that trend nicely anyway, atleast on the server and when heavily relied on.

I like this comment because you could mean it three ways:

1. What is wrong with kids these days and their XDG crap? Dotfiles are a perfectly good solution and aren’t visible in ls output by default, anyway.

2. What has happened to Unix, that so many programs need to specify configuration data in $HOME? Well-designed Unix programs should be simple enough to need no configuration in the vast majority of cases.

3. Hiding files beginning with a . was a terrible idea totally out of whack with the rest of the Unix ethos. It’s up there with filesystem links and BSD sockets for worst additions to the system.

I vote for option three, but which one were you going for?

Real Unix® operating systems distribute configuration across ~/.app/, ~/.config/app/ and ~/Library/Preferences/org.foo.bar.App.plist, so I’m quite happy with Linux converging on the XDG spec.

What’s the significance of the “8 or 10 pole” part?

The HTTP library complaint really threw me too, because it seems to imply that other languages have more features in their standard HTTP libraries. In Python or Ruby if you wanted to write a similar web server as what you could with Go’s (basically just simple routes that do things) you’d have to grab a package like Flask or Sinatra, because the base language doesn’t support things like that.

It just seems like a complaint because the author wanted to complain. If you’re pointing out something bad in about the core libraries, and then comparing it to a third-party library in another language, you’re not making a fair comparison.

On broken package management: Go does have issues with package management - it’s very much a weak spot. Vendoring is the official workaround, and whilst it’s not perfect, it does work.

I am using a combination of GNU make and goland/dep for every new Go project and I and my coworkers are pretty happy with it. Here is the project template I use if anyone is interested. To summarize, go dep and other tools like gopm and glide make package management pretty easy, thus it is not a real issue anymore.

Among other things, he doesn’t mention what he’s using instead, which doubtless has tradeoffs of its own.

I feel like the OP is a significantly better read than your reply. You assert that it’s all been said before, but then later say that the post makes surprising and novel claims. You decry subjective measures, but your entire reply has no meaningful backup for any of its arguments. You state that there’s objectively wrong claims (in an opinion post about programming!), but then don’t say what they are. You refuse to even address an argument the guy makes. Frankly, your post is awful.

Network effects. Default choices. AWS launches with linux support, so people pick linux, then they pick docker, etc etc etc.

Linux does solve a great many problems that OpenBSD does not. (Well, it offers a great many features and buttons and such which look like solutions. :)) I’m not sure that one operating system that solves all problems is the best approach, though. there’s a lot of disagreement about how even a desktop OS should work and how components should fit together.

Hardware support is what keeps me from switching.

The following HN comment from Brendan Gregg might be worth a read. It’s answering in detail basically the same question, just for Illumos rather than OpenBSD: https://news.ycombinator.com/item?id=12837972

Linux is easier to use.

How do you search for a package in OpenBSD? How do you get a description in your search results? You can search package names by downloading the index.txt file from the packages directory on a mirror. But anything more sophisticated you have to use the ports tree and the janky makefile system with non-intuitive syntax and cryptic errors to do any interesting searches.

It’s actually possible to download and install a Linux distro that comes with a desktop environment, installs quickly, and works fine right away. When I was first getting into non-Windows operating systems in middle school, I tried out OpenBSD because the whole secure OS thing sounded cool to me. I screwed with it for hours, felt like I was getting nowhere, then gave up and installed Linux Mint.

I run OpenBSD now, but I’m also a systems programmer / SRE at a database company, so I’m not exactly an “average user” that represents the trend of the market.

The file system isn’t great…

[Comment removed by author]

Same reason as many other similar situation throughout the industry. People know something else, a lot is built on other systems, marketing, and once you have a certain amount of people using tech X it’s really hard to use something else.

Another side effect that kicks in with Linux Distributions, Operating Systems and Programming languages is that at many places if you introduce a technology that isn’t the currently dominant one you will be personally blamed for every single bug or different obstacle it has. It will often be blamed on it, despite also existing on the dominant OS.

Something related is that sadly a lot of software that companies and people end up using at some point is written in unnecessarily non-portable ways. I once worked at a company that used a software running a bash script (stored inside a string in a program) and it had a typical non-portable #!/bin/bash instead of #!/usr/bin/env bash. As usually I’d report that and even create a pull request on a huge (in terms of stars, in the tens of thousands) and very hyped software, expecting it would be accepted. After being baffled that the authors didn’t even know about /usr/bin/env and what it does, a link to Wikipedia didn’t help either the conversation stalled. Since that project was being used by the front end developers I kept patch sets for such things around.

And while those tiny things are really not hard in general these tiny things add up. I know the problem even exists if you don’t use Ubuntu, but for example Alpine in the Linux world.

Having these kind of portability issues leads to the dominant technology in a field to quite often not be the best. The most famous example is how long Internet Explorer stuck, despite Opera and the Mozilla browser, until Firefox came along.

When there is a lot of users and developers even pretty bad technology can stick, because there will be widely used workarounds for problems, there will be progress on fronts, even when the architecture is flawed, etc. Change is rarely that quick, especially when many parties are involved and put their money and effectively lives on it.

Of course that doesn’t mean that Linux is bad and OpenBSD is great, just that technical superiority or being a bit better than others usually is far from a good indicator for dominance in a field. Especially if marketing and politics have a big presence, but even without. People simply need to have heard of it and a good reason to switch and get into something new to them and settle there. When there is no direct financial effect, that is significant enough people tend to not just switch utilities from one moment to the next. And even when you know OpenBSD really well and are convinced its better introducing that in an existing company might not be an option. Of course you can always switch, but why give up a safe, well-paying job with great coworkers for an operating system?

Docker / namespaces

Don’t think I’d include Rust in that. M:N threading was a feature of the language early-on, but it was removed because it complicated the runtime. What you link is a third-party library that tries to provide a library implementation of green threads, but 1) it’s not part of the standard language, 2) it’s alpha-quality code with no official release, and 3) according to its own continuous-integration tests, it doesn’t even compile currently.

The whole Internet feels overrun with extrinsic motivation.

It makes it feel rare to do something because you like it. It has to be about stupid vanity metrics, such as likes, retweets, views, stars, and other things that don’t matter but well, actually they sort of do because we need to like what others like to really appreciate it.

This is completely antithetical to forming one’s own taste, which is a prerequisite for actually doing great work.

what conversation are they polluting, exactly?