If the time differential is too extreme it will skip ahead or back instead of just skewing.
> ...The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time.
> This may on occasion cause the clock to be set backwards if the local clock time is more than 128 [m]s in the future relative to the server. In some applications, this behavior may be unacceptable.
> Nothing says you can't acquire parts from another manufacturer, nor is there anything preventing you from performing the repairs yourself.
Incorrect.
> I'm not sure if you've been keeping up with US news, but this isn't true, at least until it's decided in court. GM, John Deere, and Ford all have the opposite opinion[1][2][3]
> Not to mention I think it's currently illegal to Jailbreak an iPhone or root an Android, despite them being yours.
> I really do wish the US was as cut/dry as you make it seem, and I wish they cared about consumers more, but in reality, Companies get far more rights then we, as consumers, do.
For instance: parts that refuse to work unless all other parts return a handshake containing a copyrighted message.
False premise: you often cannot blow away the firmware, because it is either hard-coded, or signed.
And even when said premise is correct for a device, there are cases where the firmware inherently requires copyrighted material (For instance, requiring a (copyrighted) poem in a handshake).
What the manufacturer makes it easy to do and what you can get in legal trouble for are different things.
Do you want the state to use men with guns to force everything with a microcontroller in it to also come with an SDK? I'm basically a socialist, and even I think that's ridiculous overreach.
> And even when said premise is correct for a device, there are cases where the firmware inherently requires copyrighted material (For instance, requiring a (copyrighted) poem in a handshake).
No way! Copyright law does not prevent someone from creating a new work that is designed to be compatible with an old work. Likely outcomes are that the poem would not qualify for copyright protection for that usage (it's not a poem as much as a sequence of arbitrary bytes to be read only by a computer), or that a fair use finding would be made, perhaps on the grounds that the copy does not affect the market for the original work - i.e. nobody was paying for the poem. Most likely a judge would just throw out the entire case at the start as a waste of the court's time.
What bugs me is not so much caching as redundant caching.
I've seen applications that have 5 redundant caches, if not more (on-disk cache, OS cache, VM OS cache, stdlib cache, programmer-visible cache). And then you end up killing the actually-important caches (CPU caches, etc) from the amount of redundant copying required...
Meta discussions, such as this thread, are ok from time to time. But they don't really make anyone smarter. HN exists for YC's purposes, if those don't align with mine, then I am free to vote with my metaphorical feet and literal clicks [or rather non-clicks]. Standards are what makes a community and there are many others with different standards and precedents.
My interpretation isn't that no one can talk about the rules, just that the comments on an article should be about the article content. You could still post your own Ask HN to discuss the rules.
A lot of off topic comments would be better served being made into full-blown blog posts (even if the author has no blog otherwise; one-off pages like Gists work fine for this) and then submitted. If HN wants to talk about the topic, the submitted page will get voted up like any other article, and discussion will ensue.
Generally, Ask HN topics shouldn't be meta discussions [nevermind meta complaints]. There's a feature request policy, and it's a potential conduit for bright solutions to policy problems that bypass debate.
I think it is a subject that should be brought up. I do not think that a flat-out "stop complaining about it" is the proper response - and, to be frank, it disappoints me that that is the approach you seem to have decided to take.
It very much reminds me of an ostrich sticking its head in the sand - namely, that the response of a link aggregator to more and more of the links it aggregates disappearing is to say "no it's not, there are <insert increasingly complex and increasingly quasi-legal workarounds here>, now stop complaining".
It's not just now that should be worrying, it's the continuation of the trend. And a website as major as this within its domain is one of the few that has more than a snowball's chance in Hell to divert said trend, assuming it acts in a timely fashion. But this is just waiting around like a lobster in a pot of water being slowly heated.
Oh we probably agree more than disagree about the trend, and it's certainly on-topic for HN in the sense that stories about it and debates about it are welcome here in their own context. Choking other threads like weeds is another matter. We've noticed that becoming more of a problem lately, hence this post.
So is it acceptable to post separate threads about the topic of paywalls, then? Because if so, please make that explicit. At the very least, I did not get that impression, and reading through this thread it would appear I am not alone. And - assuming it is acceptable - how? Ask HN does not seem appropriate. Tell HN does not seem appropriate. HN doesn't generally have discussion threads on their own right. We are being told that other threads are not appropriate. The HN guidelines say "Please don't post on HN to ask or tell us something (e.g. to ask us questions about Y Combinator, or to ask or complain about moderation)." So where is appropriate, then?
Also, the reason why said discussions are starting to "choke other threads like weeds" is because it is rather hard to have a discussion about something when one has to resort to increasingly-complex and quasi-legal methods (if not downright illegal in some places) just to read the content people are trying to have a discussion about.
> ...The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time.
> This may on occasion cause the clock to be set backwards if the local clock time is more than 128 [m]s in the future relative to the server. In some applications, this behavior may be unacceptable.