viraptor

It also has a long list of crashing bugs open in the last few years: https://savannah.gnu.org/bugs/?group=pspp

But regardless, I know about projects like that. And I've been using Octave instead of MATLAB during my uni years. But I suspect the situation is similar here - not all the time, but sometimes you just need something to work precisely like MATLAB.

> You don’t even understand my point.

What if you didn't understand the comment?

Full validation of spec to implementation is still close to impossible and nothing that exists today will get us there outside of extremely limited scope. But some language features make the gap just a bit smaller. The less you have to look at details and more at the actual structure, the more you can be sure the implementation matches what you want.

Extreme, unrealistic case: you want to add something to a list of samples - one implementation does list.add(sample), the other inlines all the reference counting, object cloning, memory allocation and possible extension of list over 100 lines. How sure are you that either one of those implements what you want? Now reduce that to more realistic scenarios where C still forces you to either be more verbose or less explicit, while Rust (or any other more expressive language) lets you show exactly what's needed via better features or via types.

> Does it know anything about quantiles or student t distributions and will warn the agent if it implements them wrong?

No, we're not even close to that. But it lets you use stylo and implement `student(PositiveInteger v)`, which you can't achieve in C. So again - nothing can eliminate that gap today, but language features can definitely make it smaller.

> And most corporate workstations do not allow sandboxing of any kind

I don't think that's phrased correctly. What corporate it does is set policies. Often those policies disable virtualisation. (They don't disable sandboxing - that's used in many ways and security loves that) But if the business need is to run LLM agents safely, the policies will be changed to dictate how to run agents safely.

It doesn't connect to your phone, it just authenticates via the app. I deal with a company where people use thin clients that run WhatsApp on the remote desktop. It's not an unusual case.

> not sure how Rust helps with that as it won’t solve mismatch between intent and implementation.

It's not rust specific, but any language which allows you to work on a higher level and with better typing helps close that gap. For example for a long time Linux kernel had an issue with marking user/kernel addresses which opened it up to bugs and security issues. In C those are just numbers. In Rust this is moot and correct by default because user addresses are explicitly UserPtr.

So yes, sometimes a better language allows you make some unintended things explicitly not compile. It won't solve the issue completely, but the scope of the mismatch gets much smaller.

I've done some without any effect. I'm guessing there may be some sneaky moderation in play. I did email the mods though.

Author's comments are dead unfortunately so I'll repost w fragment from them here:

> It's not about memory safety per se. It's about not losing an hour of analysis because a malformed .sav file or a zero-variance sample triggered a segfault or silent wrong output. SPSS crashes on bad data.

I'm extremely on the other side - it's not about what we gain, but what we don't lose. If there's even one person with a dataset they can't process easily without a proprietary tool, why shouldn't this exist?

I'm extremely happy every time a closed format falls. Whether it's this one, Sibelius music scores, records from medical devices, data series from scientific measurements, or something else. Every one of them stopped me from doing something in the past (not on a technical level but "it's not worth spending a month on this") and I'll support efforts like this.

It depends on what you actually want to ask permissions for. We're still doing trivial script execution, but we could go further. Capabilities like "do you allow giving access to JIRA read only token" would be a massive improvement. But there are other paths too.

Honeypots are not there to prevent or disrupt attacks. You use them to collect interesting interaction samples. The author is not running any real fridges or making any choices about protecting them.

Both the post and the comments. It's cringe. Just write what you have to write, author.

That's an interesting approach, but... what's the performance impact? It seems the check was done only against really trivial tasks. Why not run some known coding benchmark against the original and pruned one?

Also Gemma is Moe not modem (https://arxiv.org/html/2410.07490v1) so will try to balance export choice for each token - I'm suspicious about expectations for this model.

That's the annoying thing with WhatsApp, Slack, Discord, etc. Let's say I've got a personal client (that I'm definitely not using...) which works so much better than the official one. I cannot distribute it or use it according to their rules. It's forced enshitification, even though we have better options.

On the good side though - if you're replicating the official behaviour close enough... maybe nobody will know. But then you have to make sure everything, including key sort order, and JA4 of requests matches. And that's tough...

> Basically every device has a GPU.

Many VMs and remote desktops don't. (Or can't really make use of)

It's a spectrum. I'd give codeblocks 25% of an IDE ;) But it will depend heavily on what you expect.

Rich IDE is not something you achieve by slapping a few extensions on an editor. It's in the name - Integrated. It means that there's a GUI designer which is aware of local classes, inspector at runtime which can jump into the right areas of code, performance analysis that gets populated during runs, highlighting and compilation that's aware of the currently selected configuration, etc. There's an extension a few of those, but they're mostly independent and isolated.

VSCode is absolutely not a rich IDE. It's a fancy text editor will extra plugins. Visual studio or IDEA are rich IDEs.

It's not clear which v4 flash they used. There are 3 different releases for that one.

Edit: I think that's the answer. This page lists the score as 53.3% which is close to the 54.4% reported here https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731 for the 0731 update. The original from April was called preview, doesn't list the score, but in the comparison with the update it scores 7.3%.

Of course some will last longer. It's not a cliff, just "not recommended to use for longer than...". But a lot depends on the conditions of storage, how much usage they got, etc. Manufacturers gave them 10-20 years normally, which puts almost all of them in the not recommended territory.

The fact people have old working floppies doesn't change the fact that degradation happens.

Also depends on the environment. My dad used to repair the pre-PC computers: Amiga, Commodore, Atari, Spectrum, etc. I've had access to them before many others have even seen a computer. I've been given a really heavy, not-completely-broken and usable laptop before they became affordable for normal people.

People who grew up with or lived in the tech environment had access to lots of things.

You're referencing "rule of law" but... what exactly do you mean? Bartz v. Anthropic resulted in a ruling that training from copyrighted books is fine if you buy them. Doe v. GitHub dismissed DMCA claim, saying Copilot generated code doesn't infringe on open source licences.

So far the precedent and the law implies the open source licence won't matter for training and the result. And these decisions will now be brought up in the US in any new cases raised.

> all of M4 and most of M5 working

This is confusing - your website shows M4 as Wip (i.e. pre-alpha) and only M4 mini as alpha. M5 is not listed at all.

Wip is described as "Bring-up in progress. Not usable yet." So is it "not usable" or "all of M4 (...) working"?

> i used kde before,

If you're comparing Omarchy to KDE, I don't think you understand what either actually is. You can use Hyprland/Quickshell in other systems.

> but a community built distro

Omarchy is also not a community built distro.

As much as I'm for releasing everything people learned and patching all-the-things soon, I would really like it if nobody was an asshole around Christmas. You can wait until next year - just let people rest - there's no point doing disclosures then from the non-malicious side.

You're nitpicking. It's a week of security related work. It makes sense. The idea is that people dealing with new issues need a break - doesn't matter when the cve was assigned.

> It doesn't matter if the number was ported and originated from a mobile service or landline telephony provider.

It still depends on public databases with hopefully-accurate data. I'm registered on Netflix on a number which can make and receive VoIP calls. It's just not a usual VoIP-specific provider. https://news.ycombinator.com/item?id=50401117

It's not fully reliable. For example you can have local residential lines that in practice go over VoIP and the provider allows you to use the same account to call out. They'll be classified as just normal landlines. It will vary wildly from place to place, but I think soon the type field in HLR will mostly lose its meaning.

(Just checked my company number, running on a hosted PBX, and it's marked as landline with no extra porting info that would contradict it)

I wish other services were as good. Yeah, start with those. But unfortunately this one has the widest support for various sites.

No, this makes sense. You often see people avoid a good solution in early languages, because it's harder to implement. This impacts security, performance, and overall design.

Consider how much easier it is in rust to do tagged unions that won't have the same pitfalls as C's, how much more likely you are to use a rust map from std rather than custom / imported dependency to do that in C, how much more likely you are to do real Unicode processing in rust vs treating strings as opaque bytes and hoping for the best in C. These are things that happen all the time. We can improve design and engineering a lot by simply providing an easy way to get it implemented.

The first time you need a string map in an existing C code, it's often "an event". Do you spend time rolling your own? Do you include a library? How big - are you pulling the whole glib? Do the strings need fancy locale aware comparison? Do you simplify, take a performance hit, and just scan an array instead?

A lot of the time when there's a logic bug and people comment "that's not a memory safety issue, Rust wouldn't protect from it", it's true, but I also think: "but this issue wouldn't exist because enum/type matching would stop it".

Call your representative and bother them about punishing the callers and telcos. It can be regulated. Just needs people to care.