geezerjay

> the question is if an early stage start-up with 4-5 devs where they typically already struggle to get basic CI in place ...

Nowadays it's super easy to setup a CICD pipeline. The basic settings and intro examples alone are enough to build and publish container images to a container registry.

> and where 1 of the devs loves K8 and the others don't really know it (but don't object because it's nice to have it on the CV), whether they should really already focus on orchestration and scaling before they even have a MVP.

That doesn't make any sense. Developing services to run on kubernetes is a software architecture problem, one which only affects some minot dev level details such as supporting env variable settings. Devs can be entirely oblivious to kubernetes and still be effective.

> I think we have reached peak k8-hype last year when F. Campoy

That's largely irrelevant and misses the whole point. Just because some people present some gimmicky take on a technology it doesn't mean the fundamentals are not good. Kubernetes allow distributed services to be deployed transparently across multiple providers (thus you are not held hostage by a seller), and allow services to automatically scale horizontally with demand and within resource limits gracefully degradate after that point. That doesn't go away if someone decides to reenact Inception with buzzworthy technologies.

And that's how your skills gradually become savage. Kudos.

Machine learning may have been used and abused as a meaningless buzzword but kubernetes in particular and container orchestration in general is a well established and proven infrastructure technology. If you are not operating a monolith and you need to automatically deploy and scale your service then you have no technically-sound argument to not use this sort of infrastructure.

You've missed the point. The argument is that eventhough aiming for FB scale is absurd, some considerations should be taken under consideration from the start. We're seeing YAGNI-style arguments being abused to sell the idea that just because it's absurd to think 10 steps ahead it's also absurd to think 2 or 3 steps ahead, which makes no sense at all.

It's a very good time to dive into microservices/containers/container orchestration.

Good times.

> For Qt dlls, use windeployqt.

This, and there are also applications which state which DLLs are missing from a deployment.

> Some pilots were able to successfully do a 180 in a commercial sim and land the plane at the airport.

It bothers me how this excerpt sounds an awful lot like an attempt to downplay and even criticize mr Sullemberg's accomplishment.

> Qt has a similar story lately, I think there's an "old fashioned" API, and a JavaScript API, and a XML-like thing too, and I just don't know where to get started with 100% confidence that I'm not learning the wrong thing.

Qt is way simpler and straight to the point than you believe it is.

Qt's UI files are XML files that offer a convenient way to design layouts which are intended to be used during the build process to generate C++ code. You are free to manually define layouts by instantiating Qt Widget objects but what's masoquism.

It's also possible to use the same XML documents to dynamically generate the UI, but I never saw a project using that in any way.

Then there's Qt Quick. That's an entirely different beast. The UI is defined with a DSL designed for this very purpose, and javascript can be used to handle UI events.

> in the AMD case, hardware is already on the market so a bunch of regular people ran the benchmark.

That only raises mor doubts regarding the validity. What's the meaning of that magic value? Is it the average? The median? Are there any outliers? Was any outlier removed?

The benchmark states that, for intel's processor, "# of samples" is 1 while AMD is 32. What does this mean? Are Intel's results taken from a single lucky test run while AMD's results are a statistic compiled from 32 test runs?

> This is akin to people who say, "The problem with homelessness there has one simple cause..." and then insert their favorite boogeyman.

It's pretty obvious that the housing shortage problem is caused by those who oppose building additional houses although demand is skyrocketting. There is no way around it.

That is not a fair assertion. You might have ignored static analyzers until you've discovered clang, but that observation is not generalizable. As others have already pointed out, lint has been used extensively for decades.

> This will affect all of your styles.

Your example affects all div elements which are not styled. If you also include class and/or ID specific definitions then your padding setting doesn't cascade and those are not affected. That's the point of CSS.

> where you fight to style your local components

That's not true. Style changes do cascade but they only cascade where the designer intends them to cascade. If a designer specifies that all div components shall use the same padding then you can't complain that all div components are using the same padding.

> This statement makes it sound like every Qt application uses CSS. That's not true.

The applications that are ok with the default style don't need to specify style. Nevertheless Qt is an UI toolkit that supports CSS styling.

> I'm not aware of any FOSS Qt applications using CSS.

And that's ok. Nevertheless I've already worked on a couple of Qt projects that used Qt Style Sheets extensively. In fact, that's pretty much the norm in any non-desktop project.

> You could theoretically see better real-world performance.

That assertion isn't very realistic. Performance benchmarks comparing gcc and clang are mixed, with performance differences being marginal at best.

https://www.phoronix.com/scan.php?page=article&item=gcc9-cla...

> You accidentally apply a global style, and your entire UI is broken.

That's only a concern if your UI elements depend on global styles, right?

Meanwhile, UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs

> The connotations of "toast" as salutation are even worse here;

I don't understand your problem with the concept. It's pretty clear what it means and how it operates, and the UI concept has been extensively disseminated and adopted, not only in web-base UI and UX but also in GUI toolkits for mobile (android) and desktop (Windows 10).

Exactly where are you having problems understanding the concept?

> The point is, "because android does it" is terrible reasoning for naming the thing.

That was not the point at all. The point is that the concept of a toast exists and is already widely established. Android is one of those platforms. That's it. I fail to see the point of bitching about Android as if that would undo the dissemination of this particular UI pattern. I mean, Microsoft adopted the concept. Do you expect to undo that by bitching about Windows 10?

https://blogs.msdn.microsoft.com/tiles_and_toasts/2015/07/08...

A "toast" means a few words of salutation. That's the purpose of the Toast UI element. A user requests an action, the action returns a successful response, the user receives a message consisting of a few words announcing the success.

Just because you are oblivious to the concept it doesn't mean it's bad. It just means you need to learn something before blindly asserting that stuff you don't know and are not familiar with is for some reason comparable to dog shit.

> Why not just call it <notification>?

In Android land, a "toast" is a particular implementation of a notification.

https://developer.android.com/guide/topics/ui/notifiers/toas...

> k8s will only redeploy containers when a node fail.

That's not true at all. Kubernetes monitors containers' health and automatically scales deployments according to the demand. Thus quite obviously kubernetes does help make your system distributable, scalable and reliable. In fact, that was the design goal of kubernetes.

The following link states that rexray does not support shared volumes, and that it was designed so that "it forcefully restricts a single volume to only be available to one host at a time."

https://github.com/rexray/rexray/issues/343

From the POV of a former researcher who abandoned his PhD due to being fed up with the constant abuse and lack of perspectives, this article is infuriating. It sounds like a praise of indentured servitude. The argument is exactly the same: they don't need rights because they are receiving training.

Docker Swarm doesn't support basic features such as shared volumes (between separate hosts), though.

> Ultimately AMD fumbled with the Bulldozer/Excavator lines of CPUs

I've heard this baseless assertion before but so far I've never heard any semblance of support. Why do you believe that AMD "fumbled" with their Bulldozer line?

> Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine.

Python does not have access modifiers. C++ does. It makes absolutely no sense to write Python code in C++ while entirely oblivious to basic, age-old C++ features just because your background lies somewhere else and you failed or refused to learn even the basics.

And you know what actually works instead of just "working fine"? Having the compiler throw an error if a careless programmer tries to access private variables.

> In my IDE in c++ I can quickly refactor m_ to non-m to make it "semantically public" without having to edit header files, change struct packing order / ABI, etc.

Don't you understand that's completely irrelevant? Just set the private member as private and it does not matter at all which naming convention you follow. Don't you understand that having to do nothing is better than expecting team members to be prescient about your convoluted and absurd naming convention used to avoid best practices?

> Besides, in c++ people can always cast your intricately-protected object to a void pointer and start manipulating it nefarioisly anyway.

Don't you understand that't entirely irrelevant? You're trying to argue that it's ok to ignore best practices such as using member access specifyers, which actually get the compiler to validate the code, if you stick with naming conventions, but arguing that it's technically possible to circumvent compiler checks under some specific circumstances is an absurd statement. Think about it: if you feel that enforcing a coding style is enough to enforce private member access then don't you agree that the same code review that is supposed to enforce your personal style can quite easily catch your hypothetical casts?

> I started doing everything all-public ala python (struct instead of class by default) with occasionally an m_ prefix for "intended to be private", and I've never looked back.

This is the sort of accidental complexity that access specifiers eliminated, but somehow you managed to reintroduce by trying to reinvent the wheel.

The 'm_' prefix only means "private member variable, don'access it" to you and you alone, and anyone who will stumble on your code will not be aware or obligated to follow your personal style. That would not be the case.if you simply used a basic feature of C++ that's been available since the time of "C with classes".

To me, you're the epitome of the main source of C++'s problems: programmers who failed to learn the basics of a language and instead decided to develop convoluted hacks to circumvent proper use of the language because they believe their new discovery is clever although in reality they only managed to needlessly add complexity to a code base while adding brittle and bug-prone code.

What else? Do away with memory deallocation because there's nothing of the sort in Python and your C++ code is packed with segfaults?

And by the way, the pimpl pattern is used to provide libraries a stable ABI in spite of what change might be done to the implementation. It is not a fad or a clever-looking trick.

> I don't understand why you have been downvoted for asking "why m_?".

Because complaining about coding conventions on a discussion about a design pattern is noise and adds nothing to the discussion.

The alledged political motivations of the prossecutors is very much irrelevant as

a) Lula was in fact guilty of operating an extensive criminal organization that transcended his party (in fact the interim president was also caught and is currently jailed)

b) Lula and his minions quite overtly stated that if they were elected they would abuse political immunity to avoid payung for their crimes and also abuse presidential pardons left and right to ensure every single member of their criminal organization would pay for theie crimes.

Therefore any concern with Lula and his minions winning the election has more to do with not wanting the criminals they were prossecuting to get off due to political trickery.

> On the other hand, I don't think it's reasonable to assume every build system will immediately support every compiler/IDE.

If your API is stable, why wouldn't it be reasonable to expect that it should work out of the box?