Hacker News new | past | comments | ask | show | jobs | submit | dripton's comments login

Consumer Reports buys all the items they review, anonymously.

That doesn't stop them from doing questionable stuff and playing favorites. All this was aired publicly in the lawsuit Suzuki filed.

Yes, many people make many claims. You should think about which ones to believe.

i don't know how you can say they play favorites. internal memos show that suzuki knew that they had a rollover issue because of the narrow wheelbase and CR called them out on it through testing.

The vehicle proved to be equal or less rollover prone than the competition (especially the Bronco II which IIRC holds the record for the most rolled over vehicle) in actual service and per the stats compiled over the years by the NHTSA

So it really kind of begs the question what axe CR was grinding. In the lawsuit it came out that one of the writers managed to put it on two wheels incidentally not part of the tests and that they monkeyed with the tests they were running to try and replicate that.


Is that total rollovers or rollovers per mile? Because there were a hell of lot more Broncos on the road than Suzuki ever sold across their entire lineup.

We're talking about the Bronco 2 here, not the normal Bronco. Rollovers compared to production numbers. Someone crunched the numbers and IIRC it comes out to 20-something percent of Bronco 2s were rolled. I can't find those numbers but I did find that the fatality rate almost doubles the Samarui.

https://www.motortrend.com/features/ford-bronco-ii-history-e...

And I found this hilarious gem:

https://www.broncocorral.com/articles/ford-bronco-ii-rollove...

I don't think anyone would expect to do a 30mph J turn in anything except the most car-like of modern SUVs and expect to maintain upright. Perhaps getting away with that sort of stuff is a reflection of the kind of tires they had at the time.


I'm amused that the original ageist response ("old people suck") is left alone and the parody of the original ageist response ("young people suck") is downvoted. I would expect a bit better from HN readers, though any community that becomes popular enough devolves to average-at-best.


Thanks. I'm torn on a response. On the one hand, HN was always bad at reading between the lines - even quite broad lines. On the other hand, maybe I'm just not as funny as I think I am, and that's what they're downvoting.


Words great, until a page rejects email with a '+' in it.


Or just knows about this Gmail trick (it's been 20 years already) and sends spam to your real mailbox.

Actually, I am surprised _any_ spammy website these days would even honor the part after the +, and not just directly send to the real mailbox name.


I used to require a "+..." on all emails. Any email that didn't have the "+..." was sent to Spam automagically. My family were whitelisted. I gave up, because too many websites (early on) refused to take the "+..." marker, so I ended up losing too much to Spam. It's easier to just let Google sort it out.


Good resource on this trick from 2010. It's not Gmail specific.

https://people.cs.rutgers.edu/~watrous/plus-signs-in-email-a...


It's part of RFC 5233 Sieve Email Filtering: Subaddress Extension


Not everyone's cup of tea, but quite nice if one can afford it: I have my personal ___domain and a catch-all inbox. So if I want to register at acme-co.xyz I will just use [email protected]

Maybe I should start using random words though? Wonder if someone will go bananas seeing their brand's name on my ___domain.


Yeah, I've had to explain that a couple times already, usually when dealing with customer support or in-person registrations.

And a "malicious" actor can get away with pretending to be another company by spoofing the username if they know your ___domain works like that. I don't think this has reached spammers' repertoire yet, but I wouldn't be surprised.

Eventually I'd like to have a way of generating random email addresses that accept mail on demand, and put everything else in quaraintine automatically.


dots are ignored, can filter by [email protected]

not sure about capital letters


Sure they do. Agnes and Hugo both tracked quite a bit west, for example.


I installed Linux on a new laptop yesterday, and couldn't get either NixOS or Debian to install until I turned off secure boot. So I guess these distros don't bother getting every release signed by Microsoft.

At least it was easy to turn off. I just wish the error message mentioned Secure Boot -- it took me a few minutes to figure out what was wrong. At first I thought I had a corrupt USB stick or something.


There are two separate Secure Boot keys Microsoft uses: one which they use to sign Windows, and another which they use to sign everything else (the "Microsoft 3rd Party UEFI CA"). AFAIK, some recent laptops with Windows preinstalled come by the default with the second one disabled in the BIOS (it's a new Microsoft requirement). To install Linux on these laptops without disabling Secure Boot, you have to go into the BIOS and enable that key.


You don’t always have to disable Secure Boot; it usually works with just changing some “OS Type” from “Microsoft” to “Other”.


You can set up secure boot on NixOS with lanzaboote: https://github.com/nix-community/lanzaboote


A couple of examples would be reduction of some of the Reagan-era defense spending under the Clinton administration, and partial rollback of some of the Reagan-era tax cuts under the Clinton administration.

Of course these were not complete elimination of programs, but adjustments. And you could argue that there were other reasons besides partisanship, like the end of the Cold War and budgetary issues.


> reduction of some of the Reagan-era defense spending under the Clinton administration

...you mean when the USSR collapsed, and Cold War ended?


I'm just the opposite. One of the worst things about vacations was having to carry along all those books or take a detour to a bookstore (if there were any) to buy more. Now I just carry a single small e-reader. It's a great savings in terms of cargo space.

I don't consider an e-ink reader very complex. You charge it once in a while, download books to it once in a while, and otherwise it's basically a book except it remembers what page you were on.


Still waiting for 4:3 to come back, as vertical real estate is precious when you're coding. Not holding my breath though. The market has spoken, and the market appears to want screens optimized for watching videos rather than screens optimized for writing text.


A little vertical space is nice for videos too, cause often there's the video controls or some kind of bar above/below a video.


Export tariffs are actually unconstitutional in the US. https://en.wikipedia.org/wiki/Import-Export_Clause


Interesting.. the same section banned any limitation on the importation of slaves... at least that clause had a sunset date. Both clauses were basically: "don't touch our cash cow".


The price of consensus


Looking at that clause, it appears that it's only unconstitutional if the individual states do it. Doesn't say anything about the federal government or Congress. Or am I reading it wrong?


There are two clauses that ban export tariffs. One applies to states, the other to the Feds.


You can divide realtime applications into safety-critical and non-safety-critical ones. For safety-critical apps, you're totally right. For non-critical apps, if it's late and therefore buggy once in a while, that sucks but nobody dies.

Examples of the latter include audio and video playback and video games. Nobody wants pauses or glitches, but if you get one once in a while, nobody dies. So people deliver these on non-RT operating systems for cost reasons.


> You can divide realtime applications into safety-critical and non-safety-critical ones.

No. This is a common misconception. The distinction between a hard realtime system and a soft realtime system is simply whether missing a timing deadline leads to a) failure of the system or b) degradation of the system (but the system continues to operate). Safety is not part of it.

Interacting with the real physical world often imposes “hard realtime” constraints (think signal processing). Whether this has safety implications simply depends on the application.


Your division puts audio performance applications in a grey area.

On the one hand they aren't safety critical.

On the other, I can imagine someone getting chewed out or even fired for a pause or a glitch in a professional performance.

Probably the same with live commercial video compositing.


Audio is definitely hard realtime. The slightest delays are VERY noticeable.


I mean, it should be.

But there are plenty of performers who apparently rely on Linux boxes and gumption.


This kind of makes the same point I made though -- apps without hard realtime requirements aren't "really realtime" applications


No -- soft realtime applications are things like video conferencing, where you care mostly about low latency in the audio/video stream but it's ok to drop the occasional frame. These are still realtime requirements, different from what your typical browser does (for example): who cares if a webpage is rendered in 100ms or 2s? Hard realtime is more like professional audio/video recording where you want hard guarantees that each captured frame is stored and processed within the alotted time.


> who cares if a webpage is rendered in 100ms or 2s?

Do you really stand by the statement of this rhetorical question? Because if yes: this attitude is a big reason for why web apps are so unpleasant to work with compared to locally running applications. Depending on the application, even 16ms vs 32ms can make a big difference.


Yes I do, because I don't think the attitude is the reason, the choice of technology is the reason. If you want to control for UI latency, you don't use a generic kitchen-sink layout engine, you write a custom interface. You can't eat your cake and have it too, even though most web developers want to disagree.


The traditional language is "hard" vs "soft" realtime


RTOS means hard realtime.


I sense that people will insist on their requirements being hard unnecessarily... and that the bug is the fault of it being on a near-realtime system instead of it being faulty even on a realtime one.


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: