HelloNurse

Being fast and being as easy to program as CUDA are two different things.

C++ is in the transitional phase where major bad things are being taken away very satisfactorily, usually by providing a simpler and more general replacement (for example, auto instead of long and pointless type declarations or modern initialization protecting against implicit conversions and surprise constructor overloads), but most progress of elegance and grace come from new features that enable something traditionally terrible or impossible (for example the gradual generalization of templates, culminating with concepts, the gradual extension of constexpr, consteval etc, and the new reflection).

Unable to be willing. The combination of not knowing any better, political parties and media that don't care or exert a contrary pressure because they belong to billionaires, and powerful health sector businesses appears to be very effective.

They don't consider the ORM the second class citizen it actually is: an optional simplified alternative to normal queries, that can be used for the easy cases.

One of the points is that, for a startup, not flailing around is very difficult and unlikely: these patterns of failure and "classic bullshit" are the universal norm. This piece "articulates a point of view or personality that you had never before considered": that you and your startup are no better than the characters in the tale, and equally doomed.

It can be accurately simulated with appropriate brushes and rags, water and soap, and a sufficient number of hands.

Considerable arrogance is required to think you can improve on mature products enough to conquer a large market share. Such arrogance should be supported by having, if not a demonstrably fantastic prototype, at least an obviously good idea; otherwise you are following the example of Juicero or Theranos.

In the article, the "smart" oven is only a speculation (maybe it works, and maybe someone will pay for it) and as such it is appropriate as a relatively low effort and low risk experiment on the part of an established oven maker (develop rudimentary automation and offer it as a very mildly disruptive feature at a modest price increase).

Brilliant autobiography.

On the contrary, the new trend of telling a bot to write code automates disregard for architecture.

  >  I've been thinking about the futsal effect - which is how Brazilian footballers developed superior skills through a constrained small-sided game with 5 on each side, then moving onto a full football game with 11 on each side. My understanding is the constraints are designed such that the most important and difficult skills are trained in a fast, immediate feedback loop.

This has nothing to do with iterations of the kind found in software development, which are about products and external constraints, not about training for individual skill and collective coordination.

A contributor in good faith is going to accept criticism and resubmit an improved change: less files modified, more explanation, more focus, references to actual tickets and discussion with actual developers.

Is this a joke? Instead of using a formal aspect specification that people (and bots) can get wrong, like any other programming language, trust a bot to do the right thing spontaneously and implement an aspect oriented architecture without tools?

The flaw in the argument is postulating a subscription model for a product that a normal customer needs very sporadically. Even old-school selling of perpetual licenses and support fees would be inappropriate.

Instead, sell expensive one-off consultancy projects to help some company understand one specific code base, with the only long-term relationship of satisfied customers recommending you and calling you again for new projects.

The quoted code suggests that the wrong sizes aren't evident constants in code (there is a function to compute/retrieve them) and extra inspection during debugging is the most plausible way to detect them.

Hopefully this kind of bug is enough to teach the important of measuring, logging and testing to a naive optimist.

Judging from the initial portion of the anime Dragonball pivoted gradually from a loose adaptation of Journey to the West (with Goku as the protagonist among funny versions of traditional characters) to a more original and specific setting and plot (with Goku as the most important of many Saiyan and martial artists).

There is a lot of room to do exactly the same thing more efficiently, which doesn't count as different algorithms.

The "amazing" organizations seem amazingly evil.

Vocabulary please. A "codec" is software that CODes and DECodes multimedia content, while specs describe an encoded file or stream format (occasionally involving network protocols and other concerns).

In a normal standard development process experimental codecs come first, then those that have proved to work well, including having good enough performance, are described in the spec; after standardization there's very little room to "develop the algorithms" because nonconformant implementations would be useless.

Reverse engineering is limited to the abnormal case of having access to some codec but not to the standard that describes it.

Email domains of employee addresses aren't necessarily owned by the company. For example:

  - a startup with legacy personal email addresses from one or two universities
  - a spin-off sharing the email domain (and the whole IT infrastructure) of the parent company
  - cheapskates using six approved free email services

With a company-managed list of owned domains where real employees have their work email addresses (unrelated to website domains).

My experience with responsive breakpoints is that they require compromises and therefore it's hard to make a manager commit to them: everything must look perfect, and identical, on every different device that exists, and if it doesn't it's the designer's fault.

You need to distinguish the prevention of actual type errors during the execution of a Python program, which would require mutilating the Python language, and linting Python code to find proven or likely defects, which is merely fraught with complications (open world and closed world assumptions, expecting more or less adversarial behaviour from callers of a function, etc.) and necessarily dependent on adding optional type declarations.

The rhyming is good, making "Oldavista" a generic wordplay that is merely more obvious to find for German speakers, and the name is insignificant compared to the effort of reproducing the whole Altavista page.

Declaring types only where one wants to introduce a constraint would be nice, but unfortunately calls with obvious wrong types like "foo(5, {})" are a minority; in most cases types in a call depend on types of the calling function's parameters, and the type checker can only deduce unknown type from unconstrained type.

Moreover, the extremely dynamic execution and lack of compilation in Python means that determining in a lint step whether "there is no + operator for int and dictionary" is essentially impossible: if you find some __add__ or __radd__, you need to trust its declaration that it accepts certain types or not and hope it's still there at runtime; if you don't find it, it might exist at runtime when operator + is actually used.

A compiled and sufficiently static language, on the other hand, can inspect source code and libraries and reason about potentially infinite sets of definitions and prove that functions exist or don't exist.

Buying a router, as opposed to connecting whatever your Internet provider gives you, is a very high technical bar.

You need to know why you want to spend money, which implies evaluating features, needs and possibilities, virtually guaranteeing that the user learns that OS or firmware updates and OpenWRT exist and are important.

Even wilder:

SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges.

Forgetting that interactive SQL queries, and to an even greater degree the underlying databases, are applications.

Remember how the 0 and 255 bins poked slightly beyond the [0,1][0,1] range’s edges? In the standard approach, the range of representable values is actually [−0.5/255,255.5/255][−0.5/255,255.5/255], meaning the bins are spaced further apart than strictly needed for [0,1][0,1] inputs

This is of course silly: the "range of representable values" of floating point colour components is [0,1] independent of quantization and how an invalid input would be quantized is irrelevant.

Looking at the actual "big picture" there are 256 representable values and (taking into account gamma correction, arbitrary ranges other than [0,1], deliberately nonuniform quantization bins, and other plausible complications) their correspondence to 256 floating point values should be regarded as a generic lookup table, abandoning all hope of using elegant and cheap formulas and making it obvious than encoding and decoding differently is not an option.

[flagged]

Is there a written explanation of the "Flatpak Next" plan? What is it supposed to change, and what does it need from systemd?

The article contains only a vague half paragraph of architecture:

  > they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing. 

And what other speculated Flatpak features introduce other dependencies from systemd? Discussing whether unwanted dependencies can be made optional or eliminated requires technical details.

There is an easy way to take control: read the volatile variable only once.

  volatile int x = 5;
  ...
  int y=x;
  printf("%d in hex is 0x%x.\n", y, y);