Tesla's Screen Saga Shows Why Automotive Grade Matters - <AUTHOR> https://www.thedrive.com/tech/27989/teslas-screen-saga-shows-why-automotive-grade-matters <comment><USER3> The first time I discovered automotive grade was when I was designing my own in-car infotainment system using a HTML based interface, a few years ago. It worked really, really well for a long time. And then, summer came, I got the magic smoke from my unit. Turns out, the amplifier IC died. But, I did more research as amplifiers were actually supposed to heat up and I had cooling fans in place. What killed it wasn't the heat, but the sudden variations in temperature - Eg. when you use A/C for a while and leave your car in the hot sun. The manufacturer literally recommended to use the automotive grade version of the IC for in-car usage. Silly me.

In the end, I never really got to finish the project because of the rabbit hole it became.

But remember, I'm a hobbyist. I have an electronics background, but that's about it. To see a huge gigantic company of this size and reputation pursue this kind of mistake that has real impact on paying customers is astounding. I mean, I like Musk and the work he's doing, but this doesn't seem right (just a personal opinion). I hope the customers don't have to bear this for Tesla's mistake.

<comment><USER4> > To see a huge gigantic company of this size and reputation pursue this kind > of mistake that has real impact on paying customers is astounding.

It's a conscious decision, probably due to cost/production volume concerns. Musk had pulled this kind of tricks before with lithium-ion batteries before (remember the early Tesla fires?), they were initially using consumer grade laptop batteries (with a highly energy density/weight ratio at the time but more prone to fire and explosion comparing to other manufacturer's automotive grade lithium-ion battery chemistry, granted Tesla might have improved.)

And honestly, the cost of automotive thermal grade 2 certified central display for 17-inch TFT screen was probably (still is I suspect) cost-prohibitive for a low margin auto industry.

What's really astounding to me is the "cabin overheat protection" feature. As the article pointed out, what this really is Tesla trying to prevent the non- automotive grade screen from failing, even though it's touting for protecting dogs and children at extremely hot summer days. It regulates the cabin temperature at +40C, but that's the temperature children's organ will start failing.

<comment><USER5> I used to work summers in the Caribbean - organs failing at 104 is a pretty much total lie

<comment><USER6> >organs failing at 104 is a pretty much total lie

Actually it is a very well recorded phenomenon. Just because you and the people you work with may have adapted well does not mean that it is universal by any means. People die in heat waves regularly; normally diabetics with peripheral neuropathy who can't sweat enough to drop their internal temperature or people with heart problems who can't take the additional stress of lowering their temperature. [1] [2] [4]

"Heat related mortality is similar in hot and cold parts of western Europe and in hot and cold parts of the United States. This implies that the populations of hot regions have adjusted by physiological or other means to their hotter summers."[3]

Also, the metric for organs failing at 104 is entirely correct, just not with regards to external body temperature. Your organs will undoubtedly fail if your _internal_ temperature is 104F/40C. I've had sepsis with a temperature of 40.9C and I would have died if it wasn't for quick treatment from the doctors.

Quick anecdote; if you're ever in the situation where your body temperature starts to get that high, scream and shout until you get an actual doctor on hand - I had nurses who had no idea of the severity of my condition and would have left me to die through shear negligence. I was lucky enough that the surgeon for my leg injury decided to check how it was healing, and rushed to call in a team of 4 or 5 doctors to stabilise me as I went into shock from hyperthermia. Spent the next 24 hours covered with cold towels and ice swapped out regularly by some very apologetic nurses.

[1] [https://emj.bmj.com/content/22/3/185](https://emj.bmj.com/content/22/3/185)

[2] [https://news.nationalgeographic.com/news/2013/07/130716-heat...](https://news.nationalgeographic.com/news/2013/07/130716-heat- wave-dehydration-stroke-summer-sweat/)

[3] [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC192832/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC192832/)

[4] [https://www.medicalnewstoday.com/articles/320226.php](https://www.medicalnewstoday.com/articles/320226.php)

<comment><USER7> > Also, the metric for organs failing at 104 is entirely correct, just not > with regards to external body temperature.

Then it's not correct _in this context_ , where everyone else was talking about external temperature.

<comment><USER6> 104F external is still relevant in this context if we're talking about venerable people that can't regulate their internal temperature down from this; those being some children, elderly, diabetics, or pets. Their temperature keep rising until it hits this 104F. That's why I commented - it's not just semantics.

</comment></comment></comment></comment></comment></comment><comment><USER8> I used to work on MyFord Touch at Microsoft and this was a constant discussion. "Why do we have such terrible touchscreens, when Tesla has such great ones?"

I think Tesla made the right decision because while it's certainly costing them a lot of money to deal with, the screens in most cars (especially back then) were so bad that it probably would have been worse for their brand.

<comment><USER9> The swing of the article "Look we told you so" really rubs me the wrong way. But it seems to represent the view of a large part of the Automotive industry. Instead of driving innovation forward, they shy away of the problems that introducing such innovation could have. Instead it seems the industry relies on shaming innovators for the issues of first generation future tech. This reminds me a lot of Steve Ballmer mocking the first iPhone: [https://youtu.be/eywi0h_Y5_U](https://youtu.be/eywi0h_Y5_U)

The most likely outcome is that they will figure it out, and much earlier than any of their competitors.

<comment><USER10> Buying off the shelf parts is not innovation. Especially when they are not suited to purpose and you ignore the vendor's own reliability figures.

<comment><USER11> I agree, but I bet we begin seeing other car companies using large displays and suddenly display manufacturers will start selling properly-designed, large displays.

<comment><USER12> Well, just to be fair, that's something that would have happened with or without Tesla. You saw those prototype screens at auto shows like Detroit years ago. Crucially, the prototypes were all automotive grade.

In this case, Tesla simply wanted to be ahead of the curve. Worked for a while, then the known failure rate of the parts caught up.

Whether or not it was worth it depends on the strategic intent and whether or not that bet paid off. We'd really need more information to make that call. And Tesla is not going to give anyone on this thread access to the strategic and financial information necessary.

<comment><USER13> Most cars STILL have garbage grade(usability wise) ugly looking touchscreen interfaces, i think you over estimate tesla's competition

<comment><USER14> Yes, but this is the point - they stick to ugly looking touchscreens that are guaranteed to work. They could take screens from some tablet for few bucks, but they know that when they sell 100000 of cars and 20% would fail within two years it would cost them a lot to fix within warranty. If they start to fail after warranty, it would be huge impact on their good will and resale value on those cars would be damaged.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> SpaceX has had similar issues with using industrial grade parts in situations where their competitors typically use aerospace grade ones [1]. Although in their case the failures are a bit more visually spectacular than some yellow stripes [2]

[1]: [https://www.nasa.gov/sites/default/files/atoms/files/public_...](https://www.nasa.gov/sites/default/files/atoms/files/public_summary_nasa_irt_spacex_crs-7_final.pdf)

[2]: [https://www.youtube.com/watch?v=PuNymhcTtSQ&t=3m](https://www.youtube.com/watch?v=PuNymhcTtSQ&t=3m)

<comment><USER16> They did a whole batch of testing and a bunch of those struts failed at similarly abysmal fractions of rated load. Is that really "industrial grade"?

<comment><USER17> No, that's "a bad batch."

The issue here (as a sibling post points out) is QA.

<comment><USER16> And "industrial grade" includes parts where the manufacturing is that unreliable and nobody has tested them either?

<comment><USER18> As evidenced by that explosion, yes.

<comment><USER16> I don't see how the explosion helps distinguish between "industrial grade" and "below industrial grade"?

<comment><USER18> The distinction is between aerospace grade and industrial grade. Aerospace grade is definitely not "below industrial grade". Aerospace grade parts will be subjected to far more rigorous testing.

The problem SpaceX had was using industrial grade parts when they should have used aerospace grade parts.

<comment><USER16> The post I was replying to was making a distinction between aerospace grade and industrial grade.

I was looking at the details of the problem, and suggesting that those parts were _neither_ aerospace grade nor industrial grade, but something lower still.

Non-rigorous testing is a reasonable thing for "industrial grade". I am not convinced that being far under half of the rated strength is a reasonable thing for "industrial grade".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I have one of these yellow screens on my Model S. Tesla told me twice over the past 3 months they would be replacing it under warranty very soon. I'm disappointed to hear they're walking this back.

<comment><USER20> I also have a Model S with this occurring on my v2 MCU. I was told by a service tech they were collecting VINs, and would have a fix available this year. I opted out of arbitration when I took delivery of the vehicle, so I intend to sue in small claims court to have it replaced if Tesla does not perform the repair as a warranty claim. Waiting for a fix I'm fine with. Being stuck with it in a $100k car that is less than a year old I am not.

<comment><USER21> Honest question: I'm surprised at such a hard stance against what I perceive to be an "early adopter" product. Did you not feel that buying a Tesla was a gamble?

<comment><USER22> Being an early adopter generally means paying a premium price without a lot of confidence that the product will be as useful as it looks, or that any promised ecosystems will appear.

People who bought an iPhone shortly after launch paid $600 with no idea that the app store would appear and become what it did. For all anyone knew, the iPhone would go the way of the Newton or the Zune. Two years later, the same phone was retailing for $200 with a proven track record and an exploding ecosystem of apps.

What being an early adopter _doesn 't_ mean is that the item may not be fit for purpose. If early iPhones had never taken off, and the product line was cancelled, that's your bad luck; you took a gamble when you bought it. If the screens had just not been rated for mobile use and had leaked LCD fluid into people's pockets, that's _not_ part of the gamble.

Tesla's appeal to early adopters, but that's not an excuse for product defects.

<comment><USER23> > People who bought an iPhone shortly after launch paid $600

I remember paying $300 at launch I think...that was the AT&T locked one but back then it was easy to unlock.

The $600 ones weren't available until much much later when they started selling off contract unlocked phones directly.

<comment><USER24> The 4GB iPhone 1 was $499, with contract. The 8GB iPhone 1 was $599, with contact. A few months after launch they lowered the price by $200 and gave store credit to the people that paid the higher price.

<comment><USER25> It was £99 iirc in the UK but you had to get it activated in-store for a seriously pricy contract. Until somebody worked out how to jailbreak it, at which point it was the bargain of the year.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Apparently these Teslas log to the eMMC so much that after a few years the part wears out. The screen goes black and the car falls back into limp mode.

[https://www.youtube.com/watch?v=o-7b1waoj9Q](https://www.youtube.com/watch?v=o-7b1waoj9Q)

<comment><USER27> I saw that as well and I find that scarry. Something so basic that should never happen. I wonder what else was ignored or mismanaged and might kill someone one day.

<comment><USER28> >I wonder what else was ignored or mismanaged and might kill someone one day.

[https://i.redd.it/kv4y1j3gjut21.jpg](https://i.redd.it/kv4y1j3gjut21.jpg)

 __This WILL kill someone. __It 's not a question of _if_ , it's a question of _when_ , and it's _intentional_.

Maybe the people responsible for that decision will see the inside of a jail cell, or maybe they won't- but the fact of the matter is that the presence of this "feature" is negligence at best, much like this case where bricking your car when something unrelated to its core functionality dies.

<comment><USER29> I researched Tesla's "bricking" and not starting after seeing that image on reddit. Turns out it can't happen while driving and means something failed mid upgrade while the car isn't in use.

Maybe I'm wrong, but the Telsa forums were absolutely livid when a poster used the word brick. His car was in state where it couldn't start or upgrade again.

<comment><USER30> >Turns out it can't happen while driving and means something failed mid upgrade while the car isn't in use.

Are the upgrades user initiated? I've had (or seen) enough productions and live events degraded or interrupted by the windows autoupdater to be terrified of the idea of "isn't in use" updates.

<comment><USER29> From my limited Telsa knowledge they were user initiated and your able to decline them. Meaning, you wouldn't be stuck at the store if you come outside and all of the sudden your car has to update.

Perhaps some updates need to be done overnight?

</comment></comment></comment></comment></comment></comment><comment><USER31> It's not surprising they had problems with a large screen. Large multilayered sandwiches of different materials have thermal expansion problems. Not everything will expand at the same rate, which means internal stresses as temperature cycles. Large size means the difference in length across the longest dimension will be much larger than for a small device. This breaks bonds and seals.

Solar panels have the same problem, and they have "expansion joints" to deal with it.[1] Hard to do that for one seamless screen.

[1] [https://www.pveducation.org/pvcdrom/modules-and- arrays/therm...](https://www.pveducation.org/pvcdrom/modules-and- arrays/thermal-expansion-and-thermal-stresses)

</comment><comment><USER32> I've long wished for a "slot your iPad in here" solution for this sort of thing. Sure it might not stand up to automotive grade punishment, but you can remove it when leaving the car in the sun and if it breaks it is easy to replace and much cheaper than custom parts (thanks to Apple's economies of scale).

<comment><USER33> I've worked on "Bring Your Own Device" concepts together with Honda.[1] There are plenty of wins for consumers in this type of setup.

Automakers have taken notice that people are using their phones for an increasing share of infotainment functions.

The tough, time-consuming parts are working through the supply chain to build out the connectivity and "happy coexistence" of phone and car. Also, I've yet to find a UX which blends physical, voice, and touchscreen controls while accounting for their strengths, weaknesses, and learnability. Tesla included.

1: [https://www.youtube.com/watch?v=OnMwI6SGAOg](https://www.youtube.com/watch?v=OnMwI6SGAOg)

<comment><USER32> Cool! That's pretty much exactly what I'm imagining, except tablet sized instead of phone sized.

</comment></comment></comment><comment><USER34> Cars are a tough environment for electronics. Asides from the other examples mentioned in the article, my Ford's monochrome non-touch LCD turns into an illegibly garbled mess in the cold (below -20°C) until the car warms up.

<comment><USER17> I've seen this same effect a lot when talking about Teslas. Any failure on their part is instantly chalked up to alleged poor practices, laziness, and general lack of care or professionalism, whereas an identical failure on the part of an established manufacturer is shrugged off as "oh well, sometimes parts fail."

(Take the issue with fires, for instance - Teslas catch fire far less frequently than conventional cars, but every time it happens it's global front-page news.)

<comment><USER35> True. But another Tesla burst into flames in Hong Kong: [https://qz.com/1618627/a-parked-tesla-model-s-burst-into- fla...](https://qz.com/1618627/a-parked-tesla-model-s-burst-into-flames-in- hong-kong/)

Parked gas cars don't usually burst into flames.

<comment><USER36> > Parked gas cars don't usually burst into flames.

Usually not, no. But every now and then, they do, just like electric cars. It's hard to say which type of vehicle burns down more often, the sample size is small and there are so many more petrol powered cars than electric powered cars.

Electric and petrol powertrains have different failure modes. An electric car can fail while being parked, which is less likely to happen on petrol cars (and if so, it's usually caused by an electrical failure in the car). However, petrol powered cars have a higher chance of bursting into flames while in operation due to the compination of high temperature components and pressurised fuel being close to each other.

A car (being petrol or electric) has a high density energy storage. Whenever that enegry can no longer be contained, bad things happen. Personally, I'd prefer my car burning down while being parked over bursting into flames when I'm driving it.

</comment></comment></comment></comment><comment><USER37> The Tesla Model S we've had since 2015 hasn't had any problems with its screen, despite being driven in California. This article's conclusion was strange. Without that Touch Screen, none of what makes Tesla a Tesla would have been a problem since it would have been controlled with un-upgradeable knobs, switches and buttons.

I agree with the comments here that Tesla should make it right for the customers though.

<comment><USER38> Do you park it in a garage or out in the sun?

<comment><USER37> Garage mostly, but not exclusively. I have never worried about this.

</comment></comment></comment><comment><USER39> Great article. These appear to be the exact kind of engineering lessons you would expect a new company like Tesla to learn the hard way. And it explains why incumbent car manufacturers might seem less innovative on the surface.

</comment><comment><USER40> Tesla may not be the greatest company ever, but it's certainly not a fraud. I think we should move on from that point if view. The I immense pressure from shorters and fossil fuel lobby should have destroyed Tesla by now. But here they are, surviving. If Tesla were to go bankrupt this year, I would still call it a successful company.

<comment><USER41> The problem is that there's a massive gulf between fraud and successful company. If Ford put Tesla's display in their latest vehicle people would be going nuts about the fact Ford shipped such an unreliable item. Tesla has essentially made the calculation that they can ship a sub-standard product and cut corners. This is exactly the same attitude the early years of Uber had. They'll certainly get away with cutting these corners in the short term, but in the long term it's dishonest and it's not a sustainable way of doing business.

<comment><USER42> >Tesla has essentially made the calculation that they can ship a sub-standard product and cut corners

Do you know that almost all (if not _all_ ) other auto-manufacturers made the calculation that they better lie to their customers about the emissions coming out of their cars?

Who's really cutting more corners?

</comment></comment></comment><comment><USER43> Read to the final paragraph:

> In fairness, other automakers have had issues with touchscreens as well. > Just last year, Ford settled a class action lawsuit over a host of problems > with its MyFordTouch systems and had previously extended warranty coverage > for its SYNC systems. Cadillac had to recently revamp its CUE touchscreen > system after numerous issues including "the dreaded spiderweb cracks." But > [like, it's totally different for Tesla for reasons not having anything to > do with screens or reliability][1]"

Basically, screens suck. Everyone's screens break. Apple and Samsung have shipped junk screens too. But _Tesla 's_ bad screens are an existential crisis. The auto industry hates them so much...

[1] Paraphrased.

<comment><USER44> >Basically, screens suck. Everyone's screens break. Apple and Samsung have shipped junk screens too. But Tesla's bad screens are an existential crisis.

All screens suck but only one manufacturer put their entire control panel in the screen... so yeah...

<comment><USER43> Right, so the whole "...shows why automotive grade matters" is a complete fabrication. All screens suck. The article spends a ton of words on why the particular panel Tesla picked was bad just to take it all back and pull a switcheroo to a _design_ critique instead. In the last paragraph!

That's not honest journalism.

<comment><USER38> What you're saying is several out of hundreds of different automotive grade screens had problems too. And one out of one non-automotive grade screen (Tesla's) also had problems. Not a large enough sample size, but things look statistically better for the automotive grade ones.

</comment></comment></comment></comment><comment><USER45> If you google the authors name "Edward Niedermeyer", you can find out that he has a history of bad-mouthing Tesla in a long series of blog posts. So I would take any allegations made by him with extreme care.

<comment><USER46> He bad-mouths everyone. He's an analyst, not a cheerleader.

<comment><USER45> Which means, that his publications shouldn't be mistaken for journalism.

</comment></comment></comment><comment><USER47> > ...despite the fact that it held the temperature at +40C which is about the > temperature where a child's organs will start shutting down...

I've been in hotter places than that as a child and my organs are still functioning. Not that convincing a tale, got to be honest.

<comment><USER48> That is the internal body temperature at which the organs will start shutting down, but external (e.g. cabin) temperature can obviously go higher without issues. Kind of disingenuous from the author.

</comment></comment><comment><USER49> So Tesla is selling:

\- electric vehicles

\- long range

\- self driving

\- big screens

I really wish they or somebody else focus on just the first two parts - <USER2> range electric cars. No need for the AI or other fancy stuff.

<comment><USER50> Do you think that by not giving a large touch-panel display, the car with become more efficient?

<comment><USER49> It will definitely have one less problem as the article points out.

I also have a small touch infotainment screen in my car. Works great for calls, music and navigation - that is all what I need it to do. I have not had a single problem with it for about 4 years.

</comment></comment></comment><comment><USER51> I called Tesla service in December because of both displays delaminating. They said they'd call me back, which of course they never did. This explains it, I guess.

</comment><comment><USER52> A car with any kind of touchscreen for anything but non-essential functions is a huge red flag for me. Because of the mandate for backup cameras, and the dash space that the display for those takes up, I think I'm going to have to stick to pre-2018 model years for as long as they let me.

I think it is incredibly unsafe that things like heat and radio controls have been shifted to non-tactile touch inputs, rather than analog buttons and knobs. But I am an old fogey that keeps at least one hand on the wheel and my eyes on the road.

<comment><USER53> That's what steering wheel controls are for.

<comment><USER54> Maybe. Depends on how modal they are.

The primary issue with touch is the difficulty many people have using it by feel, and or "muscle memory" alone. Typically, one needs to identify the UX element desired, then touch, and then often verify the thing happened or select after that.

Where it is modal, another whole layer of that interaction is needed, and or driver needs to retain more state info. "Which screen is it on, and is it currently available for me to use?"

Steering wheel controls can be better, but many of those do toggle through various modes and the driver needs to glance at a small screen in the dash cluster.

Doing that is generally superior to a touch only UX though.

On many cars, low importance functions are clumped into these kinds of UX. Higher order things get their own control.

I drive a lot of different cars. New, old, and Tesla.

I thought the Tesla was spiffy, but did not think much of the big touch panel for reasons I have given here.

My very favorite drives are on cars with great controls, and all of it working with dim interior lighting. Just enough to see what needs to be seen, the rest easily operated in a tactile way, night vision intact.

This is not to say touch is not useful in cars.

I think it can be and is.

This is to say touch has a very long way to go before it begins to seriously challenge well designed buttons, levers and switches.

</comment></comment></comment><comment><USER55> The problem with this article and many others on similar subjects is that there isn't any real information about the prevalence of the problems that they describe. Without that it's pretty much just angry bluster whether they are describing problems in a Tesla or a Mercedes.

Is it one screen in a million that fails or one in ten? There is no way of telling from the article.

<comment><USER56> As Tesla has only manufactured 150-200K Model S's to date and the article cites multiple owners, you can definitively say the observed failures are not one in a million.

</comment></comment><comment><USER57> What's the argument against just relying on "cabin overheat protection" to keep the climate in spec? Seems like that would solve a lot of their supply chain limitations at once with relatively minimal battery drain - though it does seem wasteful to spend energy keeping electronics comfy in the sun.

<comment><USER58> I have a different issue with the "cabin overheat protection": claiming that it is to "protect dogs and children" when, even if working as intended, it could allow a car to reach a temperature dangerous to children, is highly irresponsible -- even if Tesla also said that you should constantly monitor the temperature to ensure that it is safe. There's no justification for this sort of dissembling.

<comment><USER59> Cabin Overheat Protection is separate to Dog Mode.

If you want to express outrage about abdication of responsibility at least be talking about the relevant feature.

Cabin overheat protection is there to protect things left in the car like electronics, and theoretically requires no user interaction.

Dog Mode allows the user to dial up the desired temperature and then walk away. This is the actual dangerous feature, because the belief is that the air conditioner will keep the temperature at the level you want it. This despite a history of at least one police dog dying every month in the USA due to equipment failures, and theirs dog cars have specially modified environmental controls to maintain and monitor the temperature, including opening windows as a last ditch temperature control effort. Even those systems fail sometimes.

And here is Tesla setting people up for failure using a single air conditioner that is monitored remotely using an internet connection that is flakier than filo pastry.

<comment><USER60> The temperature is tracked locally, I assume you mean if the AC fails it notifies you remotely?

It is a good question if, while in dog mode, if the car detects the temperature exceeds the set point, will it lower the windows or try to notify the owner?

Leaving your dog in the car for an extended amount of time is not a good idea, and in many places is illegal. And yet, sometimes the safest place for your dog is in the car.

Personally I haven't used it yet, but I like the option of a big display showing the interior temperature of my dog is in the car without me for a few minutes.

<comment><USER59> Yes, monitored remotely through the app on your phone, which may or may not reflect the actual environment in the car at that moment.

FWIW is typical failure mode for an air conditioner is for the condenser to fail, so the conditioner ends up over-heating air that hasn't been cooled by the condenser yet, resulting in the interior temperature hitting 60C in minutes, so eg a police dog (typically a large-ish dog like German shepherds) will be dead or dying when you come out to check on it fifteen minutes later.

The systems used in police dog vehicles include redundant components, temperature monitoring and emergency actions like opening windows to allow cool air to flow. Police around the USA still lose about one dog a month with those specialist systems in place.

It's only a matter of time until someone posts on the Tesla reddit that the car killed their dog and the fans will dogpile on the poster telling them it's their fault for leaving the dog in the car in the first place.

<comment><USER16> > so the conditioner ends up over-heating air that hasn't been cooled by the > condenser yet

Does that happen when you have no engine?

<comment><USER59> Resistive heaters and heat pumps.

</comment></comment></comment></comment></comment></comment></comment><comment><USER61> This person has taken the wrong lesson from the story. The actual moral of this story is that the auto industry is too conservative and being a little less conservative allows you to build one of the best cars in the world.

So a few touchscreens have yellow lines. The Tesla touchscreen is still clearly better than any other car's touchscreen and if they'd done it this guy's way they wouldn't have been able to ship it at all because the part simply wasn't available then.

<comment><USER62> Sorry, but if you're going to design a car that replaces not just the infotainment system, not just the climate controls, but _the entire instrument console_ with a touchscreen, then it would seem to me one of the places you absolutely do not want to cut corners on is...the touchscreen.

"One of the best cars in the world" is obviously subjective, and there are some ways in which Tesla is absolutely leading. But all of the innovation on display in Teslas don't earn them a free pass on build quality issues.

<comment><USER60> Is it fair to say they "cut corners"? They bought the best screen available at the time at size they wanted, and then tested it in-house. It's not like the screen has terrible specs, but it is not rated to operate at 130°C.

So they tried adding software to keep the cabin below 50°C even when the car is parked, but either it doesn't work all the time or people turn the feature off, of someone is parked in the sun long enough to run the battery below 20%.

The trade off was a higher rate of warranty repairs in order to build the car they wanted to build.

I think in the case of the Model 3, partially how they solved it is through special glass they used above the front seats. I've been wondering why the glass is so unique above the front seats but not the same tint for the rest of the roof glass. It's very interesting — water droplets on the glass above the front seats look almost blood red. Now I'm guessing it's filtering to block IR or other solar gain which might otherwise burn out the screen.

[https://images.app.goo.gl/DBaQeKoWkWTGYqk76](https://images.app.goo.gl/DBaQeKoWkWTGYqk76)

<comment><USER62> According to the article the screen has _good_ specs -- but it doesn't _quite_ meet even the lowest-quality rating for automotive screens, and that sure seems like it's the proximate cause for the thermal failures they're experiencing.

I'm not sure whether it's fair to say they "cut corners," but I'm not sure it's _not_ fair. The other alternatives could have been finding a supplier willing to work with them on an oversized screen that met at least Automotive Grade 4 standards, or being willing to redesign the instrument panel to take a smaller screen. (Or two smaller screens.)

</comment></comment></comment></comment><comment><USER63> I have an iPhone 6 which once had a third-party screen installed to replace a cracked one.

The replacement screen looked great at first - indistinguishable from the original one.

But over time it has developed exactly the same issue: a yellow band/border/ring around the outside of the screen. I wonder if this is a wider issue within the LCD industry, rather than just being specific to Tesla.

<comment><USER64> Yes, it's an issue with oxygen and moisture sealing the edge of the screen.

The yellowing will happen to all screens eventually, just heat speeds it up a lot.

</comment></comment><comment><USER65> I hope that Tesla's attitude to using robust engineering principles does not end up causing large amount of injuries or deaths. It is not just in the cars that they produce, it is also the way their factories are run as well.

</comment><comment><USER66> Can somebody point to a definition of the word "Saga" that isn't ... related to vikings? I see it more and more and it's confusing me.

<comment><USER67> What's confusing? Sagas were long, epic stories and now we use the term colloquially (sometimes hyperbolically) to describe complex events that occur over a long period of time.

</comment></comment><comment><USER68> I think traditional car manufacturers just don't advance the state of the art in screens and other in other in-car electronics at a pace fast enough. They are content with shitty 7 inch screens with faded colors, since their supplier told them this is the best that can be done. You need someone like tesla to force screen suppliers to catch up to the best screens, do the required testing and make the best screens capable of withstanding heat and shock. It's the same with the concept of an electric car and the concept of self driving.

<comment><USER69> Ah yes, forced modernization, and the users are the beta testers of all this.

Sorry to all the yellow screen owners who won't get them replaced, and RIP that dude that crashed into the concrete barrier.

<comment><USER70> [https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...](https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in_U.S._by_year)

<comment><USER69> Such a cheap rebuttal, and a misuse of numbers. Did you know pedestrians and motorbikes are included in that stats? "But the numbers!"...

[https://medium.com/@MidwesternHedgi/teslas-driver- fatality-r...](https://medium.com/@MidwesternHedgi/teslas-driver-fatality- rate-is-more-than-triple-that-of-luxury-cars-and-likely-even- higher-433670ddde17)

Whatever the numbers it's managed to save, Tesla's buggy self-driving software has killed a few people for sure. How would you like that seal of approval on your product?

</comment></comment></comment></comment><comment><USER13> All i know is that now when i see a car without a massive touchscreen in it i end up thinking "really? in 2019? what should i pay 80 grand for a backwards POS?"

now i know why these screens aren't more prevalent but still...tesla's dashboard looks superslick

</comment><comment><USER71> I think this is fine if the failure to success ratio is low for the parts. Especially given that the failure here refers to failing pixels and doesn't compromise safety.

Some quick math, if an industrial part costs $10, and an automotive part costs $20, then for ten cars you save $100. Assuming that 20% of all your cars are faulty, that's a $80 savings translation. With the remaining money, you could spend $40 on R&D for a screen at the same price point with higher reliability and still come out on top. However, at some point, you will reach a time where the number of replacements that don't justify the design. For a bootstrapped company, I don't think it's a bad bet, but it is time critical to find an alternative before they start losing money.

<comment><USER72> While this might be true, you then possibly have a very noisy 20% previous customer base who may or may not buy your car again, and if noisy enough might convince others your designs are shoddy and are not worth the premium price tag you're trying to sell them for. Brands are not worth nothing.

<comment><USER71> Agreed, that this may not be a win for brand loyalty.</comment></comment></comment>


A2-class microSD cards offer no better performance for the Raspberry Pi - <AUTHOR> https://www.jeffgeerling.com/blog/2019/a2-class-microsd-cards-offer-no-better-performance-raspberry-pi <comment><USER2> A2 needs support in the Linux kernel. It's not there, yet.

[https://github.com/ThomasKaiser/Knowledge/blob/master/articl...](https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)

"A2 promises even better performance with 4000/2000 read/write IOPS minimum but there's a problem since as outlined by the SD Association A2 cards show "much higher performance than A1 performance by using functions of Command Queuing and Cache".

Cache and Command Queuing require host (driver) support since the host needs to activate those new features first. The cache feature on A2 rated cards makes use of volatile RAM on the card requiring the host to learn new commands to issue flushing the cache (involving the risk of data losses -- for details see especially chapter 4.17 in Physical Layer Simplified Specification 6.0)"

<comment><AUTHOR> So is there any kind of device able to use A2 cards at the rated performance yet? I can't get anything better on my Mac with multiple readers (USB 3.0 and 3.1), and I'm guessing if I tried on the reader in my 1 year old Dell XPS, I'd get the same.

What good is a performance designation (A2) if no device in the real world supports it?

<comment><USER2> I don't know. It's a bit of a bummer.

I imagine Android would benefit the most (and phones also don't suffer from sudden power outages, which is the biggest risk with enabling this), so someone may try looking if mmc core in androind kernel has patches to support this.

<comment><USER3> My phone will reboot randomly; depending on what layer the reboot happens at, there may be no flush command sent to the card.

<comment><USER2> No worries, I checked it a few minutes ago, and android doesn't support this either.

</comment></comment></comment></comment></comment><comment><USER4> I'm surprised we haven't seen a smaller than M.2 form factor for SATA on embedded devices. It seems like the big limiter on devices like the Raspberry Pi and others are the sd cards/emmc modules, since the amount processing power and ram have been continually going up.

If you need disk performance on the Pi 4, wouldn't it make more sense to only keep the kernel,initrd on the sdcard and mount the primary filesystem off a USB3 device (like an mSATA-2-USB enclosure), that is if you have the space to spare for it in your project/enclosure?

I did something similar with one of the SolidRun devices, but I had to scuttle it due to other hardware problems:

[https://penguindreams.org/blog/review-clearfog- pro/](https://penguindreams.org/blog/review-clearfog-pro/)

<comment><USER5> General practice in embedded is to avoid writing to disk as much as possible. Data collection is mostly done by sending it to the cloud for storage there. However 'edge processing' and 'edge storage' are hot topics, so there will probably be more work in this area. Some of the surveillance camera vendors are showing interest in this, since it would be beneficial to reduce data needed to be sent. Especially since vast majority of the data is never looked at, or only looked at once (human/machine event detection). But one has the (fundamental?) problem that the sensor is often installed in an adversarial environment. Would be sad to try to pull data after a crime, only to realize the camera storage was destroyed.

<comment><USER5> Many embedded applications are also not particularly form-factor constrained. A good security camera lens is often easily bigger than a couple of 2.5" hard- drives and a medium sized single-board computation. Heck, just wiring boxes for an industrial sensor system, are can often bigger than 10s of 3.5" disks.

<comment><USER6> > Many embedded applications are also not particularly form-factor > constrained.

just because the overall package is large doesn't mean the embedded designers are allocated a large portion of that.

and the upstream suppliers are always going to be pushing to be a bit smaller, so they can fit into more things, and get more sales.

</comment></comment></comment></comment><comment><USER7> I appreciate you doing these tests, this (and your last article) instantly answers my question about _" how will this perform in one of my rpis?"_. Please keep doing them as new cards(with their marketing claims) are introduced!

</comment><comment><USER8> How about lifespan? I fail to understand why SD card have such a short lifespan, and it's the sole reason I won't acquire an RPi.

It seems that the only think that is lacking on RPi is flash memory storage. Most smartphones have a lot of it, and it seems that 1GB of storage would be enough for the RPi and would not necessarily be so expensive.

<comment><USER9> FWIW, only noname and Sandisk cards have given up the ghost on me. Samsung Pro & Evo cards have been doing just fine. Other than that, you just need to worry about getting proper power. Just use the official power supplies, and you're fine.

Also eMMC chips are no magic. There are crappy ones and good ones. Guess which ones you're going to get for little money?

<comment><USER10> Proper power is essential. A phone charger is not a power supply even though it works. I suspect a lot of SD cards are getting undeserved blame from a PSU issue.

<comment><AUTHOR> This is my experience. The only time I had an issue with corruption (using over 60 different microSD cards through 7 years and maybe 50 or so different Raspberry Pis) was when I used a little .5A microSD AC adapter that came with some cheap battery powered device that broke.

I have not had any problems when using a reliable power supply. I'm guessing the 'endurance' or 'industrial' cards some people claim are lifesavers are just doing something to guard against flaky power input when doing reads and writes, so it masks the issue.

</comment></comment></comment></comment><comment><USER11> Looks like I'll keep booting my pi's from usb attached storage. At least with the Pi4 USB speed improvements should be nice.

<comment><USER12> I didn't even know you could do that! Any idea if it works on the pi4 or not? The docs don't mention it.

[https://www.raspberrypi.org/documentation/hardware/raspberry...](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md)

<comment><USER13> just a guess but s/he may have been referring to just putting root filesystem on a USB drive, but still requiring the bootloader (and possibly kernel?) to be on sd card. It's a one-time "hit" that is completely negligible.

<comment><USER14> That's the present situation and I've used it before. Some recent Pis can boot directly from a USB drive without the need for a bootloader on the SD card. That's still in the works for the Pi 4 as I understand, but network boot (PXE?) will come before that.

</comment></comment></comment></comment><comment><USER15> The major problem is not disk write speed, which we can all agree sucks, but longevity and lifespan when used as a system boot disk and also containing /var and similar. The write wear leveling on a u3 microsd card is nowhere near as good as even a $50 consumer class ssd.

Small single board computers should move towards m.2 2280 nvme drive support, or at least one sata 6 gbps interface.

<comment><USER16> SD card performance on the Pi <4 is so poor (and the bandwidth is shared with the USB controller anyway, I think) that you might as well use an attached USB hard disk; even for booting.

Jeff's benchmarks are accurate in my experience. If you try saving single images from a camera at even 5-10fps, the card quickly bottleneck and you start dropping frames. If you buffer and store (in my case 16-bit raw), you can essentially saturate USB bandwidth if you're also using a USB camera.

<comment><USER17> No, the bandwidth isn't shared as both sd controllers (sdhci and sdhost) are directly accessible using MMIO (and DMA).

<comment><USER16> Thanks for clarifying that, I was never sure.

</comment></comment></comment></comment><comment><USER18> Support for booting from SSD should solve the SD issues before too long.

<comment><USER19> why things on the RPi take so long? is the SoC still undocumented because of the NDA as before?

</comment></comment><comment><USER20> Very glad I took your recommendation from your previous article on the Evo cards for my new RPi4s! kudos and thank you sir!

</comment><comment><USER21> SD is a garbage spec. Arasan IP for SD host (in Raspberry SoC) is trash. Driver support is minimal. What'd you expect?

</comment><comment><USER22> sd card performance specs are all a joke.

they are "at most" some speed. What even is the point of writting such spec?

the car analogy would be if you measure some car going down a hill (doesn't even matter if tumbling and killing everyone inside), measuring that it was 300mph and then advertising it as "speeds of 300mph!!!"

<comment><USER23> Also how ISP speed is measured ;)

<comment><USER24> Advertised, not measured.

And it's not like that everywhere, the UK has started what I hope develops into a trend: [https://www.bt.com/broadband/deals/](https://www.bt.com/broadband/deals/)

<comment><USER25> The UK has to do that because the fastest widely-deployed internet connections available are VDSL2. DSL connections in general are relatively unreliable, and speeds vary wildly depending on a variety of factors, most importantly the length of the cable between you and your cabinet/exchange. Australian folks may chime in here with tales of their DSL connections dropping out during heavy rain, when their telephone junction boxes fill with water and short out.

If the UK had deployed fit-for-purpose tech like Fibre-To-The-Home (FTTH), there would be much less need for the UK's advertising regulations. (Obviously speeds are never guaranteed on residential connections, but advertised fibre speeds are a much more accurate predictor of internet experience than DSL or cable.)

"But", you might say, "that BT page is advertising 'Superfast Fibre'!". Well, yes, in the UK it is legal for telcos to lie to their customers. When they say fibre, they mean Fibre-To-The-Cabinet - and VDSL the rest of the way. Would anyone call their 3G mobile service "Superfast Fibre" because the tower is fibre-fed? No. For whatever reason, though, this is totally okay in the UK.

<comment><USER26> On the flip side, in the early 2000s Bellsouth (now AT&T) deployed FTTP in much of the Southeast and would convert that to ADSL to plug into existing house POTS wiring. It was sold as ADSL at 12mb/s. There was literally no other internet option available from them at the time either.

<comment><USER27> And here I am, an hour ouside the city and would gladly pay 150/mo for half that. But noone can, or cares to, deliver.

</comment></comment></comment></comment></comment></comment><comment><USER28> Doing god's work

</comment><comment><USER29> Testing microSD card speed on a Mac is rather pointless because performance is (severely) limited on the Raspberry Pi through it's terribly slow interface, not necessarily the actual card.

Remember RPi 1-3 use a plain SPI interface, and even the new 4 only has UHS-1.

<comment><USER30> He explained in the article why he did this: to check if the manufacturers claims are incorrect, or if its a RPi hardware issue.

<comment><USER2> It's neither.

<comment> 867-5309 it's clearly the former.

<comment><USER2> Manufacturer's claims are not incorrect. OS vendors just didn't intoroduce support yet.</comment></comment></comment></comment></comment>


Principles we use to write CSS for modern browsers - <AUTHOR> https://gist.github.com/alekseykulikov/68a5d6ddae569f6d0456b0e9d603e892 <comment><USER2> A bit meta, but I need this off my chest: I love how this document starts off saying "this is for react apps". IMO every discussion about CSS coding standards needs to start with context.

A lot of old CSS lore came from people who build websites. I mean those fairly uninteractive things, focus on content. Blogs, restaurants, newspapers.

Building an application that happens to use the DOM as their UI toolkit is totally different. The whole "reuse the same classes but with different content" thing that CSS classes were designed for becomes less important, and "reuse pieces of _behavior_ " makes a lot more sense.

There's probably more domains or subdomains that warrant their own CSS best practices. But I'm totally tired of a blog designer and a react app coder fighting on HN about how the other one is doing it wrong, when really they're just solving different problems.

<comment><USER3> Well said. This goes (probably double) for the similar conversations about javascript, where lots of people question whether it should be used at all, which is a reasonable question for _sites_ but not for _applications_.

<comment><USER4> Those people probably have static content sites with lots of js on their mind when they say that, no? Ads, tracking code, etc....

<comment><USER3> I think they probably do, which is why I really liked the parent comment about how people should be clear about what they're talking about so that we stop talking around each other all the time.

</comment></comment></comment></comment><comment><USER5> IMHO, naming conventions such as SUIT, BEM, OOCSS and the like are NOT a good practice, but merely a workaround for dealing with the limitations of a global namespace.

My preferred solution are CSS Modules[1], Vue's scoped styling[2] or something similar.

[1] [https://github.com/css-modules/css-modules](https://github.com/css- modules/css-modules)

[2] [https://github.com/vuejs/vue- loader/blob/master/docs/en/feat...](https://github.com/vuejs/vue- loader/blob/master/docs/en/features/scoped-css.md)

<comment><USER6> CSS Modules is still a "naming convention," just one that is auto-generated for you. Naming conventions in CSS are as much of a good practice as naming/linting conventions in JS.

<comment><USER7> Auto-generation is a good solution because names are the brain's interface to the code. If the names are auto-generated, and the brain doesn't have to look at the auto-generated names, and the abstraction doesn't leak, then you can consider the problem solved.

<comment><USER8> My devtools still doesn't show me the unmangled name. The abstraction leaks.

As a practicality, I prefer the naming conventions to the CSS processing pipeline, because it gives me a much better ability to debug and iterate.

<comment><USER9> With sourcemaps you can get close, but it still shows the "mangled" class name in the HTML.

But with a dev/prod environment, you can have your cake and eat it too (for the most part). In dev we have our classnames be in the format of `[classname]---[file-path]---[filename]---[partial-hash]` So one of my classnames from a current project is `.container` in the file, but shows up as `.container---src-components-scanner----styles---1446d`. And in production shows up as `._1533JgnvGu096C2bCAkrxT`.

</comment></comment></comment></comment></comment><comment><USER10> Some thoughts:

\- Good CSS design needs zero !important statements. Fix your specificity or your component architecture if you have a need to use !important.

\- DRY is a good thing, not a bad thing. Maybe straight CSS isn't quite there yet but...

\- Why not use the tools at your disposal to aid in development (and DRY) such as SASS/LESS?

\- Flexbox will be great once IE dies the well-earned death it deserves.

I'm very happy the author had great success with their setup. What works, works. But I hesitate to assume that just because it works without using DRY principles or other tooling, it means you shouldn't.

<comment><USER11> > \- Why not use the tools at your disposal to aid in development (and DRY) > such as SASS/LESS?

Because there is so much tooling churn + barrier to entry. The point is that sometimes it's better to repeat yourself than to use the tool of the month.

<comment><USER12> Both the tools mentioned above LESS/SASS have been for 5+ years. There is churn in frontend tooling, but it is not a valid reason for not using LESS.

</comment></comment></comment><comment><USER13> ".ComponentName-descendentName" nested inside ".ComponentName"?

Remember kids, the cascade is TEH B4DZORS - so always include everything you would have gotten from it in every class name. _headdesk_

Solidly delivered on the "no DRY" premise. Maybe they should coin a new acronym like "WET": "Write Everything Thrice"

<comment><USER14> CRY: Continuously Repeating Yourself

WET: Write Everything Twice

Credit: [https://roots.io/sage/docs/theme- wrapper/#fn2](https://roots.io/sage/docs/theme-wrapper/#fn2)

:)

<comment><USER15> WET is standardly 'Write Every Time'

</comment></comment></comment><comment><USER16> A random brain dump prompted by this statement: "No DRY. It does not scale with CSS, just focus on better components"

All programming involves resolving a conflict between two different principles and a lot of the fiercest disagreements are between people that weight the importance of these two things differently:

1\. Reducing repetition

2\. Reducing dependencies and side effects

The language and it's tooling/ecosystem can affect the importance of these.

The project's complexity, rate of change and lifespan is also a factor that might push you one way or the other.

But anything that helps one of these harms the other.

Thoughts?

<comment><USER5> I wouldn't say that they are always mutually exclusive. I think there is a variable ratio between advantages gained by 1. and disadvantages caused by 2.

In other words, at first, reducing repetition will net nearly no negative results - you just recognise different areas that do very similar things and write a common functionality. The most basic example would be programming languages providing standard libraries, even though everything could be done with regular operations. At this point, abstractions are even simpler to use than implementing things yourself.

Problems start to arise once you hit a certain point beyond which your abstractions become harder to use and maintain than simply writing things multiple times. This is where you should stop abstracting/modularising things away (assuming that the reason is purely overengineering, not _bad_ engineering).

</comment></comment><comment><USER17> > Flexbox is awesome. No need for grid framework;

Yes, great, if you can ignore all the IE users. Is that what "modern" means?

I'd love to use flexbox where I work, but it's just not feasible to give up all the customers we would lose.

<comment><USER18> Why not both? Global flexbox support is >96% and in the US it's >97%.

Unless you're aiming for a 1:1 pixel-perfect experience in crappy old versions of IE, it's negligibly simple to detect IE (or lack of flexbox support), and just use something else. You can usually get pretty close to a lot of flexbox layouts with display: table and related properties, and also falling back to floats for others.

In a worst case scenario, you can provide old IE with a more mobile-like experience and just let things stack up.

<comment><USER19> Enterprise in the US. IE9 still rules, in many cases. I actually work all over this space, do not tell me otherwise. And now I have to maintain two codebases?

<comment><USER20> Been there, done that. But you might mention to bosses/clients that MS no longer supports/patches anything older than IE-11 on desktop versions of Windows. They are most likely using an un-patch-able version of Explorer.

Virii, Trojans and Hacks, oh my!

[https://www.microsoft.com/en-us/WindowsForBusiness/End-of- IE...](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support)

<comment><USER21> My work "upgraded" to IE 11 late last year. The problem is so much of our internal infrastructure was built to target IE 8 (or earlier) that when our information services guys deployed IE 11 they forced it to run in compatibility mode.

Now you have to go through this endless dance of Enable/Disable compatibility mode depending on what site you are trying to visit. We have a lot of non technical users so as soon as you ask them to delve into menu options to use some added functionality on a site you lose them.

Even technical users hate this so most people sideload chrome. However a large number of workstation are locked down and those people have no option but to continue with IE.

</comment></comment></comment></comment></comment><comment><USER22> Plug for test-driven CSS: [https://github.com/jamesshore/quixote](https://github.com/jamesshore/quixote)

I've experimented with it on a green field project and got promising results. Found I could refactor my CSS with confidence.

</comment><comment><USER23> I agree with the Flexbox and DRY principles, but it's weird to still rely on arbitrary naming conventions like SUIT when CSS modules have been around for a while now.

Naming things has always been difficult, especially in CSS where it can lead to merging/overriding/precedence issues. _Not_ having to _think_ about what CSS class names are either available or possibly conflicting is a benefit from CSS modules that increases productivity by an order of magnitude I've rarely seen in CSS, especially in large codebases.

You've got a button and want to call it "button" and style it using ".button"? Go ahead. It will only inherit styles if you _explicitly_ say so. The global namespace remains healthy for each component you write.

</comment><comment><USER24> Personally, I very much dislike using CSS classes unless required. I prefer having a clean markup with classes used only where they make sense.

For a context, I somehow can't wrap my head around writing something like:

when `<nav>` makes more sense. Sure, if you have a case with alternate "inverse" navbar, go ahead with a class `<nav class="inverse">`.

About the flexbox, ah, well, even now they have undefined behaviour on several elements such as a `fieldset` [1].

[1]: [http://stackoverflow.com/questions/28078681/why-cant- fieldse...](http://stackoverflow.com/questions/28078681/why-cant-fieldset-be- flex-containers)

<comment><USER25> These days using "nav" instead of
 is the preferred method by default. The other two classes are just modifiers that may or may not be required. There's nothing wrong with them.

Also, I see "fixed" bug reports in both Chrome and Firefox when using flex with fieldset. To be fair, recent fixes.

</comment></comment><comment><USER20> FWIW, I'm using Angular (1.x) on a project at work, rather than React. One of the things I did recently was take the CSS file used in the project ("Few Pages App", rather than SPA, which _had_ a common .css file), and turn it into an Angular (javascript) "directive".

I wish I had done this earlier. I have no "compile" step, it's just straight js plus the framework. However, I now have a mechanism to use variables for any (new) stuff with repeated settings, inserted into the rest of the text in the "" template.

</comment><comment><USER26> I've developed my last 5 projects (corporate websites with many different layouts) with SASS + Foundation 6 an no naming convention. Instead I relied on nesting selectors.

I can behave and usually not go deeper than 4-5 levels. It's a really neat way unambiguously tell a CSS rule where it should belong to. For example I can create a

        section.hero-block{ /* things inside are scoped */ }

CSS selectors who live outside are pretty basic, utility style ones, they exists on one level, so they can be easily overwritten by the scoped ones if needed.

<comment><USER27> This is how I've developed projects for the past two years. Every module is scoped. If it needs variations but contains the same HTML structure - it gets a modifying class (.full, .half, .side, .footer, whatever)

If it has a different HTML structure - it is a different module entirely: `.module.v1` VS `.module.v2`

Doesn't matter if 85% of the CSS is shared between v1 and v2. If the HTML structure is different, it is a different version of that module. If you can run a diff checker and return 100% the same HTML structure but you need a different coat of paint, you add a variation class. _All modules begin as a "v1"_. This prevents it from needing to be added to the scope selector if a "v2" is ever added. I've yet to work at such a scale where the loss in CSS performance was a problem.

Utility and State classes live in global space. Global being defined as anything unscoped, not "everything in CSS is global space". Since everything is scoped - I can safely reduce selectors. Very rarely does it go more than 3 levels.

I use some level of OOCSS but don't use it for things like `.floatLeft`. If it is a style I will want to _remove later_ , typically for responsiveness, then I don't want a class `.floatLeft` that is really `.floatNone` at a certain size. I would rather take `.item` and change `float: left` to `float: none` with a media query.

</comment></comment><comment><USER28> So, I don't do any front end work in my day-to-day, so this may be a stupid question. This article starts out with how CSS gets a lot of negativity. What alternatives are there? Do browsers understand anything but CSS for styling?

<comment><USER29> There isn't an alternative really. Like Javascript, it's all there is.

<comment><USER28> So are these other tools people are talking about some different methods that just transpile back to CSS in the end or something like that?

<comment><USER15> Yep (such as LESS, SASS, SCSS, etc)

</comment></comment></comment></comment><comment><USER30> I think an important thing to note here is that this individual's team is very small. If you have a small team that closely collaborates then scaling things which take discipline (like CSS) becomes vastly simpler.

CSS is difficult because it takes so much effort to do things the "right" way. It requires a good set of linting and testing tools or constant vigilance to maintain a correct, robust system.

As the codebase or team grows the difficulty of that task increases. That, to me, is why CSS often viewed in a negative light.

<comment><USER25> I believe you could say the same for a large number of coding languages out there.

</comment></comment><comment><USER31> Recently I got into functional CSS:

[https://github.com/chibicode/react-functional-css- protips](https://github.com/chibicode/react-functional-css-protips)

<comment><USER32> At that point you might just go full css-in-js and embrace inline styles.

I'm not sure which is worse:

A) having twenty classes on each element, each doing only one or two things

B) having twenty classes overlapping on the same one or two things

<comment><USER25> I would say both A and B are incorrect.

</comment></comment></comment><comment><USER33> Funny how all the original markup and languages are becoming the machine code of the web. No one writes js anymore, just compiles into js. No one writes css anymore, just SASS -> css. Html? Nope, directives or shadow dom.</comment>


Google Cloud starts charging for public IPv4 on January first, 2020 - <AUTHOR> https://cloud.google.com/compute/network-pricing#ipaddress <comment><USER2> And Google Cloud doesn't support IPv6 on GCE instances or VPCs on January 1, 2020.</comment>


The first plain JavaScript plugin that can add drag-and-drop sorting to your table - <AUTHOR> https://github.com/sindu12jun/table-dragger <comment><USER2> Nice! but what's up with all the devDependencies?</comment>


How (!not) to make a 404 page - <AUTHOR> http://www.bloomberg.com/2010-12-01/galaxy-leads-casino-operators-higher-after-macau-revenue-surge

<comment><USER2> What? Bloomberg's 404 pages are _awesome_! Also see [http://www.bloomberg.com/politics/404](http://www.bloomberg.com/politics/404)

Their 500 pages are just as wacky:

[http://www.bloomberg.com/500](http://www.bloomberg.com/500) [http://www.bloomberg.com/politics/500](http://www.bloomberg.com/politics/500)

<comment><USER3> He said he liked it: "How not not to make a 404 page" ;-)

<comment><AUTHOR> @mahouse, i edited the description in light of the new information. What he pointed out here was perfectly right (at that time instant)

</comment></comment></comment><comment><USER4> This was posted here 9 days ago => [https://news.ycombinator.com/item?id=9013890](https://news.ycombinator.com/item?id=9013890).

Consensus is that Bloomberg's 404 and 500 pages are quite awesome.

</comment><comment><USER5> As a vehicle for getting word of their site redesign out its clearly been pretty effective. I mean I literally learned Bloomberg redesigned their website from an art blog of all places, and this is the second time its been on the HN front page now. This is a 'how', not a 'how not'.

<comment><AUTHOR> I totally agree @at_10. Have updated the title to reflect that.

</comment></comment><comment><USER6> I can already see Error-Page-As-A-Service as the next big business model.

<comment><USER7> Status pages as a service already exist.

</comment></comment><comment><USER8> If it hadn't been like this for a while, I honestly would have thought that bloomberg.com had been hacked and defaced. Consider this recent article about Radio Shack: [http://www.bloomberg.com/news/features/2015-02-02/inside- rad...](http://www.bloomberg.com/news/features/2015-02-02/inside-radioshack-s- slow-motion-collapse)

</comment><comment><USER9> It's probably down to Bloomberg hiring this guy: [http://www.businessinsider.com/bloomberg-hires-bi- executive-...](http://www.businessinsider.com/bloomberg-hires-bi-executive- editor-joe-weisenthal-to-host-new-tv-show-2014-10?IR=T)

The new site is a visual abomination with articles having titles designed as link-bait, similar in style to Business Insider.

<comment><USER10> No it's not because of that hire--the devs at Bberg are just an interesting, surprisingly eclectic, smart bunch.

The new layout... there were discussions about that after it launched. I was also opposed.

</comment></comment><comment><USER11> WTF...! It's Awesome! WTF happens to the avatar though? It looks like it's going to jump but then falls to pieces. I wouldn't say this is the best way to display a 404 page, however I agree it's nice to see a big corporation making light of an error.

</comment><comment><AUTHOR> OP here Didn't know they had a panache for awesomely creepy Error pages. Seems to fit in with their personality, in which case, the title of the post is my bad.

Anyways, I came across this while trying to resolve their archive page links, which seems to be broken, possibly after they changed everything to businessweek.com Although a small tweak to the url can get you to the article, a better tweak takes you to this gem of a 404! :)</comment>


Show HN: Sql Data Viewer (Free) – my first attempt at a product offering - <AUTHOR> https://blog.timwise.co.uk/2017/11/18/looking-for-beta-teste...
I hope you find this useful / interesting. I've not shared this on any sites like this before so I'm a bit nervous! <comment><USER2> Some very random comments:

– Although not intended to be a viewer tools like your product, you might get some good (and bad) ideas about UI/UX by taking a look at PHPMyAdmin [1];

– the pages don't declare any character encoding settings and language is declared on `html` tag. It won't be a bad idea to check some of i18n good practices [2][3]. This is specifically important for the non-latin script content you know the language of them [5]

– be prepared for bad parameters passed [4];

– some field types (like date/times) could benefit from reformatting in the UI for readability and time-zone-awareness;

– use BCP-47 language codes; `zh-Hant` vs. `zh-cht`

– some minimal effort on typography.

[1]: [https://demo.phpmyadmin.net/](https://demo.phpmyadmin.net/)

[2]: [https://validator.w3.org/i18n-checker/check?uri=demo.sqldata...](https://validator.w3.org/i18n-checker/check?uri=demo.sqldataviewer.com%2Ftables%2FSalesLT.CustomerAddress%3F_rowLimit%3D100#validate- by-uri+)

[3]: [https://www.w3.org/International/techniques/developing- specs...](https://www.w3.org/International/techniques/developing- specs?collapse)

[4]: [http://demo.sqldataviewer.com/tables/SalesLT.Customer?_rowLi...](http://demo.sqldataviewer.com/tables/SalesLT.Customer?_rowLimit=999999999999999999)

         http://demo.sqldataviewer.com/tables/SalesLT.Customer?_rowLimit=999999999999999999999

         http://demo.sqldataviewer.com/tables/SalesLT.Customer?_rowLimit=-100

[5]: [http://demo.sqldataviewer.com/tables/SalesLT.ProductDescript...](http://demo.sqldataviewer.com/tables/SalesLT.ProductDescription?ProductDescriptionID=1888)

<comment><AUTHOR> Thank you so much for taking the time to look and provide this superb feedback. I'll work through it and I'll see what I can do! You have no idea how much it means to me to get my first feedback from beyond my direct contacts.

Do you have any thoughts on whether you would have a use for it in any of your work? Is there a particular feature that's missing that is a showstopper for you? Or is there some other reason you wouldn't use it?

Thanks again!

<comment><USER2> You are very welcome.

The use-cases for such a tool, as you mentioned on the website, is when the user doesn't want to get involved with a querying language like SQL. I somehow disagree with the premise that writing SQL is "tedious and low value", specifically for a generalist software engineer. So although I'm not an ideal user for your product, but I could imagine a whole category of users who might need to find data in an instance of SQL Server (or any other RDBMS). Putting myself in their position, what I would like to have in such a tool is:

– not only use the full power of browser (tabs, etc.), but also benefit from code which runs on client-side and improves the interactivity of the tool; i.e. more JavaScript to allow users to dig and drill deeper into the data without leaving the page or even the browser tab. The foreign key reference is a good example for that.

– export the data I'm looking at for further processing and filtering in an spreadsheet; integration with in-browser spreadsheet tools such as Google Sheets would also be nice.

– improved UX; e.g. I know that the links in "referenced by" column of `Customer` table should point the address, etc., but the presence of the link doesn't necessary mean that there is a recorded address for a customer. The user shouldn't have to click on the link and open a new tab just to find out that there is no address for a customer.

\- allow the user to save their customized views of tables or joins and come back to them easily; e.g. she is the head of customer support for your company and doesn't want to see `PasswordHash` and `PasswordSalt` for the customers. All she needs to know is a view into this table with customers' contact information or in more advanced use-cases, number of orders in the past year for each customer in a separate column.

\- more advanced users might like to be able to pass SQL through your tool and get the results as the table format offered.

Hope these help.

<comment><AUTHOR> That's very useful! Thanks again for your generosity with your time.

I'll change the text about tedious SQL to something else, you make a good point. What I had in mind is where someone without access to the db has to ask a dev or dba to run a 'select * from xx' for them. Most SQL work certainly has great value and is far from dull!</comment></comment></comment></comment>


Catalina is checking notarization of unsigned executables - <AUTHOR> https://lapcatsoftware.com/articles/catalina-executables.html <comment><USER2> I guess the list of things keeping me off catalina (and, by extension, new Mac hardware) just got one item longer.

I recently bought a new System76 laptop as a stopgap, but it might end up becoming permanent. Kind of a sad end for 25+ years of Mac use.

<comment><USER3> My 16" is a huge disappointment. After swearing off Intel PCs after a disaster ours X1 Carbon, I switched back to a 2013 15" until this month. Figured after six months bugs would be ironed out. Wrong. I'm seeing two major glitches that have macrumors threads dozens of pages long: 1) with an external display connected, dGPU utilization shoots up to 20W at idle. (The rest of machine draws well under 10W at idle.) That wouldn't be a big deal if the CPU and GPU didn't share a tight 70W power budget. 2) when connected to an external monitor or dock—I've tried two different TB3 docks—the machine kernel panics regularly, usually waking up from sleep.

I'm torn. I don't want to return the machine because everything else is crap. At least the 16" works well as a laptop so long as you don't plug anything into the ports. But Apple's Q&A has seriously gone down the toilet ever since Steve Jobs died. Clearly him throwing staplers at people was the glue holding Apple together.

<comment><USER4> My partner is a graphic designer who loathed her 13" macbook that her work got her. She finally got an upgrade to a 16", i9, 64 gigs of ram.

It runs adobe software like total shit.

I think it's something to do with Catalina + accessing files in Google Drive File Stream + Adobe.

It runs illustrator horribly.

It's basically the saddest thing I've ever seen.

I think I'll get her a 17" XPS for christmas this year.

<comment><USER5> For what it's worth, I have _never_ had good luck with "big vendor" software (like Adobe) and using any sort of synced cloud-based filestore. I have had untold issues with things and as soon as I moved files local, everything magically went away. Might try that!

<comment><USER6> You can also set the relevant folders to keep the files always available offline.

</comment></comment></comment></comment></comment><comment><USER7> This must be a blacklist, since it doesn't block my own random scripts which it has never seen before.

If it's a global blacklist on apple servers, it should instead be downloaded to the client, and be a local blacklist.

Too big? Use a bloom filter. Now you only end up keeping less than one byte per blacklisted item. Update the bloom filter with an autoupdater. Any positive hit you can check against the server just incase it's a false positive.

<comment><USER8> Doesn't a blacklist also work only until the malware authors figure out how to randomize 8 junk bytes every time they serve an executable?

<comment><USER9> That's the crazy thing about this. There's already obfuscation techniques against hash blacklists, so what is this even for? There's no earthly way apple security engineers didn't know that. So what is actually happening?

My guess is that it's strictly for banning app store apps that they pull from the app store, but would like also to cripple retroactively on installed machines. But that doesn't explain why it had to run against random shell scripts? This is all still confusing. We don't have all the info.

</comment></comment></comment><comment><USER7> So you're telling me that every time I install a program in OSX, it pings apple to let them know what program I'm installing, my IP address, my location, and my OS version?

Sounds very Orwellian for a privacy focussed company...

<comment><USER10> No, that's not what he's telling you. You're getting ahead of yourself with your question. He's telling us that macOS will consult with Apple regarding the "fingerprint" of an executable when you run it.

<comment><USER7> But the fingerprint of photoshop is the same for everyone. If apple knows what the fingerprint of photoshop is (which they could easily find out), now they have a giant list of who installed photoshop and when, and from which IP address, and which IP location.

That data would be a wet dream for some IP lawyer looking for pirate copies of software...

<comment><USER11> The Photoshop binary is signed (presumably; it's been years since I last ran it), so this check would NOT be conducted.

Edit: What I should have said is that the binary is signed, notarized, and the notarization stapled to it, as described here: [https://developer.apple.com/documentation/xcode/notarizing_m...](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow?language=objc)

<comment><USER12> The author of the article mentioned explicitly that he signed a binary, and the check still occurred.

<comment><USER13> Did he staple the notarization though? They are 2 separate steps.

</comment></comment></comment></comment></comment></comment><comment><USER14> The article mentioned at the beginning is already discussed here: [https://news.ycombinator.com/item?id=23273247](https://news.ycombinator.com/item?id=23273247)

</comment><comment><USER15> There is so much confusion here. The OP and most others are missing one of the biggest points: Look at the packet trace. There is _no data_, not even a hash, being sent. It's a TLS negotiation and then the connection ends. I have to suspect it's a bug...

<comment><USER16> I'm not sure what you're seeing, but that's not what I'm seeing. When I Wireshark both app notarization and script notarization, I see 2 packets of encrypted Application Data sent to Apple (567 and 101 bytes), and 1 packet of Application Data (varying length) returned from Apple, in each case. What do you see when you trace a regular app notarization check?

<comment><USER15> This is odd, my proxy doesn't seem to show this. I will try to load my root cert into Wireshark and check.

Edit: Checked and double checked: When I run a new shell script, syspolicyd just makes a connection with no application data

<comment><USER16> I'd recommend trying this: Download a notarized Mac app, delete any stapled notarization ticket (.app/Contents/CodeResources), and then trace the launch. What do you see, and does the system let you open the app? Does it say it checked for malware?

<comment><USER15> Ah I see, looks like we're not running quite the same experiment. I suspect that anything including an app bundle ID is going to see some more interesting traffic.

<comment><USER16> Don't suspect, test. ;-)

I'm running both experiments. I've tested and compared script notarization to app notarization.

You're getting apparently unusual results with script notarization. So the natural next step would be to compare against app notarization.

<comment><USER15> Agh, I think it was cert pinning. Looks like the connection is terminated if you're snooping. I see the same results as you now. Thanks!

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I can't reproduce the exact test specified in the article:

      $ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
      $ time /tmp/test.sh && time /tmp/test.sh
      Hello

      real 0m0.016s
      user 0m0.002s
      sys 0m0.010s
      Hello

      real 0m0.006s
      user 0m0.002s
      sys 0m0.004s

I don't believe the 0.01s difference is long enough, and could easily explained by filesystem caching. The article says:

> Some people try to explain away the delay, e.g., "I would put the 300 vs 5 > ms down to filesystem caching", but such hand waving doesn't stand up to > further scrutiny.

...but does not provide any "further scrutiny", so for me, occam's razor applies.

<comment><USER18> A few ideas:

1\. confirm the checks are enabled:

        spctl --status

2\. Make sure your terminal/shell/etc aren't already exempted System Preferences > Security & Privacy > Developer Tools.

3\. If you already ran something that could generate a check in the last minute, the connection is still open. Most of the overhead people are recording is negotiation/handshake. If you're fairly close to the server, it seems plausible your observed time could be enough for the communication minus the negotiation. You can open Console.app and search `process:syspolicyd` in the device log to see the entries for the negotiation; wait for it to terminate.

4\. Try removing and re-creating a new file as in the test you did before and check it a little more directly:

        spctl --assess -v --ignore-cache --no-cache /tmp/test.sh

If it's working, you should see a log entry with the text "summary for task success" in it with a detailed breakdown of the request (times taken per phase, bytes sent/received, etc).

<comment><USER19> I don't have a system to check this on, but Apple seriously named an option "asses"?

<comment><USER18> Ha, no. I'm the ass, here. Fixed :)

</comment></comment></comment></comment><comment><USER20> It has to be said: if Apple published their source code, we wouldn't have to rely on reverse-engineering and speculation.

</comment><comment><USER21> Little Snitch is a god-send for users of MacOS, be they voluntary users or forced into using it because their employer won't allow them to use anything else.

<comment><USER22> I've found Objective-See's LuLu to be even better in catching every application and obscure binary daemon that ever makes a connection to the network and allowing me to set a temp or permanent block/allow rule for it - and it's FOSS. Try it out:

[https://objective-see.com/products/lulu.html](https://objective- see.com/products/lulu.html)

<comment><USER23> I didn't know about LuLu, thanks. I'm trying it out now and it's not been too bothersome (so far), which is always nice. I used Little Snitch for a few years but not only was it always in my face with the pop-up dialog (poor UI choice) but because it uses plist files for its database it became _incredibly_ slow. Had to give up on it.

I tried Murus/Vallum[1] too for a while but it was still a bit too complicated and demanding. There's still a space for a firewall with a decent UI available.

Won't be a Mac for me after this machine though.

[1] [https://www.vallumfirewall.com/](https://www.vallumfirewall.com/)

</comment></comment></comment><comment><USER24> What's the exact data being sent?

There is a lot of arguing going on here, but what is the data?

<comment><USER25> Seems to be a hash of the executable.

</comment></comment><comment><USER26> I am not sure of what is the whole point of this notarization thing. It would be great (ahem, let's say so) if there was a big and closed list of executables, but every shell / ruby / perl / python script can do many funny things, and you cannot notarize them all. Often, as in bash, by design. So?

</comment><comment><USER27> It's great tool for mass-surveillance. Since Apple has a database of all the apps the user has run on their device (but no worries, Google has the same).

For your security ;)

<comment><USER28> > great tool for mass-surveillance

It's not really that great for mass-surveillance. It "phone's home" only on first run. And it doesn't look like it sends data about your identity, device or location. They can have your IP address but another mechanism would be needed to relate that to you. (I doubt they are logging the IP address anyway. The only purpose would be to surveil you, but if they wanted to do that they would surely use a more capable mechanism . That makes keeping the IP addresses a burden and risk.)

<comment><USER29> >It "phone's home" only on first run.

Do we know that? The cache may well have an expiration date. Does the cache stay after an OS upgrade? I suspect further research will discover it's not just 'first time'.

>They can have your IP address but another mechanism would be needed to relate that to you.... if they wanted to do that they would surely use a more capable mechanism.

The app profile would already tell a great deal. Once enough of these 'non- capable' surveillance mechanisms add up, you end up with a very capable surveillance mechanism.

</comment></comment></comment><comment><USER18> late edit (2): added 3 notes including performance impact observation

I'm concerned about this behavior (both from privacy and performance perspectives), but I'm also not (quite) convinced this is working as described/implied here.

Before I get started: If you poke at this, open Console.app first. You can see recent logged "assessment" checks logged in "Mac Analytics Data" with the search "process:syspolicyd". You can use the same search to watch log messages (including all of the TLS negotiation etc.) for the checks in the device log.

The part that seems weird is that, if it is transmitting a hash (which seems possible/logical) the caching behavior doesn't appear to care or respect it?

The article suggests the following test:

        echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
        time /tmp/test.sh && time /tmp/test.sh

I tried this test and got real runtimes of 0m0.289s and 0m0.006s. Then, I changed the file:

        echo $'#!/bin/sh\necho Hellok' > /tmp/test.sh && chmod a+x /tmp/test.sh

When I re-ran the script, both runs are under 10ms. The content changed, but it didn't bother re-checking. I wrote the original script to a new file path:

        echo $'#!/bin/sh\necho Hello' > /tmp/test2.sh && chmod a+x /tmp/test2.sh

This ran with runtimes similar to the original (0m0.232s and 0m0.006s). Same content, new path, new check. Here too, if it cares about the hash, it either isn't bothering to use it for caching decisions or the hash includes the path.

Then I tried rming the file, writing it again, and running it. Once again, it checks on the first request. I think this suggests it may be caching the result by inode? The author said they saw new checks after saving changes in TextEdit--I don't know much about TextEdit, but I'd guess it is doing atomic write/rename here.

Other random details I noticed:

1\. it holds the connection open for a minute, presumably to minimize connection overhead for executions that'll generate many checks. My first checks were all in the 280-300ms range, but I tried one additional check within the minute and it only took 72ms. Making multiple requests in less than a minute may make it harder to notice

2\. The device log has a "summary for task success" entry with pretty precise timing details on all parts of the request.

3\. On my system, each of these attempts produces a "os_unix.c:43353: (2) open(/var/db/DetachedSignatures) - No such file or directory" error in the log from the libsqlite3 subsystem after the response comes back.

4\. The "Mac Analytics Data" log entry for each request has a good summary that looks like:

        assessment denied for test.sh
        com.apple.message.domain: com.apple.security.assessment.outcome2
        com.apple.message.signature2: bundle:UNBUNDLED
        com.apple.message.signature3: test.sh
        com.apple.message.signature5: UNKNOWN
        com.apple.message.signature4: 1
        com.apple.message.signature: denied:no usable signature
        SenderMachUUID: ...snip...

5\. When I add Terminal to the Developer Tools exemption on the privacy tab it does appear to kill the check. I'm not sure if there's genuine protection this check provides at some level, but I'll be considering adding either Terminal or at least some specific build tools to the exemptions I add on a new system.

6\. After adding the Developer Tools exemption, if you have the app open, it'll ask if it can quit it for you. I took the hint and restarted Terminal. It'll do the same thing when you remove it from the list. But I didn't see the checks actually return until I rebooted. Also, my system froze during reboot. Hopefully a coincidence. :)

7\. To put a better number on how this performance impact can compound for the kinds of builds I do all of the time, I ran `nix-build ci.nix` in the local directory for one of my projects before and after enabling the Developer Tools exemption for ~/.nix-profile/bin/nix. The run took 1m22s before, 45.5s after.

8\. Looks like this is the same check as is run by `spctl --asses -v <path>` (at least, per the Console.app logs). That may make it easier to play with.

<comment><USER16> > I think this suggests it may be caching the result by inode?

You may very well be right. I used TextEdit simply because it was easiest for me to guarantee a new notarization check every time, but I don't know the exact criteria that macOS uses to identify an executable as "the same". There's probably some combination of path and/or inode in addition to the hash.

</comment></comment><comment><USER30> Does anyone know if adding the Apple domain in question to piHole (or your hosts file pointing to 0.0.0.0) will suppress these checks?

<comment><USER21> If you're on MacOS, you want Little Snitch installed at all times, even if you have a pihole: a process that is denied network access is far stronger than juping DNS requests.

</comment></comment><comment> david-cako macOS has quite a few built-in antivirus features:

[https://support.apple.com/guide/security/app-security- overvi...](https://support.apple.com/guide/security/app-security-overview- sec35dd877d0/1/web/1)

IMO, you have to pick a security vendor to trust (only as far as you can throw them). Apple is incentivized to provide better end-user experiences as a matter of having end to end authority for their products. They've built a robust (albeit prescriptive) security/sandboxing ecosystem to avoid just pointing at software vendors if a customer is unhappy.

I like these features, but the fact that they're not always optional is frustrating. Note also that soon macOS will be running on Apple ARM SoCs; similar trade off.

Buy any other computer, and you now have Microsoft or Google, a CPU vendor, a consumer hardware vendor, and possibly also an antivirus company installing background services.

</comment><comment><USER31> I'm still trying to understand what the problem here is.

Nobody seems to have an issue with checking this for apps -- it's a good security feature to protect from malware, right? And which everyone knows about? And it only happens the first time you run something, so it's not a performance issue in everday usage.

And the article even states that there seems to be a valid reason for checking shell scripts, because they can be used to compile malware.

The original complaint was about slowness, but how often do you run something for the first time? The only scenario in which I can imagine this would become a practical peformance problem is if, somehow, you have an app that spawns new shell scripts all day long to execute, every few seconds, and a really flaky internet connection. Or new shell scripts hundreds of times a second, even with a good internet connection.

Is that something anyone ever needs to do? Programs can run shell commands directly, without a file, so it seems unlikely. Also, another comment here suggests that even if a shell script is modified, it isn't re-verified, so there would seem to be a trivial workaround _anyways_.

Or is the issue just that this is undocumented behavior? Or what am I missing here?

</comment><comment><USER32> Great! They can block malware as soon as they find out. Love it!

</comment><comment><USER33> Im running my dev environment in a OpenBSD vm. This makes me wanna use it for more stuff besides dev.

</comment><comment><USER34> Why don't companies come out and tell people what they're doing these days? Telemetry is getting to the point where people such as doctors and lawyers might be violating the law by using a modern computer. And people in the defense industry? Doesn't Apple employ thousands of forns? Who's audited their datasystems and ensured that this stuff stays private?

Much easier and better to just stop using it all and move to a system like Linux or BSD. 99% of people do everything in a browser these days anyhow.

<comment><USER35> If only moving to Linux were an option for everyone.

The other day I tried for the 100th time to move to Linux. I installed a recent build of a maintained, popular distribution (no it doesn't matter which one - I have tried them all), on hardware that is famous for it's Linux support.

Everything worked for a day and a half, then the sound just fucking died. No input or output.

I get millions of people use Linux daily, and are happy with it -- I'm genuinely grateful that's a thing. I would love to also use Linux, but I really don't have the time to diagnose why it broke yet again.

Any suggestions for people stuck on macOS? I guess I could block all Apple domains in my DNS resolver? Other than app updates, I can't think of anything that would stop working. That still sounds less painful than trying to deal with Linux's atrocious UX.

<comment><USER36> I had sound drivers die on me on famous brands laptops under Windows.

I had OSX lock up or lose any display on MBPs with NVidia chips.

On my wife's old windows desktop I had to plug a USB audio dongle, because of audio glitches.

Some of it is sloppy drivers, some, faulty or poorly designed hardware.

"Sound just died" is, unfortunately, not specific to Linux in any way.

<comment><USER35> Sure, though I am describing my latest attempt in like 15 years of using Linux on and off. At some point "every OS has its problems" just stopped being true for me.

Linux really sucks for anything other than servers. I hate to say that because I badly wish it weren't true, but it is.

<comment><USER37> How could it be any different actually?

A Linux conference is usually focused on the Linux kernel, drivers, filesystems, networking, more or less everything POSIXy.

If you want to learn about improvements at the UI level, there are XDG, GUADEC, Kacademy, each focused on their own silo, and other parts of the stack or UI tooling don't have any at all.

Meanwhile WWDC, Google IO, BUILD / Ignite are about all levels of the stack.

</comment></comment></comment></comment></comment><comment><USER38> I was watching a Linus YouTube video on the upgradeability of Alienware Laptops. So envious! Now you can't upgrade anything on the newest MacBook Pros.

[https://www.youtube.com/watch?v=J-RXqNafscs](https://www.youtube.com/watch?v=J-RXqNafscs)

And if something breaks on your MacBook Pro, most likely you will have to replace the entire motherboard or display.

PS: I own lots of Macs but sad to see the direction Apple is heading in.

</comment><comment><USER39> This is a specious problem _at best_. We have a very secure operating system doing things that others don't even try to do (notary) and we are complaining because our shell scripts take _n_ seconds to run? Really people? If you are running signed and notarized (stapled) binaries, the system never even reports them to Apple in the first place.

This is the height of insanity to think that Apple or anyone else would want this data or use it for some nefarious purposes...anonymous hashes of junk data are essentially useless outside of this purpose. It's fine to claim not to trust anyone for anything, but most of us aren't willing or able to build our own hardware, write our own operating system, and write our own applications. We have asked our vendors for devices and code that are more trustworthy, and when they give them to us we COMPLAIN about it incessantly. This makes no sense to me.

<comment><USER40> > We have a very secure operating system doing things that others don't even > try to do

Perhaps because such a system is extremely centralized?

> we are complaining because our shell scripts take n seconds to run?

Yes? If I buy a computer and it spends time doing stupid stuff, then I think I am fairly justified in being angry.

> If you are running signed and notarized (stapled) binaries, the system never > even reports them to Apple in the first place.

Great, let's notarize and staple tickets to every little piece of software you write…

> This is the height of insanity to think that Apple or anyone else would want > this data or use it for some nefarious purposes...anonymous hashes of junk > data are essentially useless outside of this purpose.

Executable hashes tell you if someone is running a specific piece of code.

> It's fine to claim not to trust anyone for anything, but most of us aren't > willing or able to build our own hardware, write our own operating system, > and write our own applications.

That's why I buy them from other people and would desire them to be good.

> We have asked our vendors for devices and code that are more trustworthy, > and when they give them to us we COMPLAIN about it incessantly.

How exactly does this make the device more trustworthy?</comment></comment>