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

It usually says somewhere in the description I think. E.g. this one (good series, btw): https://www.amazon.com/Shattering-Peace-Old-Mans-Book-ebook/...

> At the Publisher's request, this title is being sold without Digital Rights Management Software (DRM) applied.

Not sure how universal that is, but I've seen similar language on several other books.


Oh wow, that's hidden. Thanks.

Wait, OMW book 7? Wtf? Thank you even more! That'll be up next after my Hyperion re-read (RIP Dan)


It's an enjoyable read, hopefully it's the start of a whole new arc in the series with more to come. My only real complaint is it's short and I want more. If you never read his other Interdependency series, it's also great.

I think I read all of his series, yeah. Interdependency was great.

Hasn't menu bar applets crowding with no official overflow menu been a problem with MacOS with an obvious solution (add an overflow menu) for... 2+ decades now? I know third party solutions exist and it's kind of an edge case, but still, I remember encountering this back in the day on my ancient plastic Macbook.

It's much worse than it used to be. Before it was only really a problem with apps with a lot of menus, and you could access the items by switching to an app with fewer of them. Now, the notch takes up a lot of space, and you hit it really soon on a 14" display—I can only have maybe three third party menu applets on top of my collection of built-in ones before they disappear into the notch.

I think it's not just the notch, but that menu bar icons are more widely spaced than they used to be. I want to say it happened around Sonoma (10.14)? I was working on a Mac app at the time. Icon styles went from dense with a generally square clickable area to widely spaced, wide rectangular clickable area, and a highlight with rounded corners when clicked.

I have a 16 inch and even I moved to the “no notch” resolution last year because a ton of apps don’t let you choose whether to have a menu icon, and many of them are required corporate crapware. Apple should have bought Bartender and made it part of the OS 10 years ago, or at least before shipping this stupid notch. Apple’s “we know what you need better than you do” approach is so exhausting.

Care to point me to it? The best I can find searching a bit with unlimited data is capped to 64 kbps for $100/yr, which is quite a bit worse.


I haven't checked, but see what good2gomobile.com offer on their plans if you pay for a year. I'm on the $5/mo plan for my primary cellphone.


Philips has made "smart" TVs for years, including OLEDs, and they're more or less Android TVs like most other manufacturers. So I wouldn't hold your breath for them.


That is what I meant, they are no different from any other brand. But they could be. They could guarantee no enshitification, or an open platform.


You can after the initial discovery step, the article mentions this. The MAC routing is for the first step where the device is reaching out to try and find a controller and signal it's available for adoption, which uses an IP address at least in the scheme that is relevant for hosted operators. After that initial channel is established, the controller uses it to tell the device what its hostname is, and you can switch to more normal HTTP proxy routing thereafter.


Yep, that's exactly right!


Does Oracle still significantly use Solaris? I was under the impression they barely keep it on enough life support to satisfy leftover contracts from Sun.


Nope. It's almost all Oracle Linux.


I mean, yeah, isn't that the main purpose of client isolation? It sucks when you're on something like a locked down university dormitory network but it also stops (or at least, inhibits) other people from randomly turning on your lightbulb or worse, deploying exploits on your poorly engineered IoT device and lighting you up with malware.


Citations are too open ended and prone to variation, and legitimate minor mistskes that wouldn't bother a human verifier but would break automated tools to easily verify in their current form. DOI was supposed to solve some of the literal mechanical variation of the existence of a source, but journal paywalls and limited adoption mean that is not a universal solution. Plus DOI still doesn't easily verify the factual accuracy of a citation, like "does the source say what the citation says it does," which is the most important part.

In my experience you will see considerable variation in citation formats, even in journals that strictly define it and require using BibTex. And lots of journals leave their citation format rules very vague. Its a problem that runs deep.


Thanks for the thoughtful reply!


It's unfortunate, GoTenna was (still is) pretty cool. Beartooth is similar and you can just buy them, but they unfortunately still have military-level pricing for what is pretty simple hardware.

Though in their defense, I'm not sure GoTenna was ever "popular." Probably not enough to pay the bills, given their pivot.


Meshtastic also struggles with high density and high traffic networks. Some modifications can be made to work better, but with the default settings it really grinds to a halt, and modifying the settings to be better suited requires some expertise and foresight. It works amazingly in off grid, relatively sparse networks, but it's got some major limitations.


Yeah I always wonder with these mobile ever changing mesh networks: how do they prevent messages from aimlessly looping around the network? With all the mobile devices they're too dynamic to make routing tables and broadcasting everything leads to network saturation really quickly. You could give them a very short TTL but then the reliability will suffer a lot.


Meshtastic has a TTL of up to 7 and (from what I've been able to understand) uses flood routing largely. In Northern Colorado (where I'm at) we don't have a particularly dense mesh, but are turning down from 7 because of congestion.

Meshcore seems to (I'm still learning on this) use a TTL of 64 and flood to find a route to a destination, then uses source routing for future packets, reverting to flooding again if that path fails (say a mobile repeater moves out of range).


You need 2 kind of networks: one stable with fixed nodes, with very low refresh rates of the routes, and another one for mobile nodes.


The decision that every station is always a (delayed) router was a bad one. Also the old firmware was super chatty eating a lot of valuable ISM TX time.

They must clean up their role mess and switch to a "all clients are totally quiet - until they are set to a different mode for a reason"-strategy.


FYI: Meshtastic has "CLIENT_MUTE" and "CLIENT_BASE" roles to help with this, though they do recommend using the normal "CLIENT" role (which routes traffic) as the default. https://meshtastic.org/blog/choosing-the-right-device-role/


Eh, Meshtastic was originally for sparse off grid comms less than big public networks. In that role (which is still what I mostly use Meshtastic for) every client repeating messages makes more sense.


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

Search: