naranha

I wonder if this is simply a financial decision to get more money out of institutions that are using win10 and need the support... I think there is no technical reason for this move, because the Windows core code base does not seem to have changed that much since Windows 10 - or even Vista/2000 - and there are no breakthrough changes coming that I'm aware of. This also seems like a bit of a back paddling move after having announced that Win10 be essentially a rolling release. In any case I don't mind either way, because I don't use Windows, but it looks like it could again cost millions of tax payer money to our state's institutions that somehow can't wane themselves of Windows, even though alternatives exist.

Interesting how the embedded XML syntax resembles today's JSX, I wonder if it took inspiration from it.

Well the article is from 2014, this should be mentioned in the title. I noticed it because the author was not even talking about the dataloader pattern used often in the context of GraphQL when asking for new patterns.

In Node.JS the dataloader processes N lookups simultaneously in the next tick of the eventloop. So call(1) call(2)...call(n) would be executed as call([1,2,3,..n]) allowing you to efficiently implement it.

...which makes the distinction even harder in node, because it is a callback based language. Nearly everything is based on my code being called.

Sticking with the example of express.js, for me it feels more like a library since I'm still in control of the program flow, even though I need to adhere to certain interfaces.

The term framework itself is kind of hard to define and in many cases almost identical to "library". Is express.js a library or already framework? Or both? At least it calls itself a framework..

Many libraries or frameworks do one thing and one thing well, but there are also frameworks that are a collection of libraries for different purposes. I feel entrenched when frameworks limit library choice by making it hard to switch out components. From that perspective I prefer libraries over frameworks, but the distinction is kind of hard to make.

My concern was more about the animations switching workspaces being too jarring, but they are pretty smooth.

I was a bit sceptical, but I have to say that the horizontal workspaces work pretty well. Working with GNOME 40 is both efficient and aesthetically pleasing. And as a side note performance is much better too on Fedora 34.

> Workaround: None at this time.

I wish I could say that to my customers...

> I don’t know how I feel about Wayland.

Me neither. On the one hand I switched over 2 years ago and it worked fine for the most part, there a still a few things missing. One of the things were headless displays and it seems like there will be something like that in GNOME 40 - though probably experimental.

What bothers me most is that innovation is so difficult. Everything needs to be standardized first and then implemented in all different desktops like KDE and GNOME each in their own way. And this process is extremly slow. Back in the Xorg days many cool programs were made by independent users (for sceensharing, automation etc.). Writing a new Desktop or porting over one from X is almost impossible, were it not for wlroots. I wonder if we are not sacrificing too much in the name of security (OK an evil program can not keygrab and control other windows, but it can still read all my SSH keys etc.).

Unrelated to the article, but perhaps an interesting fact: as a Java programmer you perhaps know that using the class java.util.LinkedList is almost always worse in than using plain arrays or ArrayList. Even though there are much less allocations, the overhead for maintaining the linked list data structures is immense. And it turns out that computers are pretty fast at allocating memory.

But there more optimized implementations of linked lists of course (probably using arrays as well internally (?)).

I don't get this whole debate. Who decides what is boring and what is exciting technology?

Kubernetes can be pretty boring for somebody who worked with it for years, but an exciting, eye-opening experience for a team who has no experience with it. MySQL can also be exciting if you have only worked with Excel in the past. NoSQL can be exciting, but it can also be a safe bet if you need a multi master db, because your app needs to work offline.

I think it's easy to say a technology is safe or risky to easily promote or dismiss it. But in fact it makes sense to study and experiment with both boring and exciting technology to know if it might make your work easier and your results better.

Hey, I like that I can play around with RHEL without too much of a hassle.

Nevertheless for me that is not a replacement for what CentOS was: easy to deploy for small or personal projects without requiring registration/sign-up and you could leave it (mostly) alone for 10 years or so. Though for now I'm fairly happy with CentOS Stream, we'll see where it goes.

Ah yes, that makes sense. I didn't understand they were talking about the ENV command at build time.

It was the heading that got me on the wrong path, I think that should be clarified further:

> Do not store secrets in environment variables

> Using ENV to store secrets is bad practice because Dockerfiles are usually distributed with the application, so there is no difference from hard coding secrets in code.

This sounds wrong. If secrets are in the environment they are not in the Dockerfile, so they are NOT distributed with the application.

Aren't relational AND syncable very difficult to combine? Foreign key references for example may not yet exist on one instance when they are synced. P/CouchDB and Git support multi master sync which is great, but they are not relational.

The workaround is to detect foreign key violations in your app with indexes or a job that runs on the nodes.

PHP is a html template engine, so using it to create an API sounds like "The wrong way" by definition. I think you actually need these frameworks in PHP to turn it into something other than a template engine. They recompile your code, change the way it is loaded and accessed via HTTP, it's a whole different way to use the language and runtime.

As said in the comments, some abstractions are possible with stored functions and views, in PostgreSQL you also have generated columns now. I'm sure there are more.

Abstractions built on ORMs or query builders have the disadvantage that they are tied to one language and framework and application, making them less reusable.

Well, that's a lot of text to read. My (high-level) thoughts as a systemd user for 10 years is that it improved some things, made a few things worse, but I would not want to go back to the init.d days. Having a daemon around to manage the lifecycle of services is actually a good idea and most of the *ctl programs are preferable to the manual configuring they replace.

On the bright side, the performance tax we had to pay before the current generation of frameworks was often the "full page reload" tax, needing to parse megabytes of CSS, JS for almost every user interaction.

A question I ask myself often is what niche does a language fill, and it seems a little like the traditional niche of PHP has been eroded away in the last decade. Many of the things that gave PHP an edge (ease of deployment, templating within your HTML files, direct SQL queries) are no longer considered the correct approach.

At the same time PHP is trying to reinvent itself by adopting a strong type system and experimenting with async and long running processes. But these are niches that are already filled better by other languages (Java/C#, Node, Go), so it feels like they are fighting an uphill battle. But maybe it is that tenacity of the language to stay relevant that makes it attractive to a younger generation of developers and decision makers.

Another Pro is that they can be read client-side, so the server and the client have an agreement on who the user is and what their attributes are (if they are defined in the JWT payload).

Strange, it seems to work fine for me on 2 FHD monitors at least. Maybe I just don't see it...

Most xorg drivers have an option to run in tearfree mode.

Another dealbreaker for me (i did the i3 sway journey this summer) is the early stage of remote desktop. With x it is super easy to spin up a nice vncserver. I also miss setxkbmap, xrandr, import etc.

Wayland had some nice ideas and some not so useful ones. I'm waiting for something simple to replace xorg and wayland in the future.

Also in my experience DB Schemas often (but not always) outlast logic implemented in applications. The more the business assumptions reside in the database, the easier it becomes to rewrite applications on top of it later.

One legitimate use case could be calculated values that you want to use in several apps (written in different languages) and in SQL reporting.

Is systemd-nspawn more secure?

Yes that's true - it's a backwards compatible change.

Still, static analysis is necessary when you upgrade dependencies and for your own code. For example for seeing whether adding a type to a property breaks code somewhere else. Discovering type errors at runtime is often too late.

Luckily there are good static analyzers for PHP.

I'm still not so convinced by PHP's runtime type checking system. It adds a little overhead, I guess that's not such a big problem, but it adds also new classes of runtime exceptions that can only be caught using tests, or with a good static analyzer. Especially if you now upgrade your application to 7.4 you can only do it with confidence when you have 100% test coverage.

If a static analyzer can detect these mistakes, why even add runtime checks for it? Think TypeScript/Javascript, after the compilation is done, most type checks are removed for performance reasons.

Or perhaps there is something I don't see...

> Magento is not exactly known for well written code

As are many/most PHP 5.6 projects

> Probably their code should not be used.

In reality it is - unfortunately. And many smaller companies don't have the capacity to change.

Sure all these problems are important to address. But often there is a lack of time/interest to do it.

I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...