> I dunno why nobody used things like external includes in XML
In practice they led to fairly severe security vulnerabilities. "XXE" used to be an OWASP Web Top 10 issue, and the reason it dropped off the list was because XML mostly went away, not because it stopped being a thing.
> But at least, I think XML doesn't have macro expansions, so that's a win.
Even there, they made a lot of money before they went bust. Like if you want an example you'd be better of picking Therac-25, as ancient an example as it is.
100,000 votes (and really probably closer to 150,000 influenceable votes across those households) is a significant number compared to 10 companies who own an average of 10,000 properties each, yes.
Companies with tremendous wealth manipulate voters and lobby their representatives. Don’t presume that voters are remotely well-informed of who backs their interests.
Yeah, before we picked up YNAB more than a decade ago we never had issues with $3k of candles disappearing in the budget, but we still struggled to save money.
When we started using YNAB and entering our spending into it, it was like a hockey-stick diagram on our household net worth.
And this isn't even double-entry accounting (which I've adopted for my own personal spending). One thing I'll say is that the way we use YNAB seems different from most other people: we hand-enter every transaction, we don't import it afterwards from the bank. Then we reconcile what we thought we spent vs. what the bank says we spent.
In this way we have to be a bit more intentional about what we're spending money on since there's not some kind of big monthly exercise to make the numbers line up and then a "we'll try to be better next month". Instead it's more like an envelope system where we are tracking budget categories as the month goes by.
I used to use YNAB and I think this was its whole point: you allocate money in different envelopes (budgets) and as the month goes by, you enter your transactions and see how your envelopes deplete.
I didn't actually do this that much, I was much more interested in where my money was going over longer periods (say a year). It was nice enough, but I dropped it a few years ago when they had big price increase and became more expensive than it was worth to me.
Yeah, I'll probably switch to Actual at some point in the next couple of years as a result of the price change. The YNAB team at least continues to strive to make improvements to the core app so they seem to be actually putting the money to use, but the improvements are not in directions I need. And the improvement I do need, to make their web site faster for 10 years of budget, seems perenially on the back burner.
I absolutely prefer my Ioniq 5 over a Tesla, not merely 'tolerate it'.
Tesla has everyone else beat on charging infrastructure, that is true, but I don't need that except for about 0.5% of the miles I drive (and even there, Tesla's competitors exist and are fine on the routes I'd take).
A lot more manual controls, in particular. I've never liked needing to use a touchscreen to manage functions of the car I might need to use while driving. Ioniq could actually go further still, some of the physical interface still uses a capacitive button rather than a physical button, but it is at least single-function so I can trace my hand along the bottom and the button I want is always in the same spot.
I like that by default it is set to two-pedal drive, especially in case I end up having to use an ICE or hybrid car (or have other drivers use my Ioniq). I like that I have a key fob and there's a physical interaction I need to make to turn the car on. I like that it supports Android Auto.
I think the styling is much better. I haven't sat in a Tesla long enough to give a direct comparison but the Ioniq interior is in the top quarter of cars I've driven.
It's not all roses, there's been Ioniq drivers run into ICCU issues that you don't really see the equivalent of with Tesla, but if I run into that then I'll just take it as a warranty item.
Edit: I forgot about the turn signal stalks but that was a primary thing for me as well, I literally thought it was some kind of anti-Tesla meme at first that they didn't have normal turn signals, until I verified it for myself.
> rust, you were meant to replace c++, not join it...
Turns out that not all of the C++ noise people make fun of is due to C++, sometimes the problems you want to solve with Rust or C++ is just hard to express simply to the compiler.
If the net inflow of talented coworkers to the company with churn (including hi-po churn) still exceeds the level of talent you'd get at the company with stagnant workforce levels, then maybe you'd still find it preferable.
High churn doesn't necessarily mean low average talent, especially if the skills you need to be a high-performer are not specific to any one company.
Fractional time shouldn't be an issue as long as the ratio is a rational number. It's how durations are already handled behind the scenes.
Likewise it's annoying to cook up your own type, but as long as you can come up with 'number of ticks' type that acts like an arithmetic type then it should work with std::chrono. E.g. if I just Boost's Multiprecision library as a quick example:
#include <chrono>
#include <iostream>
#include <boost/multiprecision/cpp_int.hpp>
using namespace std::chrono_literals;
int main()
{
using BigInt = boost::multiprecision::uint128_t;
using BigNanos = std::chrono::duration<BigInt, std::nano>;
std::cout << "Count for 1s: " << BigNanos(1s).count() << "\n";
std::cout << "Count for 300 years: " << BigNanos(std::chrono::years(300)).count() << "\n";
}
Then that code (when compiled with -std=c++20 or better) should output:
Count for 10s: 1000000000
Count for 300 years: 9467085600000000000
If you're willing to use gcc/clang builtins for 128-bit types you won't even need Boost or your own custom type to do basic arithmetic (but serializing the result may be difficult, not sure how gcc/clang handle that for custom 128-bit types).
std::chrono counts the number of ticks of a given periodicity. The periodicity does have to be a known compile-time ratio expressible as a fraction of seconds, but you can use a floating-type type to count the number of ticks.
std::chrono is meant to take advantage of information about periodicity at compile time, but if you want to count in terms of a dynamic periodicity not known until runtime, you can still do things. E.g. use time_t and some wrapper functions, or just pick one (or several) std::chrono base durations such as standardizing on nanoseconds, and then just count floating-point ticks.
> The periodicity does have to be a known compile-time ratio expressible as a fraction of seconds
Right, that's the problem I'm describing.
> or just pick one (or several) std::chrono base durations such as standardizing on nanoseconds, and then just count floating-point ticks.
None of this really fits well -- the idea is to count in integer ticks (invariant cycles), without doing expensive division or floating point math. It's like steady clock, but in ticks instead of nanos.
But on any modern CPU, clock speed won't be constant. It's not compile time constant, nor a runtime constant. Its variable over time. You'd have to record the clock speed over time and the ticks, so why not just record actual time?
The CPU clock varies, but all modern CPUs have some counter that is incremented at a constant frequency, like the Time Stamp Counter (TSC) on Intel/AMD CPUs.
When discussing hardware clock ticks used for time measurement, the ticks from TSC or similar counters are meant and not ticks from some counter that counts cycles of the CPU clock, like provided by the performance counters.
The variable CPU clock frequency can be measured by computing the ratio between the ticks accumulated by the corresponding performance counter and the ticks accumulated by the TSC (or similar counter), for which the clock frequency is constant and known.
In practice they led to fairly severe security vulnerabilities. "XXE" used to be an OWASP Web Top 10 issue, and the reason it dropped off the list was because XML mostly went away, not because it stopped being a thing.
> But at least, I think XML doesn't have macro expansions, so that's a win.
XML, like HTML, has entities that can be expanded. Unlike HTML you can define them in XML and this led to the "Billion laughs attack": https://en.wikipedia.org/wiki/Billion_laughs_attack
reply