eyegor

What do you mean by "relatively universal"? This is Cuda only [0] with a promise of a rocm backend eventually. There's only one project I'm aware of that seriously tries to address the Cuda issue in ml [1].

[0] https://github.com/HazyResearch/ThunderKittens?tab=readme-ov...

[1] https://github.com/vosen/ZLUDA

+1 for gitlab support -- self hosted gitlab (or gitea) is probably the most popular one, since self hosted github is very pricy

What do you mean by "for anything serious it isn't open source"? I didn't see any red flags in the apache variant of timescale, just constant pleading to try their hosted option.

https://github.com/timescale/timescaledb/blob/main/LICENSE-A...

Does llvm have good riscv support for cross compiling? In my experience, even aarch64 isn't universally supported as a cross compiling target and building on embedded devices is an exercise in patience. I never even considered trying riscv chips in production since I assumed libs would be a hassle.

Even on rpi4, it's near impossible for a normal person to use the gpu because videocore6 is so locked down that you get zero lib support or documentation. And I'm pretty sure the only assembler is still from reverse engineering instead of the manfr.

Why don't you just add sshd restart as an interface PostUp step in the client's wireguard config file?

I don't think fortran is faster by language virtue, but it's certainly easier to scrap together high performance numeric fortran code. And ifort/aocc are amazing at making code that runs well on clusters, which is not a priority for any other domain. Fortran is absolutely still on top for modern numerics research code that involves clusters, talk to anyone who works in simulations at a national lab. If your code is mostly matrix math, modern fortran is very nice to work with.

Emphasis on modern because maintaining 70s-80s numeric mathematician cowboy code is a ninth circle of hell. It has a bad rep for that reason.

Hmm but what about another mobile phone OS instead? Or a vpn service? Surely people don't care about browser features.

I'm not sure if it's still true, but it used to be that ~half of all antivirus would flag an executable if you compressed it with UPX.

Last I checked ff explicitly does not support webgpu, webhid, webusb, etc.

Apparently nightly is supposed to support it: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Exp...

I can't get this to work reliably on mobile firefox, and I don't see any non-react examples which is strange given their value pitch is "use any front-end". Sortable works everywhere and has nice simple examples: https://github.com/SortableJS/Sortable

Lga12 with soldermask stencils and a hotplate doesn't work? Should be doable for prototype quality. Might want a computer controlled pick and place with a suction arm/microscope but it's definitely feasible. Look up some of the gpu repair guys for inspiration, they often do some insane bga parts (nand chips) by hand.

I wish everything in linux land just had an AUR equivalent.

Webusb/hid are scary powerful but for some reason I've never heard of malware attempting to use it. It's a neat party trick for being able to program usb enabled chips from a browser but I could never figure out another use case.

Despite being fairly old, many systems still don't support eddsa. As an example, the reference browser/ca spec doesn't allow it: https://cabforum.org/working-groups/server/baseline-requirem.... Last I tried, even let's encrypt won't grant an ed25519 cert despite it being in tls 1.3 (2018?).

Lstm?

If you're in dotnet land, I'd recommend looking at magic onion [0] or memorypack [1]. It'll be much nicer to work with once you have a decent pile of message types. Otherwise it's easy to end up in an entity framework like situation where you're constantly serializing and deserializing, generating serializer wrappers, doubling up on dtos and schemas, etc. Although any of the cysharp libs are great in dotnet, definitely recommend checking out their back catalogue.

[0] https://github.com/Cysharp/MagicOnion

[1] https://github.com/Cysharp/MemoryPack

Closest I can think of, $70: https://nandland.com/the-go-board/

The problem with FPGAs is they're inherently unfriendly to beginners. Thinking in HDL is a bit more difficult than a high level language like scratch or arduino c++. Plus the "compile times" are absurd so a beginner would probably lose patience.

I threw in a moderately fast USB drive (~90 mb/s after pi4 overhead) because I got sick of SD cards dying every 6-12 months. Pi4 is very speed limited. Even if you tried to use an ssd, I think the highest I've seen is around 250mb/s with an nvme drive that gets a few gb/s in a real computer. In theory it should get to like 500mb/s for sata limits.

If the first step of your build process is creating a new pip venv from scratch, it's entirely believable to me. Pip resolves packages sequentially, so there's a lot of low hanging fruit even without yoinking a state of the art constraint solver.

As a concrete example, I have a raspberry pi 4 I use for "what's the most pathetic hardware a user might try". It takes 5-10 minutes to build up a fresh venv even when it has all of the packages cached. If I nuke the caches and make it download, it's 20+ minutes. For comparison a modern laptop takes ~1 minute.

Probably fewer patrons and similar number of employees in the sweatshops. More eyes per patron leads to fewer errors. Or maybe they trained the best grocery cv model around from having a big high quality dataset, and you were fighting it. But then I'd think the tech would've been passed to whole foods instead of packing up shop, so final guess is sweatshop singularity theory.

Having used webrtc in offline environments (host device broadcast a local wifi), I can say it's a royal pain to use without ice/stun/turn servers. I had to manually mangle the sdp packets to make it work because browsers would randomly decide they needed ip privacy (from the device they connected to by ip...) where they'd translate ips to some_hash.local and try to find a turn server. I tried hosting a coturn server too, but browsers would sometimes ignore it since it was a local address. Mangling the sdp handshake is reliable but feels pretty jank.

Sublime is a massive improvement in my opinion, and cross platform. It's not free** but you can use a personal license at work and on multiple machines. It's one of the few text editors with a plug-in system that can reliably open 100mb+ files and auto reload on file updates (without crashing constantly).

https://www.sublimetext.com/

** it's sort of free, the trial period is unlimited. It just gives "activate me" popups every dozen file saves or something.

Binary ninja is another good option. In my experience it's pretty similar to ida but I find it more user friendly. It just has a lot of well thought out features that make me more productive. I haven't tried hopper but ghidra and radare2 both had a bad dev experience and produced c that didn't "read well". Granted it's been a couple of years since I tried either.

Binja is $300 (or $1500 for commercial, both cheaper for students).

https://binary.ninja/features

What kind of voodoo is this? I've always wanted something like this for non technical coworkers across countries but I didn't know it existed. I always just exported TSV and provided steps for how to import it (although I think most excel versions have native tsv support).

A lot of resources go to scaffolding for containers, runtimes, caching, etc. 4gb would make for a chugging experience if you run a Java spring boot backend for example. But an old school php + postgres stack would be fine, or modern dotnet, rust, etc. And honestly I'm not sure it matters since ram and compute is cheap for most small-medium sites (at worst maybe $30-50/mo vs $10-20/mo).

VPS services are pretty cheap these days. Hetzner, digital ocean, genesis, etc. Or you spend a couple grand to build a dedicated machine in raid6 and only pay utilities.

I'd argue llms can do a much better job, because they can also emulate styles in addition to cleaning up grammar. "that's too formal", "that's too casual", "rephrase this more concisely", etc. I've run into plenty of drafts or arxiv publications that are annoying to read because the sentence structure is unnatural or overly verbose.

It has one now, but I haven't played around enough to call it "good" or "bad". It feels more like a hack than something like cargo/pip/nuget/npm/etc, but it's a lot better than the normal c/cpp experience.

build.zig.zon discussion: https://zig.news/edyu/zig-package-manager-wtf-is-zon-2-0110-...

Example howto: https://ziggit.dev/t/how-to-package-a-zig-source-module-and-...

Actual docs: https://ziglang.org/download/0.11.0/release-notes.html#Packa...

> readable for several years

Why not just make shims to migrate dbs for future compatibility? So you could read db 1.0 in v2.0 but only insofar as to migrate it to v2. The implication that you don't want to promise backwards read compatibility feels antithetical to a db driver.

For example, if I have an ancient mssql db that was started in 2001, I'm confident that I can grab the latest mssql driver and still use it. I don't have to track down mssql 2007 to migrate incrementally. Not sure about postgres or mysql but I assume it's the same there. Sqlite is definitely backwards read compatible.

Ah yes, the lambos come out in force at the bsides conferences.

Correlation != causation. Especially when the study doesn't show a simple correlation like that either. At least not for heart attacks.

> The multivariate survey‐adjusted logistic regression analysis of the entire sample did not reach a significant association between daily cannabis use and CHD (adjusted odds ratio [aOR], 1.16 [95% CI, 0.98–1.38]; P=0.09)

But there does seem to be one for strokes

> Among those who had never used tobacco cigarettes and had never used e‐cigarettes, cannabis use was not associated with CHD or MI but was associated with stroke (aOR, 2.24 [95% CI, 1.31–3.83]) versus tobacco‐adjusted odds in the whole sample (aOR, 1.42 [95% CI, 1.20–1.68])

Study https://www.ahajournals.org/doi/10.1161/JAHA.123.030178