kdmytro

I only purchase games that claim Linux support. I don't need to play every new game as they come out because I simply don't have too much time. There's enough Linux games to fill my time.

Did you us eye tracking to check that the users never look at the scrollbar?

I am Ukrainian and I can confirm, we do not exist.

I wonder if tye price is truly steep, or if I am just spoiled by free IM services offered by data harvesting companies?

$5 per month is a big entry cost. And I am not sure how well this price will work in the long run when people begin using the server a lot. Perhaps pricing based on message throughput or used storage capacity would make for an easier and fairer entry.

Wait until they hear about International Master.

Response from the YouTube support team:

> Sorry about that

Yes, freedom is such an encumbrance. Life is so much easier when someone makes all the decisions for me.</sarcasm>

No. Why?

Self-hosted costs are the same. Bronze is gitlab.com tier, Starter is self-hosted tier.

Why?

Just because you can does not mean you should. You are responsible to arrange your workspaces in a usable manner yourself. I personally make use of i3's (also a tiling WM) tabbed mode where I can make a stack of windows occupy the same area with a list of windows above it, much like tabs in a web browser. Tabbed mode is useful for when I open a bunch of programs that I don't want to close, but don't need to see all at the same time either.

What is PIP?

What massive arming?

Linux ISOs downloads mostly.

My monitor has a built-in USB hub that works exactly like this, 4 A inputs and 2 B outputs plus an extra USB-C output.

To be fair, setting up a runner for Gitlab CI is very simple too. We self-host GitLab and we only have one runner on duty, but some projects have many stages that can be executed in parallel. I start a docker runner on my laptop before pushing new commits, which cuts the CI wait time by half.

Why?

It's spelled Chornobyl.

FYI, 05:40 is every hour.

> a lot

I see what you did there ;)

Like you said, DPI (or PPI) is a physical property of a screen. You don't set it for the screen, you just let your text rendering software know the DPI so that it could get the absolute text size (in mm) correctly. Let's consider two 15.6" screens: 1. 1366x768, ~100 DPI 2. 1920x1080, ~141 DPI

When rendering a piece of text in a certain font size on both screens without specifying correct DPI (e.g., leaving the default DPI value of 90), the text on both screens will take up the same amount of pixels, but the absolute size in mm will be different (text on screen 2 will be smaller because pixels are denser there). If you, however, let your OS know the DPIs of the screens, rendering the same piece of text in the same font size on both screens should lead to the text physically taking up roughly the same area of the screen (as much same as it could be, taking into account the fact that pixels are discrete). This is true because point[1] is an absolute unit of measurement.

To give you an example, when I switched from 1366x768 15.6" laptop to 1920x1080 15.6" laptop I specified the new screen DPI in my desktop environment font appearance settings. This made all the text be roughly same size as on the old laptop, only smoother due to greater pixel density.

> Isn't the solution for "small letters on high pixel density screen" scaling as mentioned by arvinism or simply increasing the font size?

This way you must render a picture as if the screen has higher DPI, then scale it down to match the desired DPI, you still have DPI in play here, and absolute text size implications described above apply here as well. You can use scaling for antialiasing, though.

---

[1]: https://en.wikipedia.org/wiki/Point_(typography)

You have to set DPI that is appropriate for your screen size. If you keep using the default 90 DPI with a 15" 4K screen, the text will for sure be small because it is rendered as if the screen is about 49".

That would just be an outstaffing firm.

Using Django sessions in an SPA is actually very easy. It just works, the browser handles the cookies for you. The only thing that developers has to do is to remember to include CSRF header with unsafe requests (such as PUT or POST), this is usually done by adding some kind of a pre-send hook in your request library of choice. There is a section in Django docs that explains how to do just this.

>> A point.

> No. Literally the same point, but in different words and with a feel of authority.

You should consider using words other than "No" if you agree with the point.

I use DuckDuckGo for a similar reason. My Google search settings are set to show result in Ukrainian or English, but Google never follows the settings and returns results in Russian for queries that are clearly written in either Ukrainian or English. DuckDuckGo will give you results in the language you made query in, as you'd expect.

The patch is about ALTER TABLE ADD COLUMN with non-null DEFAULT. Your step 1 does not have a default value so this patch will not affect the database behavior. Postgres will not do anything with atthasmissing or attmissingval on steps 2 and 5 because these are ALTER TABLE ALTER COLUMN DROP NOT NULL, which is out of scope of the discussed patch.

To be fair, nowhere on the linked page does it say that this is a postmortem. The submitter called it that.

Rain?

> ... and distributed ledger development.

You are careful not to say "blockchain" :)