bkdbkd

often my solution. I usually touch 'ForbiddenFolder', then chmod the file a-x.

Yes, this does not unclutter the home folder, but it does keep a program from touching places I don't want it to.

I don't care to have the machine rm -rf'ing on its own.

1. because they know better. You don't have to understand it, for them to be right.

This comes from their years of experience. When you also get those years of experience, you may come to similar understanding.

yes. and it's what I use every day.

the plan evil though.

Funny how a $20 cert is enough to prove identity and provide security for any domain on the web, but in order to run a calculator Apple hw, Apple HQ is the only entity on the planet capable of such complex security.

Contempt. use any apple device 2 updates back or more. you're screwed.

You would accept this in no other place in life, except that apple gives it for free, and puts a 'security' sticker on the box.

It's a racket. Planned obsolescence 2.0 - Users forced to update, update removes features, breaks working apps, breaks paid for ip ( literally removed from phones), apple blames the devs. bullshit.

All that, and not a single one here is surprised at zero days or trojans or malware that come right out of this process every week.

If it works, then why aren't we surprise when it doesn't?

Because we know it doesn't work.

It forces a change, where none is called for. Compatibility works both ways. What doesn't matter to me the lib dev, may for matter for someone else. The world is built on portable, flexible code, and pinning to something unnecessarily, breaks that one small part of the world. It's adding an unnecessary requirement. Life is hard enough.

Couldn't agree more.

that is not a thing. it's not how compilers work.

really really awesome.

Awesome. Well done.

"That 3000 dollar tool you paid us for? It's a brick." -Tim Apple

You might find the book: "Conceptual Blockbusting", James L. Adams helpful. It contains thoughts and activities that focus on the 'process of thinking' or problem solving. And how we go about characterizing a problem or situation.

One of the best I've read on how to think about thinking.

former Mac dev here, and completely agreed. Refactoring an app because someone else decided to change the language is a bridge to far. And if they do it this time, they'll do it again. Meanwhile the ObjC compiles.

--- Rant - With Swift Apple shifted dev power to themselves. Having gotten fat on the open world, they've backed away from every 'Open' technology they can, and replaced it with their own, ( presently all the way to CPU architecture). Yes, they are giving tremendous powers, but have they also crafted the One Ring.

I'm a sw eng. and sometimes I just need to hear the drums from "In the air tonight". Sharing in case anyone else does.

Yes, Great analogy. Remember the 2017 "Apple Commits to Pro Users" exercise? They flew reporters out for a boondoggle, gave them a tour of 'secret labs. With fresh competitive hardware coming 'real soon now'. Just spin.

https://daringfireball.net/2017/04/the_mac_pro_lives https://www.buzzfeednews.com/article/johnpaczkowski/apple-sa...

This ^^

So my carpenter should be happy to keep paying for his drill or his circular saw? He should be grateful for the subscription to the lathe that he inherited from his grandfather?

Andreas Spiess https://www.youtube.com/channel/UCu7_D0o48KbfhpEohoP7YSQ Small electronic projects, tutorials, and reviews for sensors, ESP8266, Arduino, Raspberry Pi, and ESP32

Adafruit - new stuff they sell, and tutorials that are fun.

TheCrafsman - a puppet learning how to craft, 3d print, mold, etc.

Bitluni's Lab - https://www.youtube.com/user/bitlunislab elaborate and funny tutorial videos about building gadgets.

Branchus Creations - board level repair for older PC's and gadgets https://www.youtube.com/c/BranchusCreations/featured

Choll W. Kim - Laser spine surgery and info https://www.youtube.com/c/ChollKimMDPhDSanDiego/about

David Bull - https://www.youtube.com/user/seseragistudio/ Tokyo-based woodblock printmaker, video presentations of his work, including a number of videos showing the complete process of making his prints.

Devoxx - developer tech events, talks, presentations https://www.youtube.com/c/Devoxx2015

Electronics Repair School - https://www.youtube.com/channel/UCooKQlg-HZ0PFAPc4Ymg3RA

Evil Ted - visual effects, prop., modelmaking from a pro.. https://www.youtube.com/user/evilted40

HomoFaciens - maker, elecronics https://www.youtube.com/c/HomoFaciens/videos

Jeremy Fielding - home engineering, learning, motors, robotics, making https://www.youtube.com/channel/UC_SLthyNX_ivd-dmsFgmJVg

Just A Printer - behind the scenes, explantation, at a small printing business https://www.youtube.com/channel/UCSuSPbvmwLZv9CMdeSsWkFA

Just have a think - Climate and Sustainable Energy, Technology discussion, education https://www.youtube.com/c/JustHaveaThink/videos

Kens Karpentry - garage builder, explains process, business https://www.youtube.com/user/ken311953

NorthRidgeFix - electronics repair. Often fixes without schematics, explains diagnosing and tracing faults. https://www.youtube.com/channel/UCLaXgfNlVxY149shiA1pykQ

SixtySymbols - cool videos about physics and astronomy https://www.youtube.com/user/sixtysymbols

Stock Markets With Bruce

The Signal Path - electronics tear down, analysis, and repair. https://www.youtube.com/user/TheSignalPathBlog

Two Minute Papers - video summary of interesting or exciting CompSci papers https://www.youtube.com/user/keeroyz

Exactly. It's a reasoning error.

They equate "Ensuring any recalled products remains off market" with "keeping formula off the market".

As you said, there are many cases in which it is far wiser stop to ensure safety, than to move forward with risk.

Well said.

exactly. "its not that the lock is insecure, its just that sometimes thieves figure out how to make keys."

Notarization is moving the problem to a different place, but not fixing the problem.

Imagine we take our city - Anycity, USA, where only good, trustworthy, and honest folk live, and we simultaneously decide to replace door locks with neighborhood locks.. then the city likes the idea and sponsors us to replace neighborhood locks with town locks - locks on the few roads leading in and out of town.

Now you start the see the problem. Yes we need walls, yes we need fences, and bigger walls, and bigger fences, and the city needs more authority, and then more authority. And we have to put much more trust in the city, but they really need it in order to keep us good and honest citizens safe.

By the way, what happens if a "bad guy" from Thosepeople, USA gets in disguised in a Minivan?

This is not a one-to-one analogy I know, but again, I hope it points out the innate problem with Notarization. It just moves that one problem to Apple's lap. Meanwhile creating several more innate problems.

iirc remote mouse & keyboard control was added recently.

In this interview Professor Kim Woo-joo describes a similar incident in Korea, where a choir contracted the virus. He adds that 5um is the min for 'droplet' infection, and that if the droplets remain airborne they can desiccate, and shrink , and then move from 'droplet' to 'aerosol'.

https://www.youtube.com/watch?v=gAk7aX5hksU&t=923s

Those crashes are like: You tell your machine to open the file with Emacs, but this new distro has unbeknownst to you (and you find out later, undocumented) symlinked the emacs command to a version of vim with a emacs-like overlay, because of some issue they had. The file crashes vim, but in a crazy memory overflow before he dies manages to take out the system, causing spurious disk writes which corrupts your boot drive.

- The MCAS system. Got bad information and did a very bad thing. It was the entire time operating as it was designed. The fact that the astronauts were not given the information on how to turn HAL off in the event he goes berserk isn't really their fault.

Just to be clear - The MCAS system was actively trying to fly the plane into the ground. It thought it was trying to save the plane from a stall. It was wrong. The pilots attempted to override the system. They could not. They attempted to outfly the system. They could not. They could have killed the system. Boeing did not teach them how.

The turn off the MCAS system button on the 737 Max the pilots were using, does _not_ in fact turn off the MCAS system. It is a "Pause the MCAS system button" Even worse, After a few moments, the MCAS system reactivates and then adds even more down trim. So pressing the button, not only does not turn off the system, actually triggers the plane to make the situation worse by adding more down trim.

When the FAA certified the 737 Max the MCAS Software was able to move the horizontal tail a max of 0.6 degrees. (out of a total of 5 degrees) The software flying on those planes was in fact able to move the horizontal tail 4.17 times that amount: 2.5 degrees. They never told anyone this changed. The system went from being able to control 12% of the tail range to 50% of its range.

Those pilots were pulling up on the nose of the aircraft with their feet pressed against the controls. Directing the aircraft with clear intent and skill. The 737's automation had unbeknownst to them and with their knowledge of the aircraft - un-overridable, tilted the horizontal tail into a position that would, under any operating condition direct the nose of the craft into the ground.

And with the design that both Boeing and the FAA certified to fly, that system would simply fly the vehicle into terrain. In this case it is exactly the automation that is at fault, not a pilot misunderstanding or mistraining. The automation system was designed to prevent a pilot from doing something she might have been familiar with doing while flying the old design on the new design. It was designed to keep the pilot from putting the plane in a bad state for flying. That entire system made an error that cost 347 people their lives.

What is painful, is that the pilots recognized that the system was in error, and attempted to correct it, but were unaware that it had the capability to override them. They were unaware because the designers intentionally hid the mechanism. That is made the mechanism hard to see, understand, and needing special knowledge to disable. The designers had not considered all failure modes, but acted as if their implementation was failure-proof and never to be tampered with.

The question in this case is how can one verify something like an automated aircraft system? And more importantly, if there is a technique or practice to assure the system is valid, is the company trying to build it mature enough in its engineering practices to follow it properly?

While true. That disconnect is not related to the automation system consistently doing the wrong thing. The 'thing the pilots didn't know' enough about was how to turn off the automation. Which was what saved the Lion Air flight the day before was that a jump seat pilot knew how to disable the automation. Increasing the automation in this scenario, does the opposite of what they hope.

Ah, an on premise solution is something entirely different. Moving a group of users security problem to a controlled machine could be useful. Setting phasers to laser pointer mode.

Exactly. For the slow on the uptake, this takes the entire security problem, and puts it on some strangers 'safe' computer.

Totally-Not-A-Surveillance-Organization: "Hey, um. We have this super safe place where you can do all your top secret need-to-be safe web browsing. Away from all those prying eyes. Yep, super safe, here. Right here."