Hacker Newsnew | past | comments | ask | show | jobs | submit | jabwd's commentslogin

If the US had working anti trust this wouldn't really even be a thing.


The market is a funnel, rewarding centralization, you can thrustbust the t-1000 all you want, but the mercury meets in the middle and guess who is back.


Yes, but that's by design in some sense. Monopoly is a carrot, entrepreneurs are donkeys on treadmills chasing after such carrots. The market's value to society in this metaphor is the energy produced by the treadmills, so while it's critical to offer donkeys the promise of a carrot, it's even more important they don't actually get it, because then they step off the treadmill and become a nuisance.


I agree you could make laws allowing for self-busting. As in, some management whistleblower having evidence of monopoly practices, reports it and the company gets autosplit- with the dissidents as manager of the new company.


(Actually I think it was Gallium but your point stands ;) )


He just wanted to use LLMs for coding, and not enough training data on Swift code exists for his use case. Admitting to that would be rather silly, so here we have this sentiment now exist rent free in people's brains.

The C++ interop of Swift is perfectly fine, to such a degree that FoundationDB is now using it effectively alongside its C++ origins.


It is not an OS with bubblewrap, you can still mess up your privacy / security if you want to, that includes phishing and social engineering.


Is anything bulletproof against the user signing away their data? I think the question was whether it has any measures in this regard, not whether it's impossible to get phished


It's complicated… in a sense the bulletproof solutions are the ones that raise the cost of executing the attack above the average take. In another sense even they aren't bulletproof.

This particular attack requires getting users to sideload apps that would be rejected by the play store, and most users don't have developer mode enabled. Therefore, the cost of persuading someone to enable developer mode matters. If the procedure to enable developer mode changes from "open settings, scroll down, tap, scroll down, tap seven times" to include e.g. a 96-hour wait for developer mode to be enabled, then the cost of the attack rises by whatever it costs to stay in close contact with the victim for 96 hours, close enough to react if the victim comes close to realising the truth.

This isn't a guarantee. You can still get phished even if the phisher has to spend 96 hours in intensive contact with you. Some victims are worth that effort, maybe you are, and maybe the phisher made a mistake and puts in the effort to phish you based on the mistaken assumption that you're a millionaire.

There are also other things like that. If Google can ban the keylogger you use quicker than you can deploy new builds, for example. Still no guarantee.


Has nothing to do with Trump. Trump just made the need more obvious but these talks are not new.


You can configure them to pause them when you take them out of your ear, except when it is not an Apple device. They will refuse to do so, even though they clearly detect the event since you can no longer use the stem as a pause button when you do so.

Clearly they make it worse just because you didn't get an Apple device, so yeah idk what you're smoking but give me some.


yeah the fact that many things start working if you change the host ID to apple device is very sus. i retract.


The amount of redis-as-database, or X really, that I see deployed that practically make no sense is insane. I haven't run the numbers to make my following claim based on anything but my feelings, but just incompetent dev alone is probably what keeps cloud computing alive.


Nah they stopped caring as well. Developing an application for macOS is hell nowadays. I hate the state of things but both Apple and Microsoft dropped the ball. Linux is even worse, so yeah I don't see a reality out of this unless we actually create something that surpasses the web in all measures.


Yeah I got one, why? You aren't learning anything, you are just copying code from other codebases and smashing it together to make some nginx-rust thingie... for what actual goal?


Well the biggest goal was to be useful. Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched, so a drop in replacement would be a big deal in that world.

But in terms of learning I'm learning relatively little about how to type Rust into an editor but a lot about how to set up agentic loops that can autonomously get tests to pass and improve performance.

For example if you just tell a frontier model (gpt5.5 or Claude Code 4.8) to make some portion of the tests pass they will take forever and just bang their heads against it. I developed a framework to mimic a lot of these tests in nginx... but in minimum non blocking ways so you can run many in parallel with short feedback loops.

Similar for performance - how to make tons of performance benchmark and expose maximum telemetry for agents to go and analyze the hotpaths etc.


> Nginx serves ~20% of the web, memory unsafe languages might just become untractable for critical exposed to the web infra if the rate of critical CVE's on these rises faster than they can be patched

That is true, however did you actually do any research into nginx? Is it particularly prone to memory bugs?

I honestly don't know the answer but you seem to be coming from a place of C bad, therefore nginx super vulnerable?

In my experience with other web servers the vast majority of security bugs are string handling related (path/header injection), which your rewrite will not protect you from.


https://securityaffairs.com/192132/hacking/nginx-rift-an-18-...

The project was inspired by that. Also unlike most other projects, nginx is directly exposed to the internet often times which makes it more vulnerable than i.e. Redis/ Valkey or something that would be running within a companies network generally.

"C Bad" is a bit reductionist... but I think there is some truth to the take " Until you have the evidence, don’t bother with hypothetical notions that someone can write 10 million lines of C without ubiquitious memory-unsafety vulnerabilities – it’s just Flat Earth Theory for software engineers" [1]

NSA and other government orgs are also pushing people to stop using C [2] for important software.

[1]. https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... [2]. https://linuxsecurity.com/news/government/nsa-s-plea-stop-us...


I think the risks of a rewrite - especially when using AI - are far more problematic than memory safety. In the long run those C projects will be memory safe in the next five years using memory safe C implementations.


My perspective is that it is good to have a beta in a lot of directions.

No one really knows what the endgame of software security looks like.

So some people should try the port to rust angle, some should focus on hardening the C, some should explore more exotic options like formally provable languages etc


There is nothing wrong with trying different things. But the fundamental problem here is that projects and their communities are social projects and need to be to fulfill their purposes and to ensure long term maintenance. In a free software context, rewrites just like forks (1) are fundamentally an asocial (2) activity because they fragment the community (if successful) and then increase overall maintenance burden if not able to replace the original project completely (rarely the case). Disrespect the license choice of the original authors makes this worse.

1) There may be situation were are fork makes sense (e.g. because one project can not serve different use cases well): 2) Which is why usually a "higher goal" is used to justify this, e.g. authors pretend (or lie to themselves, or may be be stupid enough to actually believe this) that some improvement in memory safety is really that important.


You won't get anywhere pressing your case here. This group has already found you guilty, and no argument will change their minds.

You've been caricatured into a blind AI-follower rust-rewriter-just-because type, and that's the surface they'll continually attack (you're wasting time, hurting the community, v2-itis, bikeshedding, premature optimization, copyright violation, moustache-twirling-evil-intent-rug-pull-later, etc etc etc).

Just continue in your work. It's good, and we need people like you.


There was no caricature as a "AI follower" etc. I gave my arguments you didn't.


You mean you rewrote the nginx test suite with smaller leaner tests ? How did you bootstrap that ? How do you know the leaner tests are equivalent to the real ones ?


Here is an example https://github.com/ianm199/nginx-rs-port/blob/main/crates/ng...

Basically I use these "kits" to prove that the behavior is working as expected with mocked data/ interfaces and then only after these kits pass I'll run the real test suite files as confirmation. So these let you iterate a lot faster than the official test suite because it is very slow.

These are bootstrapped from the real tests.

The other commenter was being a bit dismissive but this is the kind of thing I'm taking away as a real useful pattern to do verification of behavior at scale.


> the biggest goal was to be useful

Please excuse me for being unnecessarily harsh for a moment, but web servers are a dime a dozen. Quite literally. The reason nginx is successful is because it is maintained. Unless you plan on maintaining your nginx-clone as well as nginx itself, it will not be useful.

Perhaps you do, in which case I am more than happy to be wrong, but sometimes people think the act of writing software itself is useful and that other people will happily swarm over it and maintain it in their absence, but that is usually not the case.

The world has tens of thousands of http daemons, increasing that number by one is not useful in itself. The act of maintaining software over time and keeping it useful for many people however, absolutely can be.


Buddy, I think it is time to not engage with these models for a bit, you seem to have lost your mind.


We're literally in a thread on converting legacy C projects to idiomatic Rust? It seems many people are working on this same problem.


There are plenty of Rust based reverse proxies out there, why do you need to specifically rewrite nginx? You could also write a config adapter to Caddy, there are a billion options, but this is a wasted effort. The people who want to stick to their nginx configs won't use your project ever, and the people who actually care about security aren't going to use a vibe coded project.

I have no idea why you are making me spell this out, I thought it was pretty obvious.


nit: well-written C projects to legacy Rust


One very strong draw I feel, that's mentioned in this article: Rust's portability, it's ability to be compiled to wasm & run very well anywhere.


Because C code in production is a ticking time bomb.


Try reading the article next time.


I generally try not to be outright dismissive of articles/blogposts, but I don't see a ton of value in reading about someone being against opening Pandora's Box after the box has been opened. It can never be shut and we are going to have to figure out how to live with the consequences of it.

I gave the article a chance regardless and it's nothing I've not read before.


Indoor smoking in restaurants used to be legal, we made it illegal. Slavery used to be legal, we made it illegal. Don’t say that it’s not possible to stop bad things that are already happening.


It’s kind of a pointless article. Also framed wrong. Generative AI doesn’t “stand for” anything. It’s just a cool technology. Author’s time would be better spent criticizing big tech perhaps.


Actively detaching yourself from the problems of a technology doesn't suddenly make it a pointless exercise. It just puts into question whether you have any moral compass whatsoever.


It is all in the law, the problem is enforcement. 99% of the cookie banners on the web you'll encounter are in fact illegal.


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

Search: