1000100_1000101

> We do not sell your data -> But we do “share” it.

Likely true that it's not sold. They want to retain ownership. Like all modern items, they LICENSE your data to others.

I thought a big part of the opposition to data centers was due to the massive spike in electricity costs, or even loss of availability in getting power, for regular people while the data center gets a deal. If they actually paid for the new power generation, I doubt there would be much backlash.

That it's likely to be used to mine your personal data and be used to create AI slop in exchange for more global warming are just reasons to hate it more, but I think it's not the primary hate point.

Based on the ~10x performance gain from disabling access timestamps in VxWorks' HRFS, I'd guess it does. I have no idea if that's common or rare.

You'd need your OS to support, and be configured to use, a disk mounting option that disables file access timestamps, otherwise reads ARE writes.

Exactly. Sony/Playstation can lose their right to issue further licenses, but the existing licenses should be honoured. As that's apparently not baked into the existing contracts, someone needs to legislate that such basic consumer rights are required, and all existing and prior contracts interpreted as if these rights were in place.

Make it work the same as delisted games where you can go into your purchase history and click download.

On desktop it keeps adding forced pauses to scrolling, of varying sizes, and you need to scroll down a between 1 and 10 pages worth to begin scrolling again.

It might "work" just fine on mobile (or not) but you may have stopped trying before reaching the point of re-scrolling, because it's insane.

I compile and run utilities on my Mac all the time, and I've never spent a penny on dev tools or unlocks.

Yes, there's a fee to get access to the App Store, but almost nobody on the Mac uses the App Store... the fee is mainly for putting stuff on iOS (and likely watchOS, tvOS).

The fee also gets you the absolute latest Xcode, but go back one version, and it's entirely free.

On Mac, you can install brew, and use it to install gcc, clang, qemu, whatever utilities you want.

You used to need the developer fee to put stuff on your iOS device at all, but these days you can put stuff on your personal devices without a fee, but the binary expires in a week... enough to learn and debug, but not ideal for a personal tool. That's about the only annoyance where the fee comes up... long term deployment to iOS.

The Locked Tomb series: - Gideon the Ninth - Harrow the Ninth - Nona the Ninth

Liked the first Locked Tomb, didn't really enjoy the remainder of the series.

The Witch King (from the Murderbot author), was alright.

The Time Travellers Almanac. Time Travellers Almanac was meh. A set of short stories, but many retreads of the same ideas we've seen over the decades. There was one good story, and one other interesting concept...

Road to Roswell and Crosstalk. Connie Willis' books were great, as usual.

Brzrkr. Keanu's book was meh.

The first five of the Kate Daniels Series: - Magic Bites - Magic Burns - Magic Strikes - Magic Bleeds - Magic Slays

Kate Daniels is doing an acceptable job filling in for Dresen's absence, though book 3 and 4 go a bit heavy on the romance side.

Pre-orders pending on the next Murderbot book (Platform Decay), and Dresden (Twelve Months)

I'd argue that 68K is simpler to learn and use. You get a similar instruction set, but 32-bit registers, many of them. It's even got a relocatable stack so it can handle threading when you get to that point.

Just noticed you also support scroll to zoom, and it works at a decent speed.

Pinch zoom is the preferred method, it just needs to zoom at a usable (much faster) pace.

I have no idea what input events zooming generates. Perhaps an option in the URL could be used to turn on a log of input events that people can copy/paste and submit back to you, so you can get a sense of what events are coming from various devices and input methods without having to find devices to try them all yourself.

Plenty of map sites have spent years broken on Macs, not handling smooth pinch-zoom or Magic Mouse smooth scroll wheel events. A slight 3mm movement of a finger going from fully zoomed in street view to fully zoomed out planet view. I'm assuming every micro-movement event is treated as a Windows scroll wheel event where you expect to move a decent chunk on each event.

However you're treating zoom inputs, you've got the opposite effect. A full zoom motion barely does anything.

Neat project.

Minor usability note, zooming by pinch on a MacBook trackpad is painfully slow.

Perhaps someone at Microsoft threatened physical harm to a Google engineer if they didn't remove the videos... and they caved into their demands rather than reporting the threat, or perhaps did both.

Typically "Cost Of Living" increases target roughly inflation. They don't really keep up though, due to taxes.

If you've got a decent tech job in Canada your marginal tax rate will be near 50%. Any new income is taxed at that rate, so that 3% COL raise, is really a 1.5% raise in your purchasing power, which typically makes you worse off.

Until you're at a very comfortable salary, you're better off job hopping to boost your salary. I'm pretty sure all the financial people are well aware they're eroding their employees salaries over time, and are hoping you are not aware.

> 4. M1 has over 600 reorder buffer registers… it’s significantly larger than competitors.

And? Are you saying neither Intel nor AMD engineers were able to determine that this was a bottleneck worth chasing? The point was, anybody could add more cache, rename, reorder or whatever buffers they wanted to... it's not Apple secret-sauce.

If all the competition knew they were leaving all this performance/efficiency on the table despite there being a relatively simple fix, that's on them. They got overtaken by a competitor with a better offering.

If all the competition didn't realize they were leaving all this performance/efficiency on the table despite there being a relatively simple fix, that's also on them. They got overtaken by a competitor with better offering AND more effective engineers.

I got stuck on Catan for a while too, as I assumed it was like most games and didn't use names.

At some point I just moved on, and solved the next word, Chess, in like 2 seconds. The results claimed I spent a whole pile of time on Chess, since it has no idea which result I'm thinking of solving (though all the wrong guesses for Catan should have been a clue that the time should have gone towards Catan.)

I'm not sure the per-word time values are useful if they can't be trusted to be accurate.

I was actually alive then, and the painfulness of the white background was real physical eye-strain pain.

I was alive for both amber and green screens too.

Please don't suggest people are making things up from times before their birth simply because you have a different view.

Paper and paper-like writing surfaces were non-white for a long time before we got bleached white paper.

We haven't yet had a glowing-white paper.

Traditional-normal for computing was a dark background.

There was likely a technological limit in the use of pure white at the start when "emulating" paper. VGA 16-color mode likely meant that the choice was between bright white and medium grey, which was too dark. Configurability has lagged behind though.

Mac likely did use this scheme, and yes, copied it from Xerox. However neither Macs nor Xerox had mainstream use. I'd only actually seen 3 Macs in the wild before their switch to Intel, over 20 years later.

Windows adopting the "paper"-white background and whole world drooling over the arrival of Windows 3.1 and 95 is when it became the standard, I think.

Dark mode was the traditional normal.

From early green or amber text on black mono displays. Grey on black DOS text mode. Light Blue on Dark Blue C-64. Apple 2's grey/white (I don't recall) on black. Even GUI wise, Amiga used a dark-blue background as the default Workbench, with user selectable palettes for everything.

It was Microsoft Windows that changed the paradigm to default to a searing white display with black text in most apps, like Notepad, Word, etc., because "it's more like paper". Sure, paper is white, but it's not glowing white. That transition was painful.

I'm glad to see dark-modes return, I agree there needs to be an option, not just forced dark-mode. Preferably light mode options to use a not-as-bright-as-possible white too.

I'm not the original poster, but I ran into something similar late in Win 7 (Win 8 was in beta at the time). We had some painting software, and we used open-MP to work on each scan-line of a brush in parallel.

It worked fine on Mac. On Windows though, if you let it use as many threads as there were CPUs, it would nearly 100% of the time fail before making it through our test suite. Something in scheduling the work would deadlock. It was more likely to fail if anything was open besides the app. Basically, a brush stoke that should complete in a tenth of a second would stall. If you waited 30-60 minutes (yes minutes), it would recover and continue.

I vaguely recall we used the Intel compiler implementation of OpenMP, not what comes with MSVC, so the fault wasn't necessarily a Microsoft issue, but could still be a kernel issue.

I left that company later that year, and MS rolled out Windows 8. No idea how long that bug stuck around.

To add to this, I'll try to give an idea of how much zoom (or focal length really) you'd need to get a picture with detail.

I took photos of both Jupiter and Saturn w/ a Canon R7 and the RF 100-500mm lens, with a 1.4x extender. The 1.4x extender make the lens act like 700mm instead of 500mm. The R7 being an APS-C sensor adds another 1.6x factor, making the combo the equivalent of 1120mm. In these photos the planets are still just dots. The camera takes 32.5 megapixel photos. When zoomed in to the pixel level, both planets were still tiny, about 50 pixels wide. It was enough to see Saturn had a ring and some color striping on Jupiter, but that's it.

