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

Transformers operate on images and a variety of sensor data. They can also operate completely on non-textual inputs and outputs. I don't know what the ceiling on their capabilities is, but the complaint that they only operate on text seems just obviously wrong. There are numerous examples but one is meteorological forecasting which takes in a variety of time series sensor inputs and outputs e.g. time-series temperature maps. https://www.nature.com/articles/s41598-025-07897-4

> On Saturday, April 4, at 5:06 AM, I received a notification saying my authenticator had been removed. It hadn’t. The authenticator was still active on my phone - it was the recovery phone I had removed. Google apparently conflated the two.

This is a massive bug here. I was also surprised recently that Google won't let you enroll multiple Authenticators. If we had functional security regulations I think there would be some pretty large fines for Google's error here.


I have never consciously wrapped Axios or fetch, but a cursory search suggests that there was a time when it was impossible for either to force TLS1.3. It's easy to imagine alternate implementations exist for frivolous reasons, but sometimes there are hard security or performance requirements that force you into them.

Do browsers and Electron apps magically take up less memory on Macs? What is "good enough?" I never notice problems on my 16GB Windows laptop, so just for fun I closed all of my 6 always-on Electron-type apps, all of the 10 browser windows I had open, a couple other ever-present apps, and it looks like without anything else Windows 10 takes about 4GB, which I think is in the same ballpark as OS X. And I probably have some stuff running that I didn't close, this is very unscientific.

Anecdotally also, my one laptop that I've upgraded to Windows 11 is a lot snappier. As a rule I haven't noticed memory pressure on any device I've owned ever as a "regular user," it only really applies to gaming and heavy development with lots of VMs, especially these days.


Swap on macOS is incredibly good. Not sure how Apple does it. Maybe hardware compression?

It's no different from NT in that respect. macOS is significantly worse at handling OOM events than NT (even NT4, for that matter).

> Not sure how Apple does it.

They do it by prematurely wearing down the soldered SSD just in time for you to buy a new laptop.


As far as I know, there is no M1 8GB SSD wear down complaints in 2026.

There are - people are complaining about SSD health

Source? Is it SSDs breaking down or people are just looking at SSD usage and then get scared?

Throughput is directly proportional to the volume of cars, and SUVs have larger volume. Technically perhaps surface area, but there is a psychological effect to height. I believe people also give taller vehicles more space as a rule.


Throughput in congestion is determined mostly by how quickly drivers react to the opportunity to move and how many points of attrition are in a path. Both of what are impacted by the number of cars and how well they break or accelerate, not by their size.

There's space to claim large car cause attrition, but that's completely dependent of the local properties of the streets.


The footprint of the car matters. When cars get 5% longer, the same number of people in cars takes 5% more roadway, which adds up quickly, because the difference between smoothly-flowing traffic and jammed traffic is a fragile equilibrium dominated by breakpoints. Furthermore, heavier cars accelerate and decelerate slower than lighter cars, which has a compounding effect on decreasing overall throughput.


That isn't true. Most of the space a car takes is empty as you need long distances between cars.


No, the length you need between cars is variable and depends on the speed of traffic and the time it takes for a car to come to a stop. The longer a car is, the heavier it is (frames do not have negative weight), and the heavier it is, the longer the stopping distance is. Please don't bother commenting further on something you're so belligerently clueless about.


That larger cars cause diminished throughput is pretty solidly demonstrated through a variety of modeling and real-world traffic analysis.

https://www.researchgate.net/publication/365069344_How_the_r...


The heart-rate monitoring on my Garmin gives highly accurate tracking of calories burned, better than anything I could do by hand. Very valuable, I was able to lose 50 pounds and I was able to do minimal calorie counting. Basically I ate a very consistent weekly diet and used the watch to tell me if I had done enough exercise that I could eat something else. It's still very useful, I look at my calorie count regularly to guide how much extra to eat before and after activities.

I've also found some of the other ML-powered derived metrics surprisingly useful. There's a "training status" that has "productive/maintaining/strained/recovery/detraining." When I've got a bad cold/flu/covid type illness it often says "strained" which I can feel in my body but it's nice to have that objective external metric of "yes, your body is not working right and you should take it easy."

Similarly when I am working out it's nice to be able to look at my heart rate at a glance and know if I am over/under exerting myself.


I actually think Gemini Pro is great and I don't have a problem paying for it, but I don't want its tendrils in Drive and Gmail or anywhere else, it actively damages the product experience there. Everywhere they've tried to integrate LLMs, it generally provides an experience that's inferior to just chatting with Gemini.

The closest to useful it's been is in the GCP console, but it seems to decide at random to forget context, and it might just be Gemini Flash with minimal thinking, which tends to mean it's just repeating things it's already said.


All apps should be open source and subject to verification by nonprofit repositories like F-Droid which have scary warnings on software that does undesirable things. For-profit appstores like Google and Apple that allow closed source software are too friendly to scams and malware.


I don't think that's a realistic suggestion as as the quantity of applications are huge who are going to spend time reviewing them one by one. And and even then it's not realistic to expect that that undesirable things can be detected as these things can be hidden externally for instance or obfuscated


F-Droid exists and they have a much better track record than Google. I'm not actually serious, I just think if there's a single app repo that should be allowed to install apps without a scary 24h verification cooldown, it's Google's proprietary closed-source app store that needs the scary process, not F-Droid.


Users don't have to wait 24 hours because Google Play store already has registered developers. Scammers can be held liable when Google knows who the developer of the malicious app is.


Really though? Who is in jail right now for Play Store malware offenses? Or are we just talking about some random person in China or Russia who signed up with a prepaid card and fake information had their Google account shut off eventually.


I'll give you that, enforcement of the rules can sometimes fail. But scamming & malware is a global industry, definitely not limited to state-funded actors in those two countries (which is what I think you're referring to).


I think compared to the alternatives, this is the best answer.

Even if you are a bank or whatever, you shouldn't store global secrets on the app itself, obfuscated or not. And once you have good engineering practices to not store global secrets (user specific secrets is ok), then there is no reason why the source code couldn't be public.


That's absurd.


No more absurd than letting a megacorp control what I install on my own device.


Instead the megacorp forces open source licensing, which doesn't solve any of this shit anyway lol


It's also true, the best way to audit software is source-code and behavior analysis. Google and Apple do surprisingly minimal amounts of auditing of the software they allow on the Play Store and App Store, mostly because they can't, by design. It should shock absolutely nobody then that those distribution methods are much more at risk of malware.


No one is auditing. Behavior analysis works on closed source software too.


Most open source repositories do have eyes on the code. Debian often has separate maintainers who maintain patches specific to Debian.

It's not a coincidence that Linux distros are much less susceptible to malware in their official repositories. It's a result of the system. Trusted software currated and reviewed by maintainers.

The play store will always have significant amounts of malware, so this entire conversation is moot.


A lot of dubious claims here.

1. "Most open source repositories do have eyes on the code"

Seems basically impossible that this is true.

"Debian often has separate maintainers who maintain patches specific to Debian." does not support the previous statement. Debian cherry picks patches, yes.

2. "It's not a coincidence that Linux distros are much less susceptible to malware in their official repositories."

Not only is it not a coincidence, it seems to not even be true.

3. "The play store will always have significant amounts of malware, so this entire conversation is moot."

This seems to just be "a problem can not be totally solved, therefor making progress on this problem is pointless to attempt". I... just reject this?


Refusing or rejecting the claims don't invalidate them.


Why would I need to invalidate claims made with no support that seem obviously incorrect? Certainly I won't accept them.


I feel like you're overstating the resources required by a couple orders of magnitude. You do need a GPU farm to do training, but probably only $100M, maybe $1B of GPUs. And yes, that's a lot of GPUs, but they will fit in a single datacenter, and even in dollar terms, there are many individual buildings in NYC that are cheaper.


I refer you to the data centers under construction roughly the size of Manhattan to do next generation model training. Granted they’re also to house inference, but my statement wasn’t hyperbole, it’s based on actual reality. To accommodate the next generation of frontier training it’s infeasible for any but the most wealthy organizations on earth to participate. OSS weights are toys. (Mind you i like toys)


I'd really like to just have legislation to treat location data like audio or video under wiretapping provisions. If you collect my location info and convey it to a third party without my consent or a reasonable good-faith belief that I would consent, that ought to be treated similarly to recording without consent.

And consent needs to be granted explicitly for each party that might get access to my location, you can't just get blanket consent to sell my location to anyone, especially not with real-time identifiable location data.


Fair enough, but the wiretap laws are all phrased in terms of "conversation participant" -- a listener who every speaker is aware is listening. Some states require consent of all participants, others require consent of one participant.

In one-party states the consenting party has to be the one who makes the recording. In all-party-consent states, the verbal declaration that a recording is happening has to be part of the recording. It has to be verbal, so there is no "fine print loophole" -- you have to waste 2-3 seconds of everybody's time saying it out loud.

I like your idea, but the wiretap laws work so smoothly because they bootstrap off of things like "conversation participant" and "verbally granted in the recording itself" that don't carry over to location data.


> or a reasonable good-faith belief that I would consent

Don't deliberately write a loophole. No need for this part.


Good-faith is pretty narrow, mainly talking about emergencies where I implicitly could be said to have given consent, like when calling 911, or services that are close to 911 but privately administered.


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

Search: