Maybe I ate too much marketing but it does feel like having the PS5 support SSDs raised the bar for how fast games are expected to load, even across platforms.
Not just loading times, but I expect more games do more aggressive dynamic asset streaming. Hopefully we'll get less 'squeeze through this gap in the wall while we hide the loading of the next area of the map' in games.
Technically the PS4 supported 2.5" SATA or USB SSDs, but yeah PS5 is first gen that requires SSDs, and you cannot run PS5 games off USB anymore.
What are some good ways to participate if you don't have an HF radio? (Alternatively, what's a good way to get into HF if you live in a small apartment)?
I live in a small apartment and do 20m using an attic antenna. Of course, I can't compete with big outdoor antennas. But from Scotland, SSB to mainland Europe and FT8 to the US or the Caribbean is not a problem.
Even if you don't have access to an attic, there are antenna constructions that can work for apartments. Have a look at "ARRL's Small Antennas for Small Spaces" and RSGB's "Stealth Antennas" as starting points.
Alternatively, you could consider a portable solution where you carry a small HF rig and some wire in a backpack. The Yaesu FT-857D is very popular for this as it's small, all bands, all modes and does 100W. If you search for "Yaesu FT-857D backpack" you will find many suggestions. It's not in production anymore but you might find it second hand. For Yaesu, other options include the FT-891 (no VHF/UHF) and the more bulky FT-991A. Icom has the IC-7100, which is also a little more bulky than the FT-857D.
I'm a Canadian who moved to the SF bay area after graduating. A lot of my smartest friends who came with me at the same time are actively taking steps to move back due to the political environment.
I have several Canadian friends in the bay area and only one is considering moving back. The rest have bought houses here and are working toward permanent residency or citizenship.
I would love to build something like this, but it looks like the project is not quite complete yet? And also I don't see anywhere on the page where I can sign up for updates.
I reached out via email and got some more information and added to a mailing list. I'm glad they added the FAQ, it answers a few of the questions I had.
I was hit by this while working on a project for class and it was the most frustrating thing ever. The bot would completely hallucinate functions and docs and it confused everyone. I found one post where someone did the simple prompt injection of "ignore previous instructions and x" and it worked but I think it's delted now. Swore off ultralytics after that.
We were able to make some improvements by tuning how the reward is distributed and also by first pretraining the agent on scales before fine-tuning them on the final pieces.
Thanks to Kevin Zakka for helping us get started with the RL environment!
We definitely tried extending the lookahead, but I don't think we tried having a curriculum-style thing where we gradually increased the speed of the song. Great idea though!
Static linker supporter here, not to start a flame war but I like static linking because it means I don't have to worry about version mismatches of shared libraries between what I ship and what the user gets.
Your complaint is more related to how the OS you're running on handles dynamic libraries, rather than anything inherent to dynamic libraries themselves. It is possible to version libraries and serve up the correct version(s) to different applications simultaneously.
Now, consider the case of a Linux distro with a few thousand binaries. Should a defect be found in a common library, the burden of updating, say, 10,000 servers might rapidly become a headache. In this case, a shared library probably makes sense.
Also, if you want to create extensible software (like a plugin system), dynamic libraries are one of the most expedient and well supported ways to do so. This is not necessarily the traditional use case for shared libs, but it's not uncommon either. And this use case normally doesn't have those versioning problems either (as it leans more to the dynamic side than the shared side).
All that being said- static linking also has its advantages; as you stated, you can be guaranteed that your users are executing the library code you intended and that nothing breaks. It's also faster, because you're not waiting for ld.so to resolve your imports at startup & first use (nit: yes, I know you also can force all resolution to finalize at startup at the expense of slightly longer startup time). Further, you can be sure that someone hasn't hooked your library calls to do something nefarious. The downside, of course, is that you have to re-build and re-deploy your entire application on every library's bugfix/security updates.
As with anything related to computing, everything has tradeoffs. Some tradeoffs may be dealbreakers for your use case, but they might not be for someone else's.
Static linking does not guarantee that you can escape this. There are certain functions which require the same version of libc in the system, which was used for linking. At least this applies to glibc, and sticking with musl or Cosmopolitan might help.
