litchralee

In California, property tax is adjusted annually regardless of which way it goes. But if it goes up, it is capped at 2% per year, due to Prop 13. If the assessed value drops, then the reduction in property tax is not limited.

As public policy, this has been devastating for local funding, being the primary means for funding local school districts in this state. When the education prospects of children are subjected to the whims of the wider economy and/or how hot (or not) the local property market is, this is a recipe for inequity: well-off areas are willing to tax themselves extra (beyond the Prop 13 2% cap) and get good schools for it. But poor areas cannot afford even the existing tax, because property tax is regressive and consumes a larger proportion of poorer household budgets. Meanwhile, the state abdicates its role in funding education, because they believe the locals would vote for more taxes for education, even though it's plainly obviously a Zip code lottery.

But I digress.

I believe you have the current meta understood, yes.

I know that most people actually get places by having stuff to show off e.g projects, clubs and GOOD GRADES

From what I've seen with how my company handles intern applicants, there are at least two different tracks: the first track is indeed people that have GPAs and coursework that is immediately impressive to any recruiter working on commissions. But the second track is where applicants make an impression to our engineers staffing the company's booth when on-site for career fairs.

My take is that engineers have a better gauge for aptitude and generally fitting-in with the company culture, miles above what an external recruiter or a company HR person could ever assess. This makes for higher quality interns, whom could later be offered a full position. And fortunately at my company, the process for assessing applicants from either track still ends up before an interview panel of technical people.

My advice then is that in tandem with a mass approach to resume distribution, also seek out in-person career fair opportunities. These opportunities won't exist after you've left uni, and it's a good way to both understand a prospective employer and also make a good, in-person impression. And if you do this, do brush up on exactly what those prospective companies work in, and put your most appealing strengths forward first. Even just asking them questions but using correct industry vocab is a differentiator.

Happy cake day btw!

Yes

Better to use an old architecture whose patents have expired, and implement it on a new, smaller process.

I'm not aware of any examples of an old architecture that was largely reused while ported to a new process, without requiring extensive redesigning of the analog components. Old processor architectures are a product of their day, making assumptions and decisions about the silicon paths that would be wholly invalidated if brought as-is to more-modern processes. It is nowhere near as simple as a copy/paste job of SystemVerilog or RTL.

To invest even one hour of design time to update, say, the 1970s Intel 4004 design (10 micrometer process) into the 2000s (130 nm) would be more expensive than just using RISC-V for free, which has already been fabricated using 22 nm, among other processes.

I can't say I've looked too much at RISC-V (yet), but someone once painted the following picture for me: if AMD and Intel are duking it out for supercomputers, while ARM works its way up to servers and down to microcontrollers, who serves the absolute smallest use-cases? As in, what if my whizz-bang product genuinely only needs a 300 Hz -- not MHz, not kHz -- processor to do some truly banal calculations? How can I possibly convince a silicon fab to build such a niche and tiny chip at scale?

In this context, scale would be however many could fit a single 300 mm wafer, and takes into account the fixed cost of the wafer itself, and then the price premium for smaller manufacturing process that would fit more chips onto the same wafer. At such low clock frequencies, the chip could be made using ancient lithography machines for dirt cheap.

But ARM would almost certainly not entertain the request to do consulting work for such an incredibly low-end chip, where the ARMv8 and v9 architectures would be vastly overpowered.

For these sorts of economically infeasible ideas, RISC-V brings to the table the possibility that some small-batch ASIC consulting firm would work with their customers to churn out some mindboggling processor designs. Because when the architecture is free (as in beer and as in speech), it releases the designers from constraints that today's designs must have.

some ominous comments stating that it is practically unmaintained (which is not true)

Objectively, I can see that the last commit to the default branch was in March 2026, and that the 10th newest commit was back in September 2025. Of these 10, 3 are new features and 6 are fixes and 1 is documentation. I also see in the issue tracker that no project developer replied to the two newest reports, which were reported 2 weeks and 2 months ago.

As a subjective opinion, the explanation that Conduit is essentially rock-solid and this doesn't need much upkeep or commits, that is just not credible. The Git history shows fixes and new features, but at a rate that averages just one commit per month. And some of those commits are literally one-line changes.

But let's suppose that the maintainers are uninterested in small UI or quality-of-life features, and only make changes when it crosses their threshold for what is "important" enough. That's a choice, sure, but let's see if that holds water. Here is the project's response to an issue opened in January, with the response being in February that confirms a logic bug and schedules it for the next release.

That was three months ago. No updates. No mentioned branches or PRs or merges. All while this bug remains in place. And that's understandable for FOSS project developers, for whom the project is not their day job.

But in any circumstances, the totality of the evidence does not inspire confidence, let alone a determination that Conduit is "rock solid". And that's even before looking at the code.

TL;DR: the premise of the question is wrong. Conduit is not maintained.

If the data is already delimited, why does the implementation need to have fixed offsets? Why not just count the fields, as 0, 1, 2, etc?

Your post speaks of brittle code but using fixed offsets is almost always guaranteed to be brittle.

I have two questions: 1) was this written using an AI/LLM? And 2) can you give an example input text that this parser is meant to parse?

Given that your original problem was related to WAN upload performance, why did your investigation lead you to Ethernet flow-control? An ISP connection generally deals in packets at Layer 3 ("network", eg IP) of the OSI model, whereas Ethernet is a Layer 2 ("data-link") layer technology.

If there is a bottleneck at your WAN modem, then that will cause congestion at layer 3, but Ethernet flow-control can only deal with congestion that exists at layer 2. What has likely happened is that you have configured your gateway so that congestion at layer 3 is mirrored onto your layer 2 LAN. And if flow-control is enabled, then that would result in back-pressure propagating back to your VMs. Your VMs will then slow down their layer 2 rate, which conveniently forces the layer 3 traffic to also slow down.

This is an incredibly round-about and inefficient way to do traffic shaping. You should not configure a network so that L3 and L2 issues bleed into each other. A major consequence of using flow-control in this way is that it reduces the capacity of your LAN, even for traffic that isn't going out to the WAN.

The customary approach for keeping L2 and L3 separate is to perform traffic shaping solely at the threshold where your LAN meets the bottleneck. This would be OpenWRT, since after OpenWRT would be the WAN (50 Mbps upload). OpenWRT would be configured with some sort of QoS feature so that certain L3 packets are selectively dropped.

You cannot do effective L3 traffic shaping without dropping packets. In fact, all competent L3 protocols expect dropped packets in order to slow down their data rate: SCTP and TCP have their own exponential congestion control mechanism, UDP simply accepts that some packets won't make it through, and QUIC has its own mechanism as well. Simply put, all L3 protocols only understand one signal that tells them to slow down, and it is to drop a few packets. They will adjust accordingly, finding the stable equilibrium where traffic flows at the very cusp of congestion.

The Main reason for this problem seems to be the down-stepping of 10Gbit traffic to 1Gbit devices

This is a red-herring, for the reasons I've outlined above. With 1+ Gbps connections on your LAN, your L2 network is an order of magnitude faster than your WAN upload. It cannot be the case that a fast LAN makes a slow WAN slower. This is not RF impedance where step-transitions cause reflections; we are dealing in packet-switched networks, where queuing theory controls.

TL;DR: please try OpenWRT QoS instead

I personally would be thrilled if day-to-day commerce could be settled using HTTP return codes. If I could IP-block the small-talk, DNS blackhole the advertisements, and just do precisely the transactional things I have to do, without being accosted by pushy salespeople, the inconvenience of driving and parking in car-dependent suburbia with no realistic, properly-funded transit options, this would honestly be great.

The modern in-person shopping experience is not a place of honor. It is an affront to call shopping malls and big-box stores as "the future" when it so degrades the human experience, reducing people into wallets with emotions ripe for exploitation.

Online shopping did not kill in-person shopping. The in-person shopping experience destroyed itself, poisoning the idea for whole swaths of the next generation. Only time can possibly heal these deep wounds.

The latter part of Rule 3 is the issue:

If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

There is exactly one sentence in the post which relates to self hosting, buried in the middle of a paragraph, and one which could be plausibly understood in two ways: 1) we (Anonymous) are recruiting the working-class people who maintain the infrastructure that keeps the world running, or 2) we (Anonymous) are seeking people that know how to build self-sufficient infrastructure. Only the latter might be vaguely self-hosting. And in no circumstance would I say the sentence is "obvious".

I won't rules-lawyer the other points, but I repeat the old adage: when you hear hooves, think horses, not zebras. If a post is skirting multiple community rules, and the community is downvoting it into oblivion, then all signs point to a post that shouldn't be here.