For some people's beliefs and values, whataboutism is all they've got to offer.

Well, that and projecting.

The even shout "aieeeeee!" when some something scares them.

Yeah, I think they forgot to include "stupid" in the long list of his faults.

I'm even seeing tiny firmware moving to Rust.

An awful lot of firmware moved over to C++ yonks ago, too before Rust was on the cards. There have been a few hold outs where reasonable C++ compilers didn't exist, usually on platforms so small you really can write it in C or even ASM without that much penalty.

Last time I wrote C in anger was on some 8051 base bluetooth controller years ago. The compiler was IAR Embedded C/C++ 9 I think (2010 ish?). Eventually after trying to write C++ I kept bumping into so many missing things I gave up trying to figure out what passed for C++ in their minds an wrote C instead.

Still, no allocation, some basic logic and a few FIR filters. It was fine.

> disagree that is precisely the same question as "the script at dfgjkdf.bit.ly would like to save a file, allow?" as far as the ordinary user is concerned. They have no idea if it is a good idea to allow that or not and at the moment can't take the steps to even try to figure that out.

Again, everyone is missing the point here.

It's asking for permission. It's ASKING for permission. Each and every security problem it's asking for permission.

Do you have any idea how annoying that is? Have you ever dealt with an irate marketing idiot who is furious that Firefox or Chrome is asking for permission to open a pop-up window that THEY WANT UP NO QUESTIONS ASKED NO USER INTERVENTION REQUIRED? Have you ever dealt with one that is furious a video won't autoplay and the user has to click on the video to make it play?

THEY hate that shit.

Ever wondered why every marketing website that pushes notifications now has a JS dialog on it that asks you if you want to enable notifications, when there's one built into Firefox and Chrome? It's because the marketing people want to keep asking you. If you say No, they'll ask you next time. Whereas if you say no to the one built into Firefox and Chrome, they can't ask you any more.

But that's one of the rare occasions the permissions system is working.

Basically, the status quo is: you go to bad website. Owned.

The way it should work: you go to bad website. DO you want to allow this website to track you across multiple websites? Yes/No. Do you want this website to show notifications? Do you want this website to save files on your computer? Yes/No.

By the time they've exhausted every possible way to screw you over, you've closed the window because no fucking article on how to make money buying gold is worth that amount of work. Just like people now do every day when they get a cookie banner followed by a subscription email pop up followed by a sure you want to click that close button followed by a special offer pay $1 for one month followed by a... and can't get to the content.

I cannot believe people here are ignoring how dialogs like this can deter users from browsing a shitty website, and as a result from marketing predators from forcing programmers to make them.

It's so fucking obvious, yet I'm actually being modded down over it.

All of them? How do you know?

> Asking for permissions at this point would be like a Toyota Corolla popping up a dialog on the dash board "Would you like to advance timing by 1.5 degrees?" while the driver is cruising along I-70. The percentage of drivers who could think about the question intelligently is small, the number of them familiar enough the current state of that specific car in terms of tune, conditions, etc without doing additional analysis no practical while operating is even smaller.

I wouldn't put "Do you want this website to be able to access the files on your computer?" (or "Do you want this website to store information that lets the website track you when you visit other websites?") in the same category as a technical engine tuning issue, no.

Also notice that if the car did that you'd think there was something weird going on. Which is exactly the same situation as you should feel when a dialog comes up from your web browser. It's fine for the web browser to automatically accept same domain session cookies. It's not fine for the web browser to just give random websites access to the file system or allow them to set permanent cookies that can be read from multiple domains.

> The problem is that is how the SaaS, Ad, CDN, Surveillance capital, guys want it!

Ironically they, for the most part, don't want the API under discussion. The people who want this API are you and I, people who do not want our data in the cloud,. They want our data in their clouds. What they do want is tracking, and you'll notice that no dialogs currently pop up every time a website sets an overly privileged cookie. We don't get the dialogs because might say no, not because we might not understand them.

Your point being what exactly?

So a desktop might be able to guess where I am. So what? Does that mean it should prompt me even when it only has an IP address to go on? (An IP address that according to every website I go to locates me literally 100 miles South of where I am?) And why does that mean I shouldn't be able to turn the requests off permanently given it's a dialog I will never say yes to?'

> re "location information" on a desktop PC, sure it's not a mobile device, but there is still a reason to geolocate it

You miss the point. Desktop PCs do not contain GPS devices. Therefore any "location" information browsers provide is generally inaccurate, often radically so. So they shouldn't even be offering the API unless they've actually given the user an interface to enter the position of the computer, and has given permission.

There are plenty of "nice to haves" that are both technically impossible on conventional desktop PCs and dangerous with privacy. You wouldn't expect the browser to give websites the ages of users (for the same reasons you say location information is useful) either, and for the exact same reasons: privacy, and while it can make an educated guess, it doesn't actually know.

> "why not just force them to ask permission?" - look at the experience you get if you turn on "prompt every time a cookie is set".

Are you just anti-privacy at this point? Because I literally explained this (literally the last sentence of my post), and you're acting as if I didn't which makes me think you don't think the problem with too many requests is that someone violating a victim's privacy is with the privacy violations.

Do you work for Facebook or something?

It is very typical of an American to pick the worst instance of anything they can find in order to prove they're better than the very worst thing you can find! Good for you!

Meanwhile you have roads that are more dangerous than anything in Western Europe. I look forward to your excuses as to why this is the case.

Do you claim to write no bugs?

Unfortunately not.

All programmes write bugs, not all programmes believe they do.

The OP was giving you facts.

In other domains when performs keep happening, the solution is process improvements, to mitigate the fallibility of humans.

Programming isn't special here and neither are programmes. We don't yell at pilots that they suck, we now have extensive process improvements and planes are pretty safe. In much of Europe, if a road is dangerous, we generally try and fix the road to be less safe, not the road users which is why much of Europe has much safer roads than America which does not fix the process.

Etc and so on and so forth.

It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.

Broadly speaking, no this isn't correct.

From a very narrow perspective there's some truth: C is Turing complete so you can do anything in it you can do in another language. But that's also an argument in favour of writing the kernel brainfuck, Malboge or if you prefer a language designed with a purpose outside of esoterica, sed.

From a slightly wider perspective C is a "proper" language, not an esolang, (or a DSL with an accidental Turing tarpit), so it's not quite so horrible.

But otherwise, no, not really.

All code has bugs. C lacks basically any kind of automation to relieve the programmer of the burden of doing stuff by hand.

I like watching Eoin Reardon hew an oak log into a beam with an adze and hatchet to keep the old ways alive, and do period restorations of old properties. But for building at scale and for performance, a bandsaw, or heck stressed concrete does a heck of a more efficient and consistent job. Would you build a house with all traditional hand tool woodworking today? Clearly yes for some people, but would you personally want to live in a house of that size and expense?

Beautifully crafted C code is quite fun. But it's error prone, and needs a ton of effort and skill and also effort to make it good. OpenBSD manage, with strict rules and repeated code re-reviews. The result is secure C code, but it does a lot less than Linux (kernel wise). SEL4 managed even more, with correct C code (a step beyond what Rust can do entering into Ada/SPARK levels) but they had to do new maths to get that to work and it does less than OpenBSD.

But beautifully crafted C code doesn't scale and that's why the kernel has bugs. The choice is to either do less or to automate away as many bug checks and repetitive code as can be automated away. C++ does a lot, Rust does more, Ada/SPARK does even more. I personally think they'd have been wise picking C++ 20 years, but today, especially since the kernel is heavy on the irregular threading, Rust is probably a better choice here. Not enough people know Ada/SPARK and it ain't fashionable enough :)

What C can't do is much by the way of automated code generation or automated checking for potential bugs. The kernel developers have finally decided that those are good ideas. Torvalds has mellowed in the last 30 years and AI tools have made bugs more visible. C isn't up to the task they are trying to achieve any more (one may argue it hasn't been for a while).

This choice is not unique to Linux. Few of the large scale open source projects are C anymore. Linux is going rusty. GCC moved to C++, LLVM/Clang started as C++, KDE is in C++, Firefox is in Rust and C++, Chrome in C++, Blender in C++, KiCAD is, FreeCAD (especially the OpenCASCADE kernel), kdenlive is in C++, LibeOffice and so on. I can't remember the last time I encountered a commercial project in C other than tiny firmware.

You can still make smaller stuff effectively in C, but making big projects in it exacerbates all the problems it provides no assistance in solving.

Your's aren't either.

You're the one trying to "debunk" my arguments with opinions-as-facts.

But mine are at least rooted in observations and logic.

They're not though. You keep making claims about what will "obviously" happen except in related cases it hasn't. It's not an opinion that the welfare state will not be quickly forced down to starvation levels: this we can observe.

I'm actually baffled that you felt UBI and labor pool linkage was only an opinion, for example.

Hmm baffled about something that isn't actually true! Interesting! All you did was state one opinion, which I disagreed with, but that's the only thing I wrote about in that case, because I've got finite time to type long replies.

There are forces that pull the labour pool in different directions, but you're ignoring half of them. That's why it's not obvious to me that UBI simply means less work done, vs the existing benefits system.

Florida

Yeah florida isn't the world, it's also a basket case and subject to some unusual pressures.

Please discuss this in good faith. [etc]

Piss off. Me not accepting your opinions as gospel truth isn't bad faith. You whining and insulting when I tell you that means you're not someone worth discussing any further with. I'm going to stop reading here.