they bring up a valid point: libreoffice is (in their opinion) harder to use and probably lower quality, so reports are harder to write and taking away time from more important things.
in my opinion libre office is absolutely good enough for this use case and thus not taking away significant time from other tasks. furthermore, the austrian armed forces are free to contribute to the project to improve the perceived paint points themselves.
on the other hand microsoft products are closed source and probably upload data to datacenters outside the customers (i.e. in this case, the militaries) sphere of influence. this may include the data (for storage and or AI training) and meta data (for advertising and telemetry).
microsoft may even silently introduce or reactivate (after they've been declined) those options after updates (don't quote me on this, but i think i remember this happening at least once).
microsoft apologists may argue that this is only the case for improperly configured corporate deployments, but as the software is closed source nobody can really be sure and if it's that hard to get right, it's a security problem in itself.
My point was rather that officers should have better things to do than feed the bureaucracy with reports no one will ever read, and so the harder you make it to write reports, the less likely they will do more of them!
this tool works by replacing the "general purpose" algorithm by specializing it, which made it less general purpose but simpler and more efficient ... and now there's the request to make it more general purpose.
(it's a joke! and the joke is that those are two different general purpose. but still.)
Language developers really do struggle with debugging our data-structures since they are often both circular and complex compared to many other applications, I wrote yet-another-UI tool for inspecting code back when I was doing my thesis work.
Maybe I should brush it off (and make it general... ), it would give you a source-code view and navigating the source-text you would be shown compiler nodes related to the lines/statements.
It was almost the only way to make sense of it since I was often generating multiple paths per statement (It was a lossy type-inference system so previous type branchings could lead to multiple subsequent code-paths through each statement and expression).
well, the chinese outsourced hog farms (pork production) to the U.S. because the farms are considered too toxic and environmentally destructive for them.
I'm talking about output. For sure, if I am reading this bool from FFI I want to have "not 0" be truthy. However if I am writing a bool to a FFI interface I want the value to be predictable (for example 1) rather than "some non-zero value".
Although this does open interesting cases where if you read a bool from one FFI interface and write to another it may have an unexpected value (ex 2). But I still think it is useful for the in-language conversions for example Boolean to LongBool and the True constant to have predictable values.
I presume this FFI goes in both directions; some APIs really want the value of a boolean to be 1 while others really want it to be "all 1s"/0xfff.../-1 because, internally, someone decided to do something silly and compare == or switch on TRUE.
The .Net runtime generates code that relies on bools being either 0 or 1. It's quite easy using interop to inadvertently set a bool to something else and this leads to very odd bugs where simple boolean expressions appear to be giving the wrong result.
(Tangentially, VB traditionally used -1 for true. VB.NET uses the same 0 or 1 internal representation for a bool as C# but if you convert a bool to a number in VB.NET it comes out as -1.)
-1 isn't even a bad choice, since that's basically using 0xFF for true and 0x00 for false. The weirdness is the fact that you're converting a binary value to a signed integer.
This goes all the way to early BASIC, and it's signed because the language didn't have any unsigned numbers to begin with.
The main reason for this particular arrangement is that, so long as you can rely on truth being represented as -1 - i.e. all bits set - bitwise operators double as logical ones. Thus BASIC would have NOT, AND, OR, XOR, IMP, EQV all operating bitwise but mostly used for Booleans in practice (it misses short-circuiting, but languages of that era rarely defaulted to it).
A lot of the time variables will be in registers. And registers are basically ints. That would be my guess for why many things are ints that could fit in less space.
on the one hand you have the owner dictating his political bias to all his employees/journalists. on the other hand you have a person/journalist interpreting reality through their own political bias. what's the difference? in the first case the medium would only report biased in one direction, in the second case it'd report roughly split around the percentages of the (journalistic) population, e.g. 60% this, 40% that.
> The reasoning was that more horses are needed to remove the manure, and these horses produce more manure.
i think that even then, that's not a problem, as one horse drawn cart can remove a lot more manure than it produces, i.e. a small number of extra horses can remove the excess manure of all horses and the overhead the extra horses introduce is mimimal.
If the footprint of the city is large enough, eventually transporting a cart of manure from the center to the edge consumes as many "manure-miles" as it produces. Though that is probably comically large, because as you say: a cart is a pretty big compared to its own horse's output.
You don't have to remove to the edge, you have to remove to the closest railway terminal or water port. No city could grow large without one or both of those.
I'd say the biggest difference is in the backend -- canine is built on top of kubernetes, which is what lets it leverage the rich ecosystem of tooling and packages. Kubernetes has a reputation for being difficult to use, and so Canine tries to be super opinionated, and follow a set of best practices.
I'd like to think at this point (about 2 years into development) we've gotten to a place where the end user doesn't even know they are using Kubernetes.