The iPhone main camera is like 26mm (42x less zoom). The iPhone 13 Pro's telephoto lens is 77mm (14.5x less zoom), and the iPhone 15 Pro Max is 120mm (9.3x less zoom)... so you're unlikely to get much more than what looks like an out of focus few pixel wide dot even on the zoomiest of iPhones, but with that wider 26mm lens, you just might be able to capture them all in one shot.

To me, what's more technically impressive than the fact I took pictures of the planets with readily available camera gear was that I did with 1/125s shutter speed, handheld, standing in my yard. The accuracy of the image stabilization needed to pull that off is what astounded me the most.

> On an LC-3, the address space is exactly 64KiB. There is no concept of missing memory, all addresses are assumed to exist, no memory detection is needed or possible, and memory mapped IO uses fixed addresses.

> There are no memory management capabilities on the LC-3, no MMU, no paging, no segmentation. In turn there are no memory-related exceptions, page faults or protection faults.

Sounds an awful lot like a Commodore 64, where I got my start. There's plenty to learn before needing to worry about paging, protection, virtualization, device discovery, bus faults, etc.

It sounds like it's not teaching the wrong things like your GTA driving example, but teaching a valid subset, but not the subset you'd prefer.

Your tractor doesn't (I would hope) contain your banking details and all your emails, contacts, browsing history, photos, etc. It deserves to be treated as the tool that it is.

Apple taking your data privacy seriously seems a worthy exception to me. You're free to disagree, and buy an Android.

While the AI focus these days is on LLMs, AFAICT, the NPUs and GPU accelerators are just generically fast MUL, and MAD machines with varying precisions, which should help any AI, and even non-AI tasks likes image filter kernels.

Getting hardware to enable faster AI processing on phones should be good thing if used for useful tasks, LLM or not.

On iPhone, if I take a picture of a plant or animal, it identifies it for me. It's not 100% by any means, but it's useful enough. I've figured out what were baby plants I wanted vs. weeds. I've figure out species of birds I'd taken photos of with my SLR (ie: phone takes picture of Lightroom editing the image, and is able to identify it from that... I'd prefer there was a way to not require me to take a photo of my monitor, either doing it "live", and/or adding the functionality into the Mac.) For people and pets it can find other images that contain the same subject.

When my daughter was studying Chinese, I could use the live-video translation app and see the lesson text translated to English, and see her hand-written answers also translated to English. I could see this being more broadly useful when travelling, along with live translation of spoken words.

Lets just call it JPEG 40 to avoid any confusion.

Direct3D made this a thing. Trying to draw unscaled 2D elements you often end up with blurry images as it bilinearly filters with the neighbouring pixels.

This is because of a mess with where it considered pixels located, where texture samples are considered located, and where, when rasterizing an included pixel, the texture coordinates sampled. See detail at [0].

If your graphics API was blurring all your images, you'd be passionate about that half-pixel offset too.

[0] https://www.gamedev.net/blogs/entry/1848486-understanding-ha...

I've volunteered to fight a share of fires from people who check things in untested, change infrastructure randomly, etc.

What I've learned is that fixing things for these people (and even having entire teams fixing things for weeks) just leads to a continued lax attitude to testing, and leaving the fallout for others to deal with. To them, it all worked out in the end, and they get kudos for rapidly getting a solution in place.

I'm done fixing their work. I'd rather work on my own tasks than fix all the problems with theirs. I'm strongly considering moving on, as this has become an entrenched pattern.

Not the strongest on C++ myself, but the new[] will attempt to run constructors on each element after calling the new operator to get the RAM. The delete[] will attempt to run destructors for each element before calling operator delete[] to free the RAM.

In order for delete[] to work, C++ must track the allocation size somewhere. This could be co-located with the allocation (at ptr - sizeof(size_t) for example), or it could be in some other structure. Using another structure lowers the odds of it getting trampled if/when something writes to memory beyond an object, but comes with a lookup cost, and code to handle this new structure.

I'm sure proper C++ libraries are doing even more, but you already get the idea, new and delete are not the same as malloc and free.