I don’t think the answer is that easy. Python is typically run on the server and JavaScript is client-side, which means that the incentives are aligned to optimize Python rather than JavaScript. I think investment in each follows and the difference is more that JavaScript runs in an isolated environment with a more flexible runtime.
Nah although his answer wasn’t exactly what I’m looking for he’s not wrong. Python is not optimized because on the backend you just switch to another language that’s faster. That’s the economically optimized thing to do. Can’t do that on the frontend.
You can just splat whatever support files it needs into the VM there isn't anything special about them. In fact you can copy them onto a different (non-Mac) device and use them there too
Hammerspoon is basically my only reason to write Lua, a language which I really like. I am sure JavaScript is a more pragmatic choice but I will be slightly saddened by it regardless.
Most companies are evil in some way, the question is how evil and how close you are to the evil. Most people will pick "not that evil but pays a lot". A few will take "pretty evil and pays more than a lot". Some will choose "less evil and pays poorly". (It's worth noting that there are a lot of jobs that are not at the Pareto frontier and are "more evil and pay worse" but social mobility etc. cause them to be selected anyway).
I've owned and used the CR-48 prototype Chromebook model, which very well did have a developer mode and a third kernel option built right in. Ran Ubuntu on it with no issues. This has been possible since before the device family was officially available for purchase.
The school thing is different, but also hardly unique. A school issued macbook is often similarly locked down and unusable as a dev machine, due to the student lacking permissions to install anything the school deems dangerous.
It was possible on the Acer model I got when it first came out, but it was still useless. A switch that wiped the whole thing back to defaults was needed to open a terminal and from there a shell script could install Ubuntu.
It still ran the unmodifiable chromeos kernel with no updates and without some of the modules I'd like. And then the screen died.
It was junk. The EeePC was cheaper, lasted much longer and had Debian out of the box.
Author of the post here. You nailed it here; I used Chromebook as the example in my post since the one I used in high school was locked down to basically a kiosk. Couldn’t even open dev tools, much less root it. Such a wild departure from the eMacs I used in my elementary school’s library where I could set bonkers `defaults write` commands and customize every aspect of my account.
If I got a Chromebook as a personal machine as a kid, I probably would’ve rooted it and see what I could do, but growing up, the beauty of the Mac (in that Snow Leopard era) was progressive disclosure. I could start on the happy path and have a perfectly stable machine, then customize the behaviors through the terminal, see what it does, mess with the system files, see what breaks, revert it, then go back to using iMovie like normal.
In my (admittedly limited) time using a rooted Chromebook, it’s much more like a switch flip. You go from mandatory water wings directly into getting pushed into the ocean and Google shouting “Good luck!!”
You don't have to root them to do cool shit anymore. They have a full Linux (Debian based) environment you can enable with a single toggle in the settings. Any GUI apps you install via apt get their icons dropped in the system tray and their windows are rendered via Wayland.
Yeah, very little of this is still true of the period in which the Neo or modern Chromebooks exist.
If the school is managing these Macs, including laptops sent home with a student, then unless it's for a specific purpose they aren't allowing you modify files, you probably aren't allowed to open a terminal or system settings, and you definitely aren't disabling SIP. You might not even be able to access the open internet if they've hard-configured it into a VPN. No different from a managed Chromebook.
Likewise, even older and lower-end unmanaged Chromebooks can enable a full Linux environment that runs a terminal in a browser tab. Doing so doesn't require root or developer mode, and it doesn't change or sacrifice any of the rest of the ChromeOS environment (for which your core assertion, that an unmanaged Mac is a computer and an unmanaged Chromebook is a thin-client appliance, still fundamentally holds). You can install Blender and have it running in a window by about 1 minute into watching a YouTube video titled "How To Download Or Update ANY VERSION Of Blender On Chromebook".
Gaining root on a Chromebook is mostly just a prerequisite to modifying things specific to ChromeOS, but the easier to access, more featureful, and safer LDE is still an entire operating system that you can tinker with, screw up, overload, blow up, and reset to zero, all without losing the happy path of opening up Canva (or, more likely, CapCut on their phone/iPad) and editing videos or whatever.
Most schools will let you do all of those things, either out of incompetence or because it makes it impossible to actually use the Mac for what the Mac is good at.
macOS or Windows can be similarly locked down. In the schools, the school locks it down. In many companies, there are management tools like JAMF, InTune, or NinjaOne that lock down laptops, desktops, tablets, and cell phones a little or completely.
With a Chromebook, there is one thing to lock down. On a Mac, there are a lot of things to do, because the whole point of it is that it's a normal computer.
Every decent Chromebook the past several years can run a full Debian. I’m guessing the one thing you’re mentioning is disabling that feature. There are still client-side firewalls and some other settings to change to lock it down further for a school.
On a Mac, you do need to set up multiple settings in your JAMF profile but it’s only one JAMF client run to apply all the rules.
> The Neo doesn’t have a hardware indicator light for the camera. The indication for “camera in use” is only in the menu bar. There’s a privacy/security implication for this omission. According to Apple, the hardware indicator light for camera-in-use on MacBooks, iPhones, and iPads cannot be circumvented by software. If the camera is on, that light comes on, and no software can disable it. Because the Neo’s only camera-in-use indicator is in the menu bar, that seems obviously possible to circumvent via software.
iPhone and iPad does not have a hardware indicator light
There is a ton of fascinating work to make the "software" camera in use indicator just as secure if not more secure than an LED attached to the power lines of the camera. Apple hasn't publicly talked about it much but here are two sources that aren't terrible.
We've seen a few examples on HN lately (Coruna iOS Exploit Kit) of nation state level exploits in the hands of financially motivated organizations. I'm not free of bias here but the industry is quickly headed towards a reckoning in terms of security over the next few years.
Minus an intentionally bad hardware design, I struggle to imagine how a software version of the idea could ever be more secure than a power line hard-wired to an LED.
For those who are interested, you can disassemble/image the assembly and see there is no funny business. People have done it. If there is something more complex than a power line, something is afoot.
I'm pretty sure the Apple dev who was tasked with securing the older hardware "tally lamps" is on HN somewhere -- I seem to remember him posting about it. (is it you?)
I used to know a guy, about 15 years ago, who made his money exclusively through buying up laptops and hacking the tally lamp code (to stop it activating) one-by-one and selling the code directly to 3LAs. It was really good money.
I thought this too. If they're using the camera to do brightness, it needs to be on when the user isn't using it - if the activity LED is tied to the camera power rail (not sure if it is), it might look like there's something nefarious going on. No way Apple would let that go out the door.
https://support.apple.com/guide/security/mac-on-screen-camer...
> MacBook Neo combines system software and dedicated silicon elements within A18 Pro to provide additional security for the camera feed. The architecture is designed to prevent any untrusted software—even with root or kernel privileges in macOS—from engaging the camera without also visibly lighting the on-screen camera indicator light.
Isn't the argument that a hardware indicator light is (more) immune to bugs? If its just software, you're a software exploit/bug away from finding a way to access the sensor without tripping the software light.
Yes but also this has never been an issue on any phones (i.e. never heard a complaint), and you take that to the toilet. By comparison a laptop camera has much less access to your private life.
People who are truly worried about cameras will cover it regardless of indicator.
I might be mis-remembering but wasn't Pegasus spyware able to bypass the camera indicator? Or was the issue that journalists were constantly seeing the light appear for no reason. I believe it was one of those.
This depends on how the light is implemented -- if it's implemented in the camera module itself it's pretty bulletproof, but i would bet it's just a gpio to the processor on most of these devices and controlled by the os anyway. I could be wrong about that, but I err on the side of caution. I keep my phone in a bag most of the time.
Treat every gun as if it's loaded, and every camera as if it's filming.
On modern Apple devices, the HW indicator light is wired directly between the power rail of the camera module and ground. Turning the camera on via software energizes the power rail. The only way that the camera is on and the led is not is if the led has burned out.
This is a "nothing-up-my-sleeves" implementation, it's not really possible to hide anything weird in the complexity. Apple clearly didn't just want a light that's always on when the camera is on, they wanted an implementation where they can point to it and clearly prove that the light is always on if the camera is on.
reply