Hacker News new | past | comments | ask | show | jobs | submit | loeg's comments login

Evergreen. The same observation applies to any subject you know anything about that is discussed on HN.

It's probably a recurrence of the same issue.

If your domain links to content that AVs flag as malware, it gets blocked on FB. Distrowatch is likely uniquely susceptible to this because they're constantly linking to novel, 3rd-party tarballs (via the "Latest Packages" column).

In this case, it was the Privoxy 4.0.0 release from the 18th. You can see it linked in this Jan 19 snapshot of the site: https://web.archive.org/web/20250119125004/https://distrowat...


I suspect the author is summarizing the response in an inaccurate way. I suspect the response was that distrowatch is remaining filtered (because it linked to a tarball that AVs flag as malware).

If your domain links to content that AVs flag as malware, it gets blocked on FB. This is probably not shocking? Distrowatch is likely uniquely susceptible to this because they're constantly linking to novel, 3rd-party tarballs ("Latest Packages" column).


I hope that’s the case. It’s certainly a lot less chilling than intentional censorship.

It's a shame that this is one of the only accurate top-level comments and it's downvoted to hell.

I think the complaint is that it's not really a "comment", so much as it's a link to Bryan's own 20 minute video talking about it. It comes off as an annoying bit of self-promotion.

Though I will admit that Bryan is just a deeply unlikable human who is generally under-informed-at-best on any given subject that he's talking about, so people might be looking at it more cynically than if someone else posted it.


Fair enough.

Distrowatch has taken the observation that distrowatch URLs are blocked and really hyperbolized that into the broader and incorrect claim that discussion of Linux is banned. It isn't.

Fedora and CentOS are both used.

No, this doesn't show (2). It shows that Distrowatch specifically was considered malware -- not Linux in general.

https://news.ycombinator.com/item?id=42847474


Distrowatch was blocked for linking to an AV-flagged privoxy 4.0.0 tarball. The same kind of anti-malware blocking you'd expect for a mass-market, non-technical audience. Nothing to do with "speech" or Linux in general.

Some context: https://sourceforge.net/p/forge/site-support/26448/


Well, that doesn't explain why someone else in this discussion had their post removed, as there was no mention of distrowatch: https://news.ycombinator.com/item?id=42840143

Probably entirely unrelated to the distrowatch thing.

Who knows? The article says "I've tried to appeal the ban and was told the next day that Linux-related material is staying on the cybersecurity filter." -- presumably we could ask Distrowatch to share the exact wording of the response they got back, but the fact FB apparently responded in such a way suggests it wasn't a filter specific to Distrowatch.

I think the Distrowatch author is just missummarizing the interaction. https://news.ycombinator.com/item?id=42848244

Maybe! We're all just speculating about the degree of accuracy here. I messaged them on Mastodon to see if they will clarify the text. Will post back if I hear from them.

Thank you for providing this, it seemed a little clickbaity. Even far less technical companies run some things in Linux so seems weird they’d ban Linux talk in general.

So like, taking a step back, is NuttX POSIX or POSIX-like (if there's a file namespace with /dev in it / you can use the Nix package)?

And... does it have a global memory allocator (using stdlib packages that use alloc)? I can't really tell if this is an RTOS for microcontrollers or like, 32-bit ARM and don't have any background on it. And how does that interact with RTOS guarantees?


Yes, it’s POSIX-like, its system calls can even be implemented using interrupts like a normal OS (though that is optional). It has its own hardware abstractions and IOCTL interfaces around devices. Yes, it has a global memory allocator you obviously can use when processing interrupts. You can register your own interrupt handlers through the operating system, so you can still get real time guarantees.

It does run microcontrollers. In the project I worked on we ran it on a STM32 device. The networking stack, threads, POSIX-like message queue, memory allocator, and synchronization primitives were fine. It has a little shell than runs on serial that can be useful debugging tool. It had a little file system that was easy to corrupt. Most of the other hardware abstractions we avoided and just talked directly to hardware.

Personally if I were doing a project from scratch I would use a different RTOS that does not add extra layers of abstraction. But I understand the appeal of porting existing software to a POSIX-like target.


It probably makes more sense to save more bytes and compressor time and just switch to zstd (a bigger scoped effort, sure).

Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: