Sandford Fleming (the guy who invented time zones) actually made it easier.

Before timezones, every town had their own clock that defined the time for their town and was loosely set such that “noon is when the sun is at its highest point in the sky.” Which couldn’t be measured all that accurately.

If it wasn’t for Fleming, we’d be dealing with every city or town having a separate time zone.

I think I have you slightly beat… mine was an Apple II+, circa late 1981, with a disk drive, and a monochrome green screen monitor.

First cell phone was around 1997. Though I honestly don’t remember what it was. I recall having a Nokia model from before they made that indestructible model in all the memes, as well as a Kyocera one that I could connect to a laptop and have wireless dial up internet at some abysmal speed like 20 kbps. (0.02 mbps). I had at least two more phones, including a Treo 650 “smartphone” before getting my first iPhone, a 3G. I’m on my sixth iPhone now.

I question the methodology here. The same site lists Linux desktop share at 2% in my country specifically. It feels like if it was that high you’d see it on people’s laptops more in coffee shops and what not… but I’ve yet to see a single other person using Linux on the desktop.

I know most of that 4% is in India… but still feels like it should be more ubiquitous if the number is that high.

If a website using home realm discovery adds anything more than one extra press of the enter key or mouse click of an ‘ok’ button, get a better password manager.

If you’re annoyed by that one extra click that’s fair. Click counts matter.

It’s called home realm discovery. It’s common in business apps though it’s usually used with email & password logins not username & password logins.

It’s done that way to support federated logins. Larger companies will often used a single sign on solution like Okta or Azure AD. Once the user’s email address is entered it checks the domain against a list of sign on providers for each domain and redirects the user to their company’s federated login if it finds it there instead of prompting for a password.

This has several benefits:

1. The user doesn’t have mutiple passwords to remember for different apps. Which is know to result in users either reusing passwords or writing down passwords somewhere.

2. When an employee quits or is terminated the company only needs to disable their account in their company directory and not go into potential dozens of separate web apps to disable accounts.

3. The software vendor never receives the password, if the vendor’s system is compromised they don’t even have password hashes to leak. (Let alone plain text or reversibly encrypted passwords)

Websites that work that way are (usually) doing it right. If that doesn’t work with your password manager, you should (probably) blame the password manager not the website.

That’s surprising accurate for many developers.

And you’re forgetting that about 1% of the population is pregnant at any given time and has another whole human inside of them.

Lived in a house that had a heat pump with resistive electric heat as a backup in Canada. Never noticed a significant difference between that and other houses I’ve lived in that had natural gas furnaces.

Aux heat would kick whenever it was below about -5°C. That house would be about 20 years old now and had decent insulation for the location and age. It never really felt like the furnace struggled to keep the house warm, or was running all the time.

Cost wise it didn’t seem significantly better or worse than natural gas. It was definitely using more juice in the winter when there was a cold snap, but it wasn’t crazy amounts. The electric bill was actually highest in the summer when the heat pump was cooling.

I will absolutely give you that transitioning an established mature product to the subscription model is usually a terrible idea. Plenty of examples of that going horribly wrong.

As for subscriptions being a “blatant money grab” that definitely happens sometimes… notably when there’s a mature product with a dominating market share. The company already captured most of the market share, so they can’t get much more revenue from new customers, existing customers are satisfied with the version they have so they’re not buying any updates. Sales go down and someone comes along say just make it a subscription and keep milking the cash cow forever…. Yep, I admit it, that totally happens. The enshitification ensues.

But none of that’s the fault of the subscription model per se.

The same subscription model that becomes the incumbent’s downfall, is what creates a market opportunity for a new competitor.

A new competitor can coming in with a new product that was built with a subscription model from the start. The competitors product is cheap to try for a month, cheap to switch to with no big upfront costs. The newcomers can generally react much faster to customers needs than the incumbent. (Not because of the model, they can because they’re smaller)

Established software companies doing blatant money grabs happen all the time. Hell most of us are here using Lemmy because Spez attempted a blatant money grab on Reddit. Had nothing to do with the model.

Subscription model gets a lot of hate because greedy companies tried to use it as a blatant money grab exactly as you described. But it doesn’t have to be that way.

Subscription models make it easier for newcomers entering a space, which is good for consumers. It’s more compatible with agile development methodologies because you don’t need wait until you’ve bundled enough features together to market it as a new version worth upgrading to. It’s in your best interest to ship new features immediately as they’re developed.

It’s totally fair of you don’t like the model.

But the model itself isn’t the problem.

Shitty companies being greedy will always happen.

Totally fair if you don’t like the subscription model.

But I am genuinely curious what you think I’m making assumptions about.

Wow… lots of people in here bashing the subscription model, but let me point out it’s maybe not as bad as you think…

If you sell a product under a perpetual license model (I.e the one-time purchase model). Once you’ve sold the product, the manufacturer has almost no incentive to offering any support or updates to the product. At best it’s a marketing ploy, you offer support only to get word of mouth advertising of your product which is generally a losing proposition.

Since there’s little incentive to improve the experience for existing customers. Your main income comes from if you can increase your market share which generally means making products bloated often leading to a worse experience for everyone.

If the customer wants support, you need to sell them a support contract. If they want updates you have to make a new version and hope the customer sees enough additional value to be worth upgrading. Either way we’re back to a subscription model with more steps, more risk, and less upside than market expansion so it takes a backseat.

If you want to make a great product without some variation on a subscription. You need to invest heavily upfront in development (which most companies don’t have the capital to do, and investors generally won’t invest in unproven software)

From a product perspective, you don’t know if you’ve hit the mark until people start using your product. The first versions of anything but the most trivial of products is usually terrible, because no matter how good you are, half to three quarters of the ideas you build are going to be crap and not going to be what the customers need.

Perpetual licensing works for a small single purpose application with no expectation of support or updates.

It works for applications with broad market needs like office software.

For most niche applications, subscription models offer a better experience for both the customer and the manufacturer.

The customer isn’t facing a large transition cost to switch to a competitor’s product like they would if they had to buy a perpetual license of it, so you have a lot more incentive to support and improve your product. You also don’t see significant revenue if the customer that drops your service a couple months in… even more reason to focus on improving the product for existing customers.

People ought hate the idea of paying small reoccurring fees for software instead of a few big upfront costs. But from a business model perspective, businesses are way more incentivized to focus on making their products better for you under that model.

I concur with everything you’ve written here.

I concur that a left-to-right interpretation of consecutive explicit multiplication and division is wide spread and how most calculators and computers would interpret:

a / b * c.

But the sources you quote in your blog post and the style guides I’ve read, state that a fraction bar or parenthesis should be used to clarify if it should be interpreted as:

(a / b) * c

or

a / (b * c)

You make the argument in your post that:

a / bc

is ambiguous (which I agree with)

but

a / b * c

is not ambiguous. Which is the part I disagree with, and I think the sources you quoted disagree with you as well. But I’m open to being wrong about that and am interested if you have sources that prove otherwise.

If I’m understanding your response correctly, you believe that

a / b * c

is unambiguous, and always treated like

(a / b) * c

because of a wide spread convention of left-to-right interpretation (a convention that we both agree exists), not because you found a source that states that.

Anyhow… I’m not out to convince you of anything and I appreciate you taking the time to explain your thinking to me.

I would be particularly interested if you found something in a mathematical style guide that recommended an expression like

( a / b ) * c

Should be re-written as

a / b * c

Generally speaking, style guides advise rewriting equations for maximum clarity. Which usually includes a guideline of removing parentheses when their existence isn’t needed to clarify intent.

I believe, and I’m particularly interested to see if you found evidence that my understanding is incorrect, that the LTR convention used by calculators and computer programming languages today exists because a deterministic interpretation is a requirement or the hardware, not because any such convention existed prior to that or has been officially codified one way or the other by any mathematics bodies.

So like, forget division for a sec…

In a mathematics paper, you usually wouldn’t write:

(a + (b + c)) + d

You’d write:

a + b + c + d

(Except perhaps if in your paper the parentheses made it easier to follow how you got to that equation.)

Because in mathematics, it will never matter which order you do additions in, so you should drop the parentheses to improve clarity.

On a computer or a calculator though you might get a different result for those two equations like if a+b overflows your accumulator and c is a negative number, or when these are floating points values with significantly different magnitudes.

I believe english speaking engineers just adopted LTR as the convention for how to interpret it since they had to do something, and the english language is a LTR language. I don’t believe that convention exists outside of the context of computing.

The Wolfram quote and ISO quote in particular that you have in your post imply that an inline division followed by an explicit multiplication is ambiguous as to if it should be interpreted as a compound fraction.

If that’s correct, then it would be the inline division that makes it ambiguous, not the implicit multiplication that makes it ambiguous.

If there’s some source from before computers, or outside of the context of computers forcing a decision. Then your assertion that it is the implicit multiplication causes the ambiguity is correct.

I’m not trying to prove you’re wrong, I’m just genuinely curious which it is. And if you found evidence one way or the other.

My apologies, I wasn’t trying to spar with you friend, just trying to understand why a/b*c wouldn’t also be considered ambiguous, particularly since an author could have written a*c/b and removed any doubt.

In your blog post you also quoted ISO

In such a combination, a solidus (/) shall not be followed by a multiplication sign or a division sign on the same line unless parentheses are inserted to avoid any ambiguity.

You seemed to speak rather definitively that it’s only ambiguous when combined with implicit multiplication.

I agree that almost all calculators and programming languages will interpret consecutive explicit multiplications and divisions with left-to-right precedence.

But as far as I’m aware no such LTR rule has global agreement in mathematics, I was curious if you found something in your research that says otherwise.

Will you accept wolfram alpha as credible source?

https://mathworld.wolfram.com/Solidus.html

Special care is needed when interpreting the meaning of a solidus in in-line math because of the notational ambiguity in expressions such as a/bc. Whereas in many textbooks, “a/bc” is intended to denote a/(bc), taken literally or evaluated in a symbolic mathematics languages such as the Wolfram Language, it means (a/b)×c. For clarity, parentheses should therefore always be used when delineating compound denominators.

What is your source for the priority of the / operator?

i.e. why do you say 6 / 2 * 3 is unambiguous?

Every source I’ve seen states that multiplication and division are equal priority operations. And one should clarify, either with a fraction bar (preferably) or parentheses if the order would make a difference.

You state that the ambiguity comes from the implicit multiplication and not the use of the obelus.

I.e. That 6 ÷ 2 x 3 is not ambiguous

What is your source for your statement that there is an accepted convention for the priority of the iinline obelus or solidus symbol?

As far as I’m aware, every style guide states that a fraction bar (preferably) or parentheses should be used to resolve the ambiguity when there are additional operators to the right of a solidus, and that an obelus should never be used.

Which therefore would make it the division expressed with an obelus that creates the ambiguity, and not the implicit multiplication.

(Rest of the post is great)

I’m genuinely not sure which side you think is which.

Or something like it controls the lights in the elevator cab (but not the elevator itself).

Total monthly posts exploded after Spez enshitified Reddit, and is still growing steadily month over month.

That suggests that the current decline in monthly active users is primarily because lurkers who only came to lemmy after initially hearing about it on Reddit, went back to lurking Reddit.

The number of users that are contributors is still growing, and that’s what’s important.