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

When I see stories that make me want to click, I read HN comments first, and 8 times in ten that saves me a from a "won't get fooled again" moment.

There's got to be a way to generalize this for anyone who still cares about the difference between real facts and manipulation.


Sufficiently advanced ideological capture is indistinguishable from parody.

If you're not willing to pay for your own LLM usage to try a free resource offered by the author, that's up to you. But why complain to the author about it? How does your comment enrich the conversation for the rest of us?

It's not free if I have to expend Claude credits on something a locally hosted Qwen 7B could handle.

> How does your comment enrich the conversation for the rest of us?

Straight back at you.


Yes, it has actually worked starting with the Pixel 3.

It's called Dual-Band Simultaneous or "STA+AP" (Station + Access Point) concurrency that can bridge an existing wifi connection to an access point to other devices via a hotspot.


And then a few of those users who you treated like adults who don't need surveillance make a private network among themselves and other nodes in Russia and China to exfiltrate the corporation's most sensitive intellectual property, serve as a bridge for state-sponsored bad actors to bypass your firewall, and tunnel command-and-control traffic through your "unrestricted" egress, and now your zero-trust philosophy has created a zero-accountability blind spot that your IR team discovers eighteen months later during a breach investigation.


If your threat is state sponsored bad actors you've already failed. OK, great you blocked VPNs. Now they tunneled their vpn through as HTTPS. You successfully annoyed all your legit users and completely failed to stop the real problem.


Https is also inspected in our place and has been for a decade.

Also there's different classes of state sponsored APT groups. You won't stand a chance against the NSA but there's a lot of state sponsored groups in Russia that are just looking for low hanging fruit to get some foreign money for their regime.


What’s the alternative—locking down all legitimate users and still losing the data anyway?

Network controls alone don’t stop exfiltration. HDMI/DP can move data faster than most consumer NICs. Does the system account for that scenario?


It's a matter of layers. Banning VPNs isn't a perfect measure. But it makes it a lot easier than when you let everyone cowboy around.

Same with RBAC. It's not perfect because some people need legit access to stuff and it can be abused. But it makes it much harder for bad actors.


> Network controls alone don’t stop exfiltration.

Stop signs alone don't stop all traffic accidents.


You know, that makes sense for a corporate network. They have an extremely aggressive firewall on the academic campus, which is how it should be.

However, they have failed to provide isolated networks for the research labs which just need it for even downloading LLMs (they have banned huggingface!).

Moreover, a hostel is residential. They should provide either the option of getting an external connection (which I would happily do!) or provide a means of non-stupid internet which they aren't.


Then you've failed in security infrastructure, policy, and enforcement, and you've infantilized your users and wasted a bunch of IT time on checking boxes. The real power move in that case would be ensuring some third party vendor checked the boxes for you, so that your ass gets sufficiently covered and you have a narrative that goes something like "well, we did everything you're supposed to, those pesky superhackers are just soooo devious and skilled that they can get anywhere!"

The actual fix for things like that is to ensure that your sensitive data is properly protected, and things that you don't want exfiltrated aren't put into scenarios where exfiltration is possible. If you need to compromise on security for practicality, then make those exceptions highly monitored with multiple people involved in custody and verification. Zero trust means you don't give any of your users or host devices any trust at all, and modern security software can require multiple party approvals and MFA.

You can use a phone to scan documents as you scroll through them, or mitm hardware devices that appear to be part of a cable, or all sorts of sneaky shenanigans, and it's a never-ending arms race, so you have to decide what level of convenience is worth what level of risk and make policies enforceable and auditable. In some cases that might mean SCIF level security with metal detectors and armed guards, in other cases it might mean ensuring a good password policy for zip files shared via email.

Inconveniencing users by limiting web access and doing the TSA style performative security thing is counterproductive. This doesn't mean you give them install rights, or you don't log web activity, or run endpoint malware scanning, or have advanced unusual activity monitoring on the network and so forth. It just means if Sally from accounting wants to go shopping for ugly christmas sweaters for staff on Etsy, she doesn't have to fill out forms in triplicate and wait 3 months while the IT department gets approvals and management has meetings and the third party security vendor does a policy review and assessment before signing off on it, or telling her no.


The depreciation schedule isn't as big a factor as you'd think.

The marginal cost of an API call is small relative to what users pay, and utilization rates at scale are pretty high. You don't need perfect certainty about GPU lifespan to see that the spread between cost-per-token and revenue-per-token leaves a lot of room.

And datacenter GPUs have been running inference workloads for years now, so companies have a good idea of rates of failure and obsolescence. They're not throwing away two-year-old chips.


> The marginal cost of an API call is small relative to what users pay, and utilization rates at scale are pretty high.

How do you know this?

> You don't need perfect certainty about GPU lifespan to see that the spread between cost-per-token and revenue-per-token leaves a lot of room.

You can't even speculate this spread without knowing even a rough idea of cost-per-token. Currently, it's total paper math on what the cost-per-token is.

> And datacenter GPUs have been running inference workloads for years now,

And inference resource intensity is a moving target. If a new model comes out that requires 2x the amount of resources now.

> They're not throwing away two-year-old chips.

Maybe, but they'll be replaced by either (a) a higher performance GPU that can deliver the same results with less energy, less physical density, and less cooling or (b) the extended support costs becomes financially untenable.


If a model costs them 2x as much, they charge 2x as much. That much is clear from their API pricing.


Better to spell out exactly what you think is misleading than to go for the ad hominem.


The question is not "how do you make reddit work over mullvad".

The question is "if reddit can block mullvad why can't China".


There's a corollary to that question: why would China choose not to block Mullvad? We know every large nation with a capable online force maintains a fleet of ORBs, so maybe they consider Mullvad more useful for them as a functioning system?

Some of their own contractors may well depend on Mullvad. Perhaps as long as the overall "civilian" volume and user count remains acceptably low, the cost-benefit estimate may well be in favour of letting it slip by. (And for the civilians that do use a working variant, subject their connections to fine-grained traffic analysis.)


I watched from the sidelines with grim interest as my organization tried to decide between Oracle and SAP.

The team defined requirements, ran an RFP and demo process and did site visits to clients of each company. The SAP reference clients weren't exactly thrilled with SAP, the product was too complex and too expensive, but it was rock solid and SAP was a reliable partner. The Oracle reference clients had the usual complaints about features and flexibility, but their real beefs were that Oracle was a predatory and untrustworthy partner.

Oracle made claims in their RFP response that were proven false in the demos and site visits, confirming the claims from reference clients about the company's ethics. In contrast, SAP's RFP responses were validated by the team's due diligence.

So management decided to go with SAP. In response, a senior Oracle person tracked down all of the company's board members and made outrageous claims of incompetence against the company's executives, and alluded ominously about bad faith and conflicts of interest.

Oracle was completely hostile and off the rails when they figured out they lost the deal. I will never, ever do business with Oracle.

Unfortunately, while the SAP application seemed solid, the organization went with their HANA database which was astronomically expensive, and had a bad habit of returning different and provably incorrect results to the same deterministic SQL query every time it ran, and then the entire database would crash for all users.


It's wild dealing with Oracle. They are an adversary to their customers. They'll repeatedly try and setup meetings where they begin off-topic asking questions about how many cores/sockets you're deployed on (Answer: Fewer than we're paying for). When we declined their Java subscription (after thorough preparation on our part), they repeatedly threatened us with audits and ominous threats of download monitoring.

If anyone has to deal with this, I highly recommend Palisade Compliance for consulting. Ex-Oracle people who do not sell licenses, only consult on compliance and represent you during an audit.


> If anyone has to deal with this, I highly recommend Palisade Compliance for consulting. Ex-Oracle people who do not sell licenses, only consult on compliance and represent you during an audit.

Oof. That's a new standard for shitty company: when ex-employees build a business around protecting customers from their former employer.


Nvidia is adversarial too, and a giant pain to deal with. But then since the 1980s there's been a slow pendulum move to suppliers having more actual and self-perceived power over customers. I'm a big proponent of respectfully letting the supplier know when needed I tell them they don't me if I am satisfied or whether its worth the $ spent on them. Always have options. Without options there's no choice. Internal suppliers (in a corp) periodically need to be told the same thing. Mishandling one's customer power in the relationship is an error i don't like to make.


You’re going to have to elaborate on that last bit! SAP HANA is used by enormous organisations as the core database for their entire operations, so pervasive data corruption bugs would be rather… concerning.


This was in the early days of HANA, I'm sure they've fixed the defects by now, but it was shocking to pay nose-bleed prices for every 64gb shard, and then have basic SQL return provably incorrect results. It was a catastrophe, and after spending heavily on consultants to work around the defects, the organization eventually switched to SQL Server.


> return provably incorrect results.

Again, you're burying the lede here.

It's like the Linux fanboi stating without evidence that Windows will just accept any user name without a password, and then refusing to elaborate on that claim. Like... wat?

SAP HANA may have its faults, but I've never heard of pervasive data corruption as one of them.


> It's like the Linux fanboi stating without evidence that Windows will just accept any user name without a password, and then refusing to elaborate on that claim. Like... wat?

Did you enter the correct NSAKEY username?


Who, exactly, is the "we" who you see "pearl clutching" instead of "yes and-ing"?


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

Search: