GeekNights Monday - Containers


#1

Tonight on GeekNights, we talk about containers (like Docker). They're not the panacea for environment configuration/distribution some people make them out to be, but they have their uses and you should know about them.

In the news, after an aside about axe murder, we consider Microsoft's acquisition of GitHub, Yahoo messenger is going dark on July 17th, and Apple has deprecated OpenGL.

Things of the Day

Episode Links


#2

#3

What has Microsoft bought and ruined?

Skype


#4

Your experience of trying to work out what containers are, and not just follow instructions on how to implement them, is what I go through every time I learn any bit of programming or web development or servers stuff. All the best how-to guides already assume you know EVERY step of the process up until the moment you need to do the thing, and then just throw out loads of jargon and commands and assume dependencies, etc.

Of COURSE you know every step along the way, or else how would be in the position to use this thing?

I worked out once that I did have something installed on my laptop/server already, only after spending two hours trying to get it to work for the first time, because something like three years ago I copied a command while doing something else… and it didn’t say what that command did, or how important it was, or anything. It’s incredibly frustrating.

How was I supposed to know that the really hard thing you are telling me to do now is something that was so easy it was just one step along the way of this other super easy thing three years ago? Answer: fuck you.


#5

The story of Apple deprecating OpenGL on macOS is the same story as Apple making a mixed framework to allow iOS apps to run on macOS.

iOS runs all its graphics on Metal, and now macOS has converted all their window servers and graphics to Metal. That means mixing display elements and windows from iOS on macOS is possible in a sensible way. Apparently having any OpenGL running on an macOS machine and trying to also show an iOS app with Metal is so difficult they’d prefer not to try it.

Games that use the big engines like Unity, Unreal, etc will be fine. Game companies that use their own technology in that regard will have to invest making it work on Metal or, more likely, not bother with supporting macOS.

However, to get a game running on iOS means using Metal anyway, and next year it will be possible to write one game that works on both an iPad and a MacBook. I think Apple is trying to steer developers into making games and apps that can take advantage of both the high power and screen estate of an iPad Pro, and that will also happen to be a powerful Mac app too.

It’s not the case of “drop support for macOS” but “we are making supporting macOS as easy as writing an iOS app”.


#6

How *NIX works and how HTTP works are well documented. You probably just aren’t looking or caring to learn all the foundational and prerequisite material just because you want to make a web site.

How Docker works was not well documented when it was new. Even now the documentation mostly focuses on the container registration and distribution functionality, and not on what is happening under the hood.

The biggest problem with removing OpenGL is that tons and tons of old apps will never be updated. When they actually remove OpenGL, they will just stop working. Bye bye. They can never run on Mac or iOS again. Common users will mostly notice tons of games already in the app store, just not working anymore or ever again if they don’t have developers maintaining them.

As for engine developers doing all the work for new apps, that is partially true. Any app that makes significant use of the GPU, even if it uses a major existing engine, is customizing that engine. At the very least they are writing plugins or shaders using OpenGL or Vulkan or something. That part of the code no longer being cross platform is going to be a factor in any GPU-based applications being cross platform or not. There is going to be software that would have been cross platform, but now will not be.


#7

Exactly my point. The answer always boils down to “Fuck You”.


#8

Can’t build a car without learning about engines first.


#9

I side with Scott, containers are not for the layman. If you want to play with these things, that’s great, but it’s not unreasonable to expect that someone knows their Linux/UNIX fundamentals well.


#10

I thought it was Tuesday, and saw the title thinking this was an episode about Container.


#11

I agree with not being able to build a car, but this is not being able to use a car. And knowing how the engine works is utterly impossible unless you already know the magic words to open it, and when you do find out those magic words, actually it’s just “fuck you” all the way down.

People who think like you are the problem.


#12

If you want a web site without programming, gotta use Square Space or something like that. If you want to write code, now you’ve opened the hood.


#13

I will say that I want there to be better tools that sufficiently and safely abstract the underlying systems such that someone like Luke can work on a higher level.

I think the reason they don’t exist comes down to the lack of a commercial model around such a thing. The tools and resources that are free are aimed at experts/hobbyists or appear easy but have hidden dangers. Non-expert hobbyists are too small of a market to feasibly support, since anyone you can make money from is going to pay for an even higher level of abstraction (e.g., SquareSpace or other managed hosting solutions).

So you can build tools for experts and expert hobbyists, often in service of your own personal expert needs. Or you can build services for people who will pay. The narrow middle isn’t easily served in a capitalist economy.


#14

People do make these kinds of tools. The thing is they all use the cloud to deliver them as non-free SaaS. Want to write a web app in Python without learning any *NIX? Pay money to Heroku or some shit. Want to host your own Git server, but don’t want to learn, pay GitHub/Lab some money.

If you actually want to do something on your own, then you need to spend time learning instead of spending money.


#15

I look at it like CentOS/KVM vs VMware. Centos is free and works great and there’s documentation abound, but using KVM is still way harder than using VMware. For that convenience, you pay a steep licensing fee.


#16

Or even more simply, macOS vs CentOS. I’m loving me some CentOS on my home PC right now, but MacOS is way easier to use.


#17

I’ve been debating going to linux for my primary os for a while now, not because I think that’s a particularly good idea. But I do think that’d be a great way to learn / practice the fundamentals. Basically give yourself no choice.

For the record I’m a sysadmin, I know the fundamentals, I just think having a like… primary motivation to practice is better than just having a work motivation.


#18

The last time I used Linux as my primary OS…

  1. I didn’t play any PC games. At all.
  2. I was willing to spend a TON of time fucking around with audio to make awful OSS audio software work correctly
  3. I never touched anything once it was working
  4. My computer was a glorified web browser and crashy audio platform and nothing more.

#19

It’s better now, but I’m only doing this because I’m not currently gaming.


#20

Part of my motivation is a thing I’ve only recently heard of called a GPU passthrough where, you basically run a windows VM and using the passthrough, occasionally give the vm your full graphics card, allowing you to game in windows, while still having linux as the primary os.

Getting that working is easier when you can’t game until you get it working. It’s one of those, “ok fucker, backs against the wall now, its like your finals again, get it working or no games”

That’s really what this would be for me. A way to force myself to learn, not just get it working and never touch it again, but really learn, linux fundamentals. Downside is linux isn’t a desktop OS, not really and every now and then I’ll run up against that wall.