The article says 2.6 gigabits/second which is 2,600,000,000 bits/second, 2,600,000,000b/s * 0.5s / 8 is 162,500,000 bytes, 162,500,000 / 1,000,000 is 162.5 megabytes
Right, thanks
Readit Newshtgb commented on World-first gigabit laser link between aircraft and geostationary satellite esa.int/Applications/Conn... · Posted by u/giuliomagnifico
Don't people think this is one tool that would greatly benefit from using the very fastest languages available? Where's the C++, Rust, maybe even FORTRAN version?
This is only the language for describing the volumes. That's not heavy, rather the importance is that you can express the ideas you want. The heavy lifting of rendering and computing how volumes interact etc is already implemented in native code.
htgb commented on Jujutsu worktrees are convenient (2024) shaddy.dev/notes/jj-workt... · Posted by u/nvader
In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main.
I personally find this annoying. I usually like to keep one pristine and always current working copy of main (and develop if applicable) around for search and other analysis tasks[1]. Worktrees would be ideal and efficient but due to the mentioned restriction I have to either waste space for a separate clone or do some ugly workarounds to keep the worktree on the branch while not keeping it on the branch.
jujutsu workspace are much nicer in that regard.
[1] I know there are tons of ways search and analyze in git but over the years I found a pristine working copy to be the most versatile solution.
That sounds like a nice improvement, just like many other aspects of jj!
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
That's... a strong statement. There is absolutely nothing wrong with going with a non-LTS version. You just have to update a little bit sooner, and that's it.
Especially with the recent extension of STS release support from 18 to 24 months [1]. Previously, upgrading from an LTS version to the next major (STS) version meant the support window decreased by half a year, while now it would stay the same.
[1] https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-su...
Why is EF regarded as such a good ORM? I've encountered countless bugs in different repos related to its stateful nature after many years in .NET. Personally I found it completely illogical for my ORM to maintain state. I just want it to hold my schema and build queries.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
Yet another similar tool: https://fairanimateddrawings.com
Discussed three years ago: https://news.ycombinator.com/item?id=35561203
Link should be https://aphyr.com/posts/397-i-want-you-to-understand-chicago
htgb commented on Athlon 64: How AMD turned the tables on Intel dfarq.homeip.net/athlon-6... · Posted by u/giuliomagnifico
I was one of those weird users who used the 64-bit version of Windows XP, with what I'm pretty sure was an Athlon 64 X2, both the first 64-bit chip and first dual-core one that I had.
Me too! It was funny how little love it got given how well it worked.
The only issues I came across were artificial blocks. Some programs would check the OS version and give an error just because. Even the MSN Messenger (also by Microsoft) refused to install by default; I had to patch the msi somehow to install it anyway. And then it ran without issues, once installed.