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

> 2.4GHz 802.11 b/g/n wireless LAN

> Bluetooth 4.2, Bluetooth Low Energy (BLE), onboard antenna

Oof ... BLE 5 has some huge improvements over 4.2. BLE 5 stuff has been on sale for almost 10 years now ...

Hopefully this gets a refresh soon.


I had an appliance delivered from Home Depot, and after it was installed, the person mentioned he had Meta glasses on. I didn't realize the whole time he was wearing them in my home, because I didn't know what they looked like. I felt uneasy.

I recently noticed that there are a ton of gig jobs (like this https://newyork.craigslist.org/brk/lbg/d/brooklyn-office-err...) that pay manual laborers to do their ordinary work with a wearable in order to train world/vision/robotics models. So expect a lot more of this horrifying intrusion unless the cutlure shifts.

And to be clear, I would be uneasy with this being made by any company, but I am quadruple uneasy with it being fucking Meta. Fuck meta, fuck Facebook, fuck their shitty business model and their algorithm.

Most companies I can give like, they make SOME good shit. Even Google. Not Meta, our entire civilization would be better off if we shoved all their bullshit into an ocean.


> the bluetooth libraries across different devices (particularly in Android land) has me concerned

At Google IO 2026 there little discussion of core improvements to Android as a platform. It was mostly AI related, nothing about Gabeldorsche etc, which I find more interesting.


Another part of the problem is our lax regulatory "anything goes" environment which puts no guardrails on how AI can be used / abused. For example, eventually nearly everyone needs healthcare, and the idea you might be denied by AI or fighting AI to get a claim accepted is unpopular.


So far it seems like AI is helping the little guy fight the bills more?

(That can of course change very quickly, yes)



Secure Connection Failed

An error occurred during a connection to dylan.gr. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG



I disagree, there is low-hanging fruit Firefox is leaving on the table. The main thing that comes to mind is tab unloading. They don't unload tabs automatically like chrome can.

I was pleasantly surprised at the tab unloading settings under "memory saver" in ungoogled-chromium.


Firefox has been unloading tabs for several months or so (at least on nightly).


Firefox unloads tabs under memory pressure since more than 4 years: https://hacks.mozilla.org/2021/10/tab-unloading-in-firefox-9...


It is a naive and suboptimal implementation, they even describe it in the link you posted

"We have now approached the problem again by refining our low-memory detection and tab selection algorithm and narrowing the action to the case where we are sure we’re providing a user benefit: if the browser is about to crash."

I would prefer FF to be more proactive in unloading tabs way before "its about to crash" to keep system level memory pressure lower. Firefox is the main memory hog on my M1 mac.

Chrome can do this, there is no reason we should be stuck with "manual tab unload" and "unload when the browser is about to crash".

I am using an extension, but that just reinforces the argument: they could be doing much more here.


Which extension are you using in Firefox for memory unloading?


I believe that Firefox does it but not as frequently as Chrome does, but don't quote me on it. However, I am using a "tab suspender" addon on firefox to control how fast the unloading happens on tabs that are not active.


Indeed, I am using something similar "auto tab discard".


"High Performance Browser Networking"

I wish there was an update to this book, reading it a while back I think it covered some proposed HTTP/2 features but definitely not HTTP/3.

Many of the issues discussed had to do with TCP itself.


Me too. Everyone should email O'Reilly.


Perhaps the reasons are not technical. Perhaps it has more to do with jurisdiction, not being physically dependent (or susceptible) to any physical state.


After a few years of Kotlin, I recently ran into what I consider to be some shortcomings here as well, with respect to returning errors. As we know, Kotlin does not have checked exceptions. Ok, but ...

The KEEP for Result<T> goes into details, but basically there are a few ways of handling return values + errors:

1) throw exception if something goes wrong

2) return null if something goes wrong (stdlib XXXorNull)

3) Use Result<T> in some cases, its error type is not paramerized and catches CancellationException

4) Use Arrow if Result<T> doesn't meet your needs

5) Return Sealed Classes / Interfaces with all the possibilities.

Right now, I am going the Sealed Class interface route, but its such a verbose pain in the ass, so I only use it at certain levels of abstraction (like from a Repository, or library API, etc).

The code I needed to write was calling into okio, and it was not straightforward to figure out what kinds of exceptions would be thrown by the JVM layer underneath (docs just say IOException, but sublasses can be thrown).

Its sad to see they still haven't figured this out. Rich Errors was mentioned a year ago but its not even in preview yet. Its also not clear how it will work with Java interop.


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

Search: