I tried it on Firefox, but see it failed because it doesn't have WebGPU (on linux). Same thing on Chromium actually:
main.js:145 Myth browser startup failed Error: WebGPU adapter was not available.
at Module.initialize (foster-webgpu.js:400:9)
at async main.js:61:3
(anonymous) @ main.js:145
main.js:146 Error: WebGPU adapter was not available.
at Module.initialize (foster-webgpu.js:400:9)
at async main.js:61:3
I can give an example. My parents live in the UK, and their house was built in 1985. A couple of years ago the copper phone line had to be replaced as it had degraded somebow. The operator had to dig up and reinstall their driveway, brick pathway and garden. Now the operator is installing fibre to replace copper phone lines, so again they need to dig it up.
One days work for one house. Multiply that across an entire nation, and work out how much diesel is burned for that. Where they live you can't get cable (not very common in the UK), but if it was available I guess there would have been another digging day in the 90s.
Thanks for the excerpts! I was trying to understand the reasoning, which seem to just be in the 2nd excerpt:
- The rules of signed/unsigned are complicated and there is too much auto-conversion - does that mean languages that make this more explicit means this is fine? It just seems ideal to have stronger typing.
- It is mentioned that you can initialized an unsigned int to "-2" - but that presumably could also be fixed in the language.
I'm trying to separate out which is "don't do this in C/C++" and which is "don't do this in any language".
that argument (and many others) also round to essentially "implicit imprecise integer casting is surprising but we do it anyway" which is... perhaps the actual problem???
I've made lints for Go that simply disallow implicit number casting, and omfg the (real, occurring but unnoticed) bugs it found. those kinds of lints are trivial to build, you can just stop doing it. forcing visible casts made many of these problematic patterns extremely suspicious at a glance, catching issues at review time far more easily.
> I'm trying to separate out which is "don't do this in C/C++" and which is "don't do this in any language".
To achieve high performance, any language would need to implement integer addition with a single machine instruction like 'ADD'. Languages can achieve more intuitive behavior by adding an operand check before the 'ADD', or by using an 'ADC' instruction and checking the carry bit afterwards. But adding branch statements to every add operation would slow computation significantly. Clever languages/compilers might deduce certain invariants and variable ranges that enable it to remove some of these branches to help in certain special cases.
Evidently Rust has an optional "safe add" that adds the branches to check for overflow. So newer languages offer more explicit options. But the core issue is more fundamental than language-specific.
I still don't like having explicit conversions everywhere like in rust. Either you're not thinking too hard about it and the explicit conversions are not really doing anything for you, or you are, meaning you need to be reasoning about it every time and justifying why it can never fail and/or injecting error handling. I would be a much happier rust user if index/length types were are i64 and we relegated unsigned types to serialization almost exclusively. I have other gripes for unsigned types btw, those are just my complaints why explicit casts are not a panacea.
> In Python, this works correctly for negative values.
They’re both “broken” in different ways. Arguably C’s brokenness is more apparent and less useful but Python also has footguns: C uses truncated division for its “modulo” so the remainder has the sign of the dividend, Python uses floored division so the remainder has the sign of the divisor instead.
The wiki page for modulo has a pretty extensive page on the subject.
I say you want a pair of operations such that (a, b) = quotient_and_remainder(x, y) gives you a and b such that a * y + b = x
The Euclidean division and remainder work, the other division and remainder also work, and they're both identical for the positive integers so people who only think about the positive integers won't even notice there's a choice here. So I like that Rust provides both pairs, in the same way Rust provides both Wrapping<T> and Saturating<T> because maybe you mean wrapping overflow or maybe you mean saturating overflow and we should make you choose not just assume we know best.
> Python uses floored division so the remainder has the sign of the divisor instead
Serious question, how is that a footgun? In decades of software development I have never needed a negative divisor for modulo. What would you use it for?
But where do you get the checksum from? I realize in some cases you are downloading from a mirror (thus as long as you trust the source of the checksum, that is quite useful) - but if it is from the same host - then you are just comparing against the same webserver.
You raise a good point. This is why people sign the checksums. The signature confirms that authenticity of the checksums. That somewhat moves the goalpost, though, since it then depends on where you got the source's public key, but it is still a more secure practice overall. The advantage of having the public key is that you only need to get it once and you can check many downloads later.
It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.
Totally agree with one shotting GUI tools. I especially have liked it to create a single-file web app, and then open it with Chromium locally (no web server needed).
In my case, it built a tool for splitting sounds and a tool for defining hitboxes for a game. Tools made exactly for more workflow. Wild times.
Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production.
You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.
Plenty of package managers can install to an arbitrary directory like ~/.local. Each user, or even each project, can have its own rootfs full of software.
The only things I tend to have running at the system level are a kernel and init and maybe openssh.
How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.
I still don't understand the note that the companies can't decrypt the messages with e2e encryption. Isn't it as simple as a software update that says:
"If user = foo, then send the on device keys elsewhere"?
Or if those keys are part of a TPM, then a software update that just asks it to send in the decrypted messages?
Can judges not order this now, but can order decryption if the keys are stored centrally?
I wonder if for closed-source apps if governments can not just force the key collection the same way they would force decryption with centralized keys.
That's an interesting take I don't see anyone else bringing up.
It would also, I would think, make it easier for the 30% fewer engineers to earn a better living in the long run and reduce human management effort.
This makes the most sense to me. So far AI, being fallible, can only augment humans so you can have less humans to do the same work (or tasks where accuracy can be less than 100%, like lower level support calls/questions). Next comes the task of re-balancing the distribution of labor or teaching other departments to utilize AI.
To me that rings the most true because where AI saves me the most time is in never having a bug that takes more than a few hours to pinpoint, even if I'm looking in the wrong place, because with enough clues the AI will look in the right place before I think of doing so. Like finding a needle in a haystack. It doesn't suddenly make me 100x more productive, but it saves a lot of time on some time consuming tasks.
The debugging improvements have been huge for me too. I was debugging some financial software, and while it took a few shots, just with access to my code and not to the database that showed the issue, it found a fairly complex problem.
This was my thinking. It's a tool with many options like digital spreadsheets. It can still be used 'wrong' or poorly, but you better know how to use it on some level.
The recent is very recent, so not much uptake yet (https://caniuse.com/webtransport) - but hopefully can be used without fallback to WebSockets in a couple years.
main.js:145 Myth browser startup failed Error: WebGPU adapter was not available. at Module.initialize (foster-webgpu.js:400:9) at async main.js:61:3 (anonymous) @ main.js:145 main.js:146 Error: WebGPU adapter was not available. at Module.initialize (foster-webgpu.js:400:9) at async main.js:61:3