alanfranz

I don’t see any indication that the untrusted workload could extract data from another _unwilling_ workload.

Side channels exist; but it doesn’t mean that all of them are a security risk.

I’m not sure I see a real threat here.

If you’re running an untrusted workload, you’re already running it.

Whether it can communicate with another untrusted workload, even though it should be separated, meh.

Unexpected? Probably. but I’m not sure it’s a security risk.

… IF chinese models stay open.

From a purely technical perspective, gog offline installers make it trivial to preserve your collection.

It may not be legal, as I said.

What I mean is that for most (all?) GoG games you can download an offline installer.

So you CAN pass your collection over to your heirs on an hard disk.

Whether this is legal it’s a different matter.

You mean legally? Because technically in GoG you can.

I didn’t really read the bill, but I see no problem in subscription games. I don’t remember how wow was ‘sold’ when released. But if I buy a game on a 12 month subscription, I understand I’m not purchasing a game forever.

Problem is with “purchase” imho.

The parking lights vs low beam icon are quite standard, at least in the EU, and they tell you the difference when getting your licence.

Icons are still the same as they were 25 years ago AFAICT.

> executioner

I suppose you're not a native English speaker, btw: besides the dubious statement, probably "executor" is the word you wanted to use.

Kafka also has inkless with diskless topics that run off object storage!

What kind of article is that? No explanation, no thoughts, just an empty "trust me bro" prediction from a website that usually publishes consumer hardware reviews.

And the article doesn't even appear in their homepage.

And the author is somebody from a company that "provides you with quality RAM"

Flagged. How did this even get to HN ?

The “subtle” difference in expectations implies overcommit. Malloc would be easier to understand without overcommit.

I also think that many allocators nowadays can use mmap besides brk.

It’s a standard term for a role during an incident.

Probably AI generated.

But, what bars are clearly off? I couldn't spot any.

I don’t think it would have been possible for the last 12 years. But should be possible now.

Only the 2021 spec for usb pd supports 36v (common bike battery voltage) and more than 100W delivery. My bosch ebike charges at 36v 4A.

I also think that a small usb c connector could easily break when used in an ebike. But this should not prevent standardizing a “bigger usb c” to be used in ebikes.

From: https://support.claude.com/en/articles/16266773-how-claude-m...

> We'll support users and other third parties to detect Claude’s marks

This is the part that I fear most. What happens with false positives? Will I need to change arbitrary parts of my text if they are flagged as AI generated? Will I be forced to add mistakes?

And then, since LLMs are trained on existing, human-written, quality content, it may be that well-written text gets accidentally flagged more often?

And, if all the providers do this, and they use different watermarks, will I be forced to change things at random until I get a negative from all of those?

I very much think this will yield the wrong signal. There were already some academic plagiarism checkers around that would return false positives, and were blindly trusted by teachers and professors. I suppose AI checkers are all around now, and there will be more of those.

Proofreading is one of the best uses of LLMs that I can think about - I still write my text, then an LLM fixes some of my "errors" since I'm not a native speaker. It usually improves clarity. But now I risk my text to be classified as AI written with potentially bad outcomes.

I don't know whether I should blame the EU, though :-)

But form factor and energy efficiency may be helped by some of the changes that producers are doing.

Why complain about those, then?

Diy is still possible. Looks like nas is becoming more specialized.

Looks like a bad offsite handling, both in your case and linked article.

I feel that offsites work best when you let people interact on their own schedule, pace and topics. Trying to force hands via a lot of activities can kind of backfire.

Relationships happen. They are not programmatically built.

What's the risk of NOT doing this?

That's the problem. That's the risk that few (if any) hyperscalers want to take.

But this is Rust, not safe Rust, right? So, you still have a lot of ways to shoot yourself in the foot.

Of course, the C -> unsafe Rust -> safe Rust is more likely to happen than just going straight to (mostly) safe Rust (I doubt a 100% safe dbms would make sense).

> How good are you at writing assembly?

This is a false equivalence.

A compiler is a predictable, testable, deterministic piece of software.

An LLM is not.

Sure, all abstractions leak; so, at some point in time, for some reason, you may need to check its compiled code ( cough cough gcc 2.96 ). But, if today your code compiles properly, it will properly compile tomorrow as well.

they are not bricking the units. just kindle store won't be available anymore, and the azw/epub version which is supported on your kindles won't be provided anymore by amazon anywhere.

what is on the kindle will stay and keep working.

if you reset the kindle, DRMed content won't work anymore.

Looks like they'd like something git repositories (maybe with transparent compression on top) rather than .tar.gz files. Just pull the latest head and you're done.

And?

Did I claim something different? I just didn’t use that feature on other OSes.

Well...

I'm not sure what the author really wants to say. mmap is available in many languages (e.g. Python) on Linux (and many other *nix I suppose). C provides you with raw memory access, so using mmap is sort-of-convenient for this use case.

But if you use Python then, yes, you'll need a bytearray, because Python doesn't give you raw access to such memory - and I'm not sure you'd want to mmap a PyObject anyway?

Then, writing and reading this kind of raw memory can be kind of dangerous and non-portable - I'm not really sure that the pickle analogy even makes sense. I very much suppose (I've never tried) that if you mmap-read malicious data in C, a vulnerability would be _quite_ easy to exploit.

You are right. I linked a differently formatted article with the same content. I don’t know why I didn’t initially notice such text.

I’ll answer to myself: an RCE is very unlikely on any modern platform. DoS is possible.

“ Impact summary: A stack buffer overflow may lead to a crash, causing Denial of Service, or potentially remote code execution.”

From: https://openssl-library.org/news/secadv/20260127.txt

Is this really exploitable? Is stack smashing really still a thing on any modern platform?