You won’t know if you’ll get a 404 until you make a network request. How many of those can you make per second? Hundreds? Thousands? Let’s be very generous and say millions.
That means you just need millions of years to go through the entire range.
Not quite. We are saying that adding `not_available_before: 2026`, or similar, ‘right away’ is usually not a good thing; therefore anything that helps with doing that is not something we desire.
It should be a multistep process. Yes, it will waste time now, but it will save it in a long run.
I mean, sometime along the way you’re going to have something that consumes the data (otherwise, why bother keeping it in the first place), and that something will have certain expectations about the way things are structured.
It will probably become a good idea then to have some clue as to what structure used to be at one point or the other, and for that you’d want to keep track as to what got added/removed and when.
If it’s a very early stage in the development, and you don’t expect any of the current data to survive to the final version, I guess that’s fine. But when you have an actual running product that has to keep running, dealing with the multiple versions of the data scheme is a pain, and dealing with the multiple untracked versions of the data scheme is a pain squared.
It still does the same thing, but now in a non-general, distro-specific way. Hundreds of distributions customize their software like that: for example, I believe it is actually more common to find gnome-terminal with patched-in transparency than the vanilla one without it.
I agree, but still think it might be considered reasonable not to want to rebrand in some cases—like patching Cargo to try and check with the package manager first when installing packages. It obviously won’t (and shouldn’t) get accepted mainstream, but it doesn’t also seem confusing enough to warrant a necessarily different name.
Unfortunatelly, neither. Main problem with his surname is the ‘ś’ (proper spelling is ‘Kościuszko’), which doesn’t appear in English at all. The closest equivalent I can think of is Japanese sound at the beginning of words such as ‘shinobi’, which I guess English-speaking people still pronounce like ‘sh’ in ‘fish’…
And then there’s ‘ci’, which is pronounced similar to ‘s’…
The closest I can get is ‘Koshch-oosh-kuh’, but that’s still not it (that would be spelled ‘Koszczuszko’).
> Yeah, so like the other poster your point reduces to "I trust Fedora to build Mozilla code more than I trust Mozilla to build Mozilla code". Which is nonsensical.
I don’t think it is. That way, you have two authorities checking things over instead of just one.
I don’t think restricting the changes to default settings is enough, you can still do quite a lot of malicious or just plain annoying things with that—for example, I didn’t change the default browser theme, but that doesn’t mean that I wouldn’t be pissed if it changed to an advertisement of any sort.
It gives the developers a great power—they can change applications behaviour outside typical venues for this. Most users expect an update to change things, but if my browser would start to behave erratically and I knew I haven’t updated it for a while, it would have send me on a wild goose chase for other things that I might have done that make my Firefox crash or whatever. It wouldn’t have occurred to me that some change to my settings was pushed without my knowledge.
We can only hope FF devs will use that power responsibly. It can be a nice feature or a complete nightmare. And I for one would very much welcome some kind of pushed notification about that (‘hey, there was a problem with this and that, so we changed that and this; here’s how you can revert the change if needed’).
The one that is remotely done for you, without any action on your part.
Typically, a user has to click the installer or use package manager or something to get the update, it’s their decision they make locally. If a setting is in place where this decision can be made somewhere else, it’s now a remote thing, a remote update. Quite useful thing in some cases and one of the things that make SaaS possible in the first place.
Changing a default setting _remotely_. That is a huge field of possibilities, from not SaaS-y at all to very SaaS-y.
Like for example you could make it so the script to be run when a browser encounters a pdf file is put directly in the settings. Thus changing that setting changes what the browser does—you can add, remove or change an in-browser pdf viewer that way.
It’s not what Normandy currently does, but it is something it’s at least theoretically capable of. And hitting that extreme would, in my opinion, made it reasonable to start calling it SaaS.
Yes, sort of. The change is made to _default_ configs, so if you changed something, it won’t touch it. And while I get that changes to that can be annoying, I also find them necessary to keep the application easy to use and productive and cannot think of any piece of software that never have changed their defaults.
The reason for Normandy to exist is to allow the developers to check if some change to that defaults is production ready yet. For example, you can start enabling by default hardware video acceleration for some people and compare the number of browser crashes they experience compared to the general public and use that knowledge to know when this feature is stable enough to be enabled for all.
> Then you're not disagreeing with me, because those functions pass my test as I demonstrated above.
Yeah. I must have misunderstood your definition of ‘obvious’—I though you meant ‘an obvious inclusion to the standard library’, not ‘having an obvious definition’. The definition is obvious, why they should be in a standard library is not.
> […] since by your own admission you don't even know what they are
I mostly do—I studied mathematics. Or, to be more precise, I learned about them, then never used them in programming, had to remind myself what they were and even after that, I don’t find them useful enough to warrant an inclusion to the standard library. Thus, since they were included, I think that’s a good evidence of C++ committee not trying to keep its standard library concise.
> You named some other features, such as quaternions, that you think would be better for implementors to spend their time on, but surely you can imagine someone like yourself who is tired of having to define the Bessel functions every time they start a new project, and can't imagine why the C++ committee saw fit to include something so useless and obscure as quaternions before getting to Bessel functions.
The thing is, I can’t. If you use them, you want a better support for solving differential equations than C++ offers anyway, so it’s more of a ‘OK, I have this small part already implemented, but I still have to find ways of doing the rest 95%’. This, plus the fact that I’m quite certain that people using C++ to do 3D geometry outnumber people using it for solving differential equations by a few orders of magnitude—a cursory glance at GitHub showed me that the only projects in C++ that mention it are… implementations of a standard library (and forks upon forks of those).
My problems with this is that C++ is now in a very strange place—it implements some very high level, niche features, bloating the language and its implementations (the size of glibc is a practical problem) while still lacking many others, that seem much more ‘obvious’ (i.e. ‘if given an unknown language, I would be much less surprised to find them included in its standard library). In the end, I have a language that both has annoyingly big standard library and heavily relies on other, non-standard ones for quite a lot of things.
There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those.
If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could potentially think of to implement, there are hundreds of things that are orders of magnitude more useful to have and equally well-defined and standardized—even if we limit ourselves to mathematics alone, I’d much rather see basic constants like π or e included, or quaternions, or arbitrary precision integers, or decimal numbers… or dozens upon dozens of other things before that.
But mainly, I find it impossible to maintain the claim that any general-usage language, like C++, that implements such niche functions is trying to keep its standard library small and ‘include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics’.
> include only elements that have a somewhat settled, "obvious", lowest-common-denominator semantics
Can you, from the top of your head, tell me what irregular modified cylindrical Bessel functions are and the last time you needed to use one? And yet, they were included in the standard library in C++17: https://en.cppreference.com/w/cpp/numeric/special_math/cyl_b...
Corporations aren’t people, thus are incapable of making any decisions. People run corporations and these people make decisions. And they make them, as most of us do, with their own interest in mind first.
> Obviously, but that's because businesses act unethically -- ie, for private profit over public good.
I don’t find that unethical. What’s more, I do it all the time—for example, right now I’m watching Netflix instead of doing any kind of public service. I have two kidneys, but only really need one. I use my money to buy stuff for my own usage, instead of donating it all after I fulfil my basic needs.
And if I happened to run a business, I would do the very same thing. So I don’t think it’s my place to be calling people out on things that I do too. Doing things for the community should be held in a very high regard. But being legally forced to do that seems really inappropriate to me.
That means you just need millions of years to go through the entire range.