leanleft

joined 4 years ago
[–] leanleft@lemmy.ml 1 points 4 weeks ago

anyone who has this kinda money would probably just store data on cloud storage provider. unless they are the provider.

[–] leanleft@lemmy.ml 14 points 4 weeks ago

this *seems* long overdue

[–] leanleft@lemmy.ml 17 points 1 month ago

currently* back only as readonly

[–] leanleft@lemmy.ml 2 points 1 month ago

cool info. but more of a lifehack

[–] leanleft@lemmy.ml 3 points 1 month ago* (last edited 1 month ago) (2 children)

what makes this so great? ( genuinely curious. slightly critical)

[–] leanleft@lemmy.ml 6 points 2 months ago

maybe its time people redirect their money to supporting peertube

[–] leanleft@lemmy.ml 5 points 2 months ago (6 children)

better to keep track of a ton of torrents and seed the ones that go completely dead

[–] leanleft@lemmy.ml 2 points 3 months ago* (last edited 3 months ago)
[–] leanleft@lemmy.ml 1 points 3 months ago

We share a public space with LLMs now

[–] leanleft@lemmy.ml 1 points 3 months ago* (last edited 3 months ago)

"In kernel development, debugging is very hard for several reasons:

  • Documentation is often hard to find, and BIOS implementations may be flawed (more often than you would think)
  • On boot, the kernel has full access to the memory and is allowed to write where it should not (its own code, for example)
  • Troubleshooting memory leaks is not easy. Tools such as valgrind cannot be used
  • gdb can be used with QEMU and VMWare, but the kernel may have a different behaviour when running on a different emulator or virtual machine. Also, those emulators may not support gdb (example VirtualBox)
  • Some features in the support for gdb in QEMU or VMWare are missing and gdb might even crash sometimes

All those issues are reasons for using a memory-safe language, to avoid them as much as possible.

Overall, the use of Rust in the kernel allowed for the implementation of a lot of safeguards. And I believe that it is, to this day, the best decision I have made for this project."

 

"The most recent example is a now-merged merge request to revert an earlier change bumping the Zlib dependency for Mesa. The basis for that revert is that it breaks SPECViewPerf."

"Due to Mesa dynamically linking Zlib and how SPECViewPerf is handled, the update happens to break SPECViewPerf that is a popular benchmark for workstation graphics and one commonly used by hardware vendors and other stakeholders. Ultimately it's an issue with how SPECViewPerf is setup as an application bug but it could also be argued that Mesa could statically link it or better handle its dependencies. In any event, it's a regression for Mesa and breaks SPECViewPerf. And SPECViewPerf is important to vendors.

So the immediate solution that's now been merged is to revert that Zlib update commit..."

"They think it's a technical issue. It's not. It's a political and strategic issue for the Mesa community. If you prevent something from working that the industry finds important, you risk destroying real jobs in this community and shrinking it, regressing Mesa's reputation, making it more inferior in the industry, and thus less important. What this revert does is that it preserves existing jobs (i.e. existing stuff keeps working) and opens the door for creating new jobs and growing this community in a sustainable manner by showing others what it can do. You need capital and business interests to grow the community, and to get that, Mesa must be the best because it's always competing with alternatives.

If you thought this is only about dependencies, well, you're mistaken, and if you want to hurt the future of Mesa because your stupid zlib dependency is more important than anything else, including the livelihood of other people, you're just a foolish bikeshedder."

 
 
 
 

pandemic WW3 work

1
Ourgasm (i.redd.it)
submitted 2 years ago* (last edited 2 years ago) by leanleft@lemmy.ml to c/memes@lemmy.ml
 
 
view more: next ›