wizee

There are promoted apps in the app store, ads within news articles in the News and Stocks apps, and Apple also advertises their own services like Apple Music and Apple News and Apple Arcade etc. in some places, particularly on first use of some apps. Nowhere near as egregious as Windows, but still a bit disappointing.

Porsche 944s and 928s are far more rust resistant than most American or Japanese cars of the 80s or even 90s. Likewise with Volvos. The classic 911 was an old design that went through iterative improvements, and the 964 is better rust-proofed than most American or Japanese cars of the late 80s or 90s. Old Audis tend to have minimal rust, and old Mercedes-Benzes like the W126, W124, and W201, while they certainly can and do rust, their bodies tend to far outlast Japanese and American cars of the same era driven in similar conditions. Old W124s still soldier on as daily drivers and winter beaters in the cold and salty environments of post-Soviet states with mostly OK bodies, whereas Japanese cars of the 1980s almost all rotted away beyond repair being worthwhile more than a decade ago.

Displacement taxes are terrible. There are many instances of large displacement engines (e.g. modern GM LS/LT series engines) that are lighter and more efficient than comparably performing smaller turbocharged engines. Penalize heavy vehicles that damage pavement, or vehicles with poor pedestrian safety, or gas guzzlers, but don't penalize one aspect of engine design (displacement) that isn't directly harmful.

It’s a competitor/alternative to Alma with a slower moving development team.

No, it does not beat Time-of-Flight measurement. What it does achieve is keeping GATT response latency within normal ranges, so that the GATT response latency cannot be reliably used as an indication of relay attacks. GATT response latency can vary by tens of milliseconds, whereas Time-of-Flight is usually measured in microseconds or nanoseconds. Unfortunately, Bluetooth LE alone lacks a mechanism for time of flight measurement in secure ranging, hence why technologies like UWB are needed.

Devices don’t use GATT response latency to estimate distance, but elevated levels of GATT latency are commonly used as indications of relay attacks. A lower latency relay attack can work around this defence. The researcher recommends time-of-flight measurement in a secure ranging protocol to mitigate such attacks.

Very ordinary detached family homes in decent shape pretty much anywhere in Ontario are near a million dollars or more. If people could buy a family home for vaguely affordable prices in even the most remote parts of the province, people would flock there. There's plenty of land, but getting permission to build anything in much of Canada is a difficult and slow process, even in remote areas.

I Ontario at least, houses in the middle of nowhere are still absurdly expensive. Getting permission to build anything anywhere is hard.

Yup, battery life is great on my 13 mini. The narrower notch on the 13 compared to the 12 is nice too for the smaller screen.

As an 8 year old, I had no interest in playing with children’s toys. I wanted to learn how to what the grown ups around me that I admired did, making professional looking things. VB6 and Adobe Flash were perfect for this circa 2002. They were professional grade tools that were easy to get started with but capable of sophisticated professional looking output. The drag/drop/drawable user interfaces or scenes of these programs was also great for a kid to make something interesting without getting too frustrated with detail. I enjoyed doing things like making clickable buttons change text on a label or pop up a message box or open a file. I also thought making menu bars for applications was so cool and fancy. Likewise, I enjoyed making simple animations with flash. I think the key is having a tool the kid thinks is useful/professional grade and cool (I didn’t find kids toys or kids software cool above the age 8 or 9) but also approachable for early gratification with results that can be seen.

Sensitivity to colours outside the visible spectrum can cause colours to appear incorrect relative to what the human perceives. Imagine two objects whose visible spectrums are the same, but whose IR or UV spectra are different. They’d look the same to a human, but different to such a modified camera.

Rocky Linux provides a perfectly good and compatible drop in replacement for CentOS 8. So does Alma Linux.

The issue is that the tests portray themselves as being accurate (in the sense of low false positive rates), and portray the result as “your baby has XYZ rare syndrome” instead of “your baby has a 15% change of having XYZ rare syndrome”. If the test providers stated the false positive rate for their results more clearly, parents would be in a better position to make informed decisions.

Many forms of FGM are just cutting off the clitoral hood, equivalent to a male circumcision.

1. They own their cloud, you own your device. Having your own device work against you is more problematic in principle than having another party you give your data to working against you. I don’t like the concept of devices that I own betraying me.

2. When scanning is done locally, it’s easier for them to secretly or openly modify the software to scan everything on your device, rather than just what’s just uploaded to iCloud. If they tried scanning everything (including non-iCloud images) in the cloud, the network traffic of uploading every image on your device to the cloud would be observable.

Why not just report odometer readings annually, and tax based on that? It would avoid the need for implementing so much surveillance to track every movement of every car.

With little endian, if you take a pointer to an integer of a large type (eg. uint64_t) where the value fits in a smaller type (eg. uint32_t), you will get same correct value accessing it as a uint64_t or uint32_t on a little endian system. This can make integer type conversion/casting slightly more efficient, and simplify code a bit.

My point is that driving at 160 km/h on a fairly empty highway in a manner that is respectful of others is not particularly dangerous. In fact it’s pretty relaxed and routine in Germany for the middle lane of 3 lane derestricted autobahn. The right lane goes 130 km/h, middle lane goes 160 km/h, left lane stays mostly empty except for the occasional person passing. People keep their distance, slow down when there’s traffic in the distance ahead, and strictly adhere to keeping right except to pass. On most modern cars, stopping distance and fuel economy are also pretty reasonable at 160 km/h. I will admit people flying by at over 200 km/h in the left lane can be scary, and stopping distance and fuel economy become terrible for most cars at 200 km/h, though it generally works safely there because of the strict lane etiquette, coupled with people maintaining distance and slowing down in advance when traffic is ahead.

A bigger danger than speeding on clear highways is things like tailgating, weaving between lanes, aggressive passing, and distracted driving. This often happens below speed limits, and is not the focus of automated speed enforcement systems.

In Ontario, Canada, we have wide, well maintained, and well engineered highways that have unreasonably low speed limits of 90 or 100 km/h. While there are times when it’s necessary to drive more slowly (bad weather, traffic ahead), strictly enforcing such limits on wide clear highways in good weather would be silly. People here generally drive 120-130 km/h because cars are designed to operate safely and efficiently at these speeds. Strictly enforcing unreasonably low speed limits would just breed contempt from drivers, so currently the police are lenient with the speeds people actually drive. Strict enforcement of speed limits could be more reasonable if they set realistic speed limits, perhaps variable ones depending on the weather and traffic conditions.

Fact is that people drive that speed regularly on German autobahns without any widespread carnage. Driving aggressively when below the speed limit, or being distracted, is far more dangerous than just driving quickly on a clear road. The emphasis on speed is mainly because it’s easy to measure and enforce.

There’s standard etiquette there to slow down when there are vehicles in the distance ahead or curves or imperfect visibility. You don’t have to drive like a mindless drone holding a one-size-fits-all-situations speed limit. You and other drivers are generally safer going 160 km/h on a mostly empty highway than 50 km/h through an urban where there’s a much higher risk of encountering other people/vehicles/obstructions.

It’s swapping places with RHEL beta, not RHEL. Not calling it a beta doesn’t not make it a beta. It’s directly taking the role that RHEL beta releases used to have (ie. be a point release ahead, and be for the public to test and report issues before going to stable RHEL).

Regardless of what your blog post says, RHEL was not a beta for old CentOS. Old CentOS was a rebuild/copy of RHEL, bugs and all included. RHEL will not be a copy/rebuild CentOS Stream, so it’s not a reversal of roles.

Using outdated packages doesn’t make a distribution stable. It’s stable when its combination of packages and configuration has already been tried by a bunch of people, and confirmed to work, or has had its issues thoroughly documented with effective workarounds.

The PF (BSD Packet Filter) firewall built into Mac OS covers apple processes. However, I don't think its interfaces are sufficient to implement the functionality of Little Snitch. The new-ish NEFilterDataProvider API used by Little Snitch on Big Sur is neutered by allowing Apple apps to bypass it.

I'm talking about VPNs, not firewalls. This article (and people in general) are claiming that Apple applications bypass VPNs, and falsely implying that system-wide VPNs are no longer possible in Big Sur. NEAppProxyProvider was never meant for system-wide VPNs. NEPacketTunnelProvider, the system-wide VPN mechanism (when used in destination IP mode), continues to route system-wide VPN traffic, including that of Apple applications.

I'm not denying that NEFilterDataProvider is an inferior solution for per-app firewalls like Little Snitch, compared to their previous kernel extension.

Per-app VPNs have existed for some time, and their use case is different from system-wide VPNs. Typically, per-app VPNs are used when you want to grant specific applications access to resources on say a corporate VPN, without granting all applications access to the VPN. Per-app VPNs are also useful if you want to protect a specific app's communications through an encrypted tunnel without affecting the rest of the system.

More info on the purpose of per-app VPNs: https://support.apple.com/en-us/guide/deployment-reference-i...

Apple apps do bypass NEFilterDataProvider (used by application firewalls like Little Snitch), and the per-app VPN mechanism (using NEAppProxyProvider). Thus, per-app VPNs can't be applied to Apple applications, but per-app VPNs were never intended to globally intercept traffic. Claiming that Apple apps bypass (all) VPNs in Big Sur is deceptive - they only bypass per-app VPNs that were never intended to cover all system traffic in the first place.

Traditional VPNs that cover the whole system and route traffic based on destination IP (such as OpenVPN in UTUN mode) use the Packet Tunnel Provider in Destination IP mode. To the best of my knowledge, global VPNs routing based on destination IP (ie. non per-app VPNs) still route traffic from all applications, including Apple ones.

See this for more details on the Packet Tunnel Provider: https://developer.apple.com/documentation/networkextension/n...

Generally, yes. The benchmarks are calculating/computing the same things on both architectures, and the various sub-benchmarks are based on real-world non-trivial computational problems rather than microbenchmarks that are easily manipulated by instruction set differences.

Researching the very most efficient parts from Intel and AMD today, 3x the perf/watt would be more accurate. Operating at a 5-6W TDP, the 2018 Apple A12X gets a multicore Geekbench score of 4730. Operating at a TDP of 15W, the i7-1065G7 (Ice Lake) gets multi-core Geekbench score of 4865. This is on Intel's 10 nm process that's comparable to TSMC 7 nm. Near equal performance for 3x the power.

I'd expect a 2020 A14X or whatever it's called to comfortably beat what they could achieve in 2018, so getting 4-5x the perf/watt of Intel and AMD's best is what I'd expect when operating at similar points in the frequency/power curve. The A12X was around 4-5x the perf/watt of what Intel and AMD had out in late 2018.

https://browser.geekbench.com/v5/cpu/2639065 https://browser.geekbench.com/v5/cpu/2638528

> Those curves also apply to Intel & AMD. As in, you can drop frequency on AMD to also achieve significant improves in perf/watt. That's not a unique aspect of the A12. That curve is more "this is how TSMC's 7nm transistors behave" type of thing. Geekbench only measures perf, not perf/watt. It does not try to achieve maximum perf/watt, nor has Apple tuned to the A12/A13 to achieve maximum perf/watt in Geekbench either. Geekbench's single thread numbers where it "competes with Intel & AMD" are also these ~5W per core power figures.

While similar curves also apply to Intel and AMD, their mobile parts are drawing 10-20 watts per core to acheive the very top results. When you're using all the cores together under a 6W TDP (as apple is doing), Apple is able to achieve a much higher Geekbench result than Intel or AMD parts set to a comparable TDP, or even 3x the TDP. Compare multi-core Geekbench scores of Apple's parts running at a 6W TDP to Intel or AMD's most efficient parts running at a 15W TDP, and you'll see that Apple outperforms them while drawing 1/3 the power. Similar curves apply, but Apple can achieve far morea at 1W per core than any x86 competitors.

That's fair. However, according to the same chart, it draws 1W at 2000 MHz, which should give 80% the single core performance. This is how Apple is getting 4x the perf/watt of Intel and AMD competitors in Geekbench and similar workloads. Apple is able to acheive very high multithreaded performance within a 5-6W TDP by running all the cores around 80% of peak performance.

You cherry picked a terrible example. Here are some more Windows examples with the same chip: https://browser.geekbench.com/v5/cpu/2628613 https://browser.geekbench.com/v5/cpu/2628613

In my own personal experience, running Geekbench on many machines, Geekbench scores are pretty close running between Windows and Linux on the same machine. At least for compiling code (my main use for powerful machines), their compilation benchmark numbers also fairly closely match compilation times I observe.

The A12 draws 4W when all four big cores are maxed out. Not 4W per big core. That's 4x the performance per watt of your comparable Intel or AMD parts.