isogon

Becomes a lot less interesting when you consider that there's no way to power such a camera for any meaningful period of time without a much larger battery (ignoring the issue of storage/transmission).

Repurposing flags not always well-motivated, but one legitimate reason to do this is the memory (and particularly cache) footprint.

Often flags are local to a particular object. If there are lots of such objects, you want each to take as little space as possible. You should check out the contortions linux devs go through to make struct page small [0]. This is important, because there is one such struct per page of physical memory. The memory use is a near-constant percentage of your total memory, and you wouldn't want it to be any larger than necessary.

Even when there are not a lot of these objects, in low-latency software it's important to hit the cache. Your program should always just be as compact in memory as possible.

Semantically flags are booleans (is proposition P true of this object). They are stored compactly as bitsets, often implicitly, say:

    #define FLAG_1 0x01
    #define FLAG_2 0x02
    /* ... */
    #define FLAG_8 0x80

   struct order {
       u32 qty;
       u16 id;
       u8  type;
       u8  flags;
   };

Another example of this is intrustive flagging, using, for example, the high or low bits of a pointer aligned to 2^n bytes. If you run out of bits there, not much you can do.

[0] https://github.com/torvalds/linux/blob/master/include/linux/...

There is certainly much variance between the firms, especially the sign-on IME. People I know have turned down HRT core dev for big tech because their offers were unimpressive.

I think an interesting target for comparison with big tech is Jane Street, since their culture and WLB are good, so the main QoL drawbacks of finance don't apply. A new grad will get ~300k at Jane Street, though probably not with this large a sign-on.

I cannot confirm this. ~300k is pay (excluding sign-on) fresh out of college at a big HFT -- sufficiently senior devs make 7 figures.

Noticed this just now. It is.

The idea is precisely that you want to avoid pinging main memory at all, which is possible (in the happy case) if you do things correctly with DDIO. Not everything is done in hardware where I am. I am wary of saying much because my employer frowns on it, and admittedly I work on the software more than the hardware, but DDIO is certainly important to us.

For low-latency strategies, AMD's lack of DDIO [0] makes it a non-starter. The memory latency is a big gap to close.

[0] https://www.intel.com/content/www/us/en/io/data-direct-i-o-t...

Right, and I disagree with that post in this sense: there is a social expectation of fitness for a purpose that cannot be disclaimed with a license.

Many projects under licenses providing no warranty are nevertheless of high quality and well-maintained. Making the category in question precise is difficult, but it includes log4j. Projects by organizations such as Apache and eminent individuals like Bellard or Valsorda fall in this category. There is therefore an expectation that if you are such a project, yet unwilling to hold yourself to that standard of quality, you should make it clear for your users. Using a license with a no-warranty clause does not achieve it because it is not a distinguishing factor. The license, of course, protects from legal liability and so on, but no one is talking about legal matters here -- only about whether we should be collectively unhappy with the log4j maintainers.

The reason for this unhappiness would not be that they aren't willing to donate more of their time, but that their stewardship of the project is poor. Vulnerabilities are found in FOSS all the time; this instance was special because the misfeature in question was an egregious inclusion in the first place. It appears to be not a case of lack of time for review, but a lack of sense to say, "no, interpreting strings after formatting is insane and will never be part of this library." Obviously, they are entitled to include whatever code they want in their project, but some code is incompatible with it being useful -- if they do not aim to clear that bar, they should make it clear, because others in their position do.

I would say that something like opening your README with "this is not a serious project, you should not use this in prod" would be reasonable. This warning needs to be front and center and explicit, not merely sating "we are unpaid volunteers" or similar. There is precedent for this. Yes, some ignore such warnings and complain -- as long as this verbiage creates a useful distinction, such people are wrong and we should ridicule them. This warning would stand in contrast with the great many projects which aim to be fit for a purpose in practice, such as Postgres, Linux, Blender, etc. Obviously, such projects are usually better funded than log4j -- making it clear that you're not funded well enough to dedicate much time to the project an important part of this warning's content.

To continue the workplace analogy, I would be the unreasonable one to complain if the company specifically warned that they were significantly more trigger-happy that the normal company hiring at-will.

There is social context to licenses.

My employment contract states that I am an at-will employee, so my boss could technically fire me because they didn't like my haircut. If they were to _actually_ do this, I would certainly be slighted by this, probably post about it publicly and forewarn others against working for them, although they would not have violated the letter of the contract nor my understanding of its literal meaning.

I think the thrust of the complaint is that the society doesn't sufficiently value privacy for its own sake.

In a different kind of society, websites of the sort that you describe would be unpopular, because users at large would place less value on the real-person guarantee than on the non-collection of their identifying information.

Closely related to this is the topic of end-to-end encryption. To withstand attacks that I expect will continue to be mounted on it, I think the society has to believe in privacy as a terminal good. The answer to the argument that "we could catch such and such criminals if we had key escrow" ought to be "yes, and not catching those criminals is a price we agree to pay, because privacy is just that valuable to us".

I think it's quite reasonable to compare defer and destructors, in that case.

Destructors probably cannot be usefully imported into C while preserving the simplicity of the language: then you'll want at least unique_ptr to manage your memory with destructors, then probably shared_ptr, and some ownership semantics as you pass those around, et cetera. In that sense, defer strikes a balance between simplicity and usefulness. However, there is still a comparison.

It does often gloss over the nuance. I ultimately try to estimate how bad I am at assessing the veracity of arguments concerning the topic at hand, which I think is most valuable.

For example, I read many conflicting predictions concerning the last US election, saw that I could not distinguish bad predictions from good ones, and concluded that I have to remain unconvinced. I was vindicated by it being a very tight race. This doesn't always happen.

On the other hand, I read the recent Texas filing [0] and found that I could confidently argue against it, and the best opposing arguments I could find did not convince me. To my SO, I confidently voiced the prediction that this lawsuit will fail, and articulated why the probability argument in the attached Cicchetti Declaration is misguided. This is arguably a very easy task, so this correct prediction does me little credit, but I think that's the point: even if I only become convinced of things which are obvious, it is important to not accidentally become convinced of things which are not obvious.

[0] https://www.supremecourt.gov/DocketPDF/22/22O155/163048/2020...

I think it is valuable to read a hundred convincingly-written arguments in favor of one point of view, become convinced, and then read a hundred opposing arguments and again become convinced. This maintains my awareness of the fact that I'm a terrible judge of veracity of arguments. Since I want to know what happens in the world, I must be exposed to arguments, so I think it's very important to be viscerally aware that I'm an idiot and should use a lot of care.

As for why I want to know what happens in the world and particularly where I live (i.e. North America), it is because those events affect me. If I were on an information diet, then I would probably miss, for example, the recent passing of S.386 [0] by the US Senate, which is intimately relevant to me as my long-term goal is to immigrate to the US.

[0] https://www.congress.gov/bill/116th-congress/senate-bill/386...

That's true. I should add /r/Sino to that list. I also subscribe to ChinaTalk, but I'm not sure how valuable a it is for really gauging what goes on in that part of the net. Unfortunately, I can't read Chinese, so I have to trust someone to translate and aggregate that content in the end.

I haven't tried anything outside of US, China (these two being the two major geopolitical players), and Russia (because I am from there and understand the language). I would love to expand that list, but my time is limited.

Another factor is that reading American commentary is entertaining because I live here and am immersed in the culture. The same goes for Russia. I haven't been able to make this work with China: there is a mass of cultural material that I'm not "in" on, so it feels much more like work.

My own experience is that it works quite well for a certain kind of person: on Reddit I was simultaneously subbed to /r/The_Donald, /r/politics, /r/ChapoTrapHouse, /r/Libertarian, etc (while those were still around). I'd also drop by voat occasionally to get my weekly sample of virulently antisemitic takes.

I think looking at extremes is the most realistic path. Purportedly balanced sources are dangerous because their bias is subtle; extreme sources typically have very clear bias that is easy to keep in mind as you. You can read many extreme sources and sort of take the intersection of what they show you to guess at some minimal amount of what must be really true.

In my view, the fact that a[b] is equivalent to *(a + b) in C and C++ (in most languages with arrays the latter notation is meaningless) is a sort of a neat coincidence which we shouldn't feel bound to in language design in general.

There are many reasons to depart from this idea in languages far removed pointer arithmetic. For example, Julia has 1-based indexing and I appreciate it for that when doing computational mathematics. It is closer to familiar notation: A[1][1] is the element of matrix A in row 1 and column 1. In a language with zero-based indexing, it is sometimes easier for me to allocate an extra row and column, wasting memory, than to shift indices and risk an inevitable off-by-one somewhere.

I think it's a trope because most people really don't need color printing, so that advice is appropriate for them.

I, for example, have only ever used my printer to print such things as tickets and documents which must be mailed for bureaucratic reasons. My hunch is that this describes many others too.

Dockerfiles are far simpler than the Nix language. Likewise, sure, FreeBSD had jails first (and for a long time!), but they are more difficult to set up.

Docker allowed reproducibility to be accomplished by a person who likes the idea of it, but will shelve it if it doesn't work within an evening. This describes me, for example. I think it took off for that reason.