HN user

karavelov

405 karma
Posts2
Comments130
View on HN

why not switch to bird that was not affected at all? not just acknowledged and fixed. isn’t it “safe be default” better than “fixed after they pointed the flaw”

The cost of the CPU is small part of a server TCO. Graviton instances could be cheaper because the platform is cheaper, uses less power and needs less cooling - I think we know from Apple Silicon that ARM chips can have these advantages.

Disclaimer: I work for AWS but I don't have any internal knowledge about Graviton pricing and non-public performance data.

I am a Linux user, and I gave on Thunderbird due to terrible Exchange support - now I use Evolution, it has its own problems but my calendar is synced.

P.S. No my choice to use Exchange on the server side.

It matters actually, if your each tasks use 10KiB stack for execution, and you have 1000 tasks, with threads that will consume 12MiB just for the stacks (+2KiB per task due to page alignment). If you use async runtime as Tokio the stack is un-rolled on each suspend point. So if you have 16 worker threads, that means the stacks will consume 192 KiB.

PerformanceTest software only runs on Windows OS

I think this excludes huge population of servers as we know Windows is not dominant there.

Pravetz Computers 5 years ago

Yes, this is how I learned programming Basic, assembly, Turbo Pascal (CP/M) and C on Pravetz 82M and 16. It was fun time. Some models of Pravetz 16 had a NEC CPU clone that was running substantially faster, if my memory serves me well 12 MHz vs 4 MHz for the Intel.

They were widely available in the education system and there were optional classes to learn programming.

Edit: I forgot the Pravetz 8D a friend had - they were available for purchase fro individuals. It had 4 channel audio synth and I programmed on it a drum-box for my teen rock band.

Naming fields is a small pain, the PITA is that JSON does not have native encoding for enum/variant/sum types. So now there are multiple ways to encode them: internally tagged, externally tagged, adjacently tagged, implicit/untagged. And JSON schema does not solve that at all: you can write schemas for all of them, but they do not convey the same information in the end languages even if they have all the type capabilities.

Type parameters are decided by the use of the type. The associated types are decided by the implementation of the type. Type params are input, associate type are output.

Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords.

There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end.

[1] https://github.com/thepowersgang/mrustc

[2] https://github.com/sapir/gcc-rust/tree/rust

[3] https://github.com/Rust-GCC/gccrs

[4] https://github.com/bjorn3/rustc_codegen_cranelift