jasode

I'm using "normies" to describe people who are not developers and they would not install something like OpenClaw on a Mac mini.

E.g. the OpenAI's 2-minute marketing video for Dot trying to show non-developers using AI assistants to get tasks done: https://www.youtube.com/watch?v=uXspbC2srEQ

A man wants his website changed, and a woman wants her presentation slides updated. "Serious engineers" don't need cutesy re-incarnated mascots of Microsoft's Bob or MS Office Clippy paperclip assistants. OpenAI dots doesn't have to win over HN techies who are comfortable with CLI tools.

Take off your "engineering" hat and put on your "normie" hat...

OpenAI's Dots, Meta's Muse, xAI's Grok Bot, etc are trying to target non-technical people and give them "24/7 AI personal assistants". Apple is also pursuing this angle by adding more features to the new Siri (partnership with Google-Gemini).

Perspective of product and market : we need our AI to be more deeply intertwined with customers lives instead of just being on-demand chatbot Q&A sessions. The "sticky" product to create this customer relationship is "AI personal assistants". Instead of just providing "answers" (chatbots) -- provide "completed tasks" (AI assistant).

Perspective of technical predecessors and concepts overlap : OpenClaw and Hermes self-hosted software on Mac minis and Linux boxes as "personal assistants" is geared for techies instead of normies. Instead, repackage those types of tools for normal people in cloud VMs to be hosts for "long-lived agents". Zero install required.

The above scenario of fixed time regardless of DST/TZ changes is what I tried to call "cultural/political time". In other comments, I called it "appointment time".

What you call "calendar time", others will call it "time with calculated UTC offset". (Which then leads to more meta discussion of "no... calendar time is not UTC offset because ..." )

Both examples of our ambiguous labels causing more confusion is prime example of the industry not converging on good names to make devs aware of the difference.

>I think practically what matters for developers are three things:

That categorization is fine but is still obscuring the key issue: many developers think they can collapse all of your 3 types into one simple strategy of "always store it as UTC"

I happen to call them "scientific datetime" vs "cultural/political datetime". However, the software dev industry has not converged on a standard vocabulary to delineate the 2 types which is unfortunate because that means programmers are unaware that the difference exists. Concepts are more top-of-mind when there are good names to label them.

If a programmer doesn't understand how the 2 datetimes behave differently, they will create software bugs as I've outlined before: https://news.ycombinator.com/item?id=39418897

There's the meme of "store UTC everywhere" (maybe perceived as correct because of superficial similarity to "use UTF-8 everywhere") ... but storing datetimes as UTC is only unambiguous for historical events such as timestamps of activity stored in server logs.

But future datetimes can have ambiguous edge cases which causes the split into 2 different types.

That hybrid setup can deliver very satisfactory sound but for some guitarists, they also want real tube power amps because they behave differently than solid-state power amps.

The tube preamps give the distortion fuzz but the tube power amps also provide the extra dynamics that makes the whole response under the fingers more spongy, velvety, etc. Connecting the preamp outputs of a Mesa Boogie or Soldano into a solid-state amp has a different feel than tube power amps. The solid-state amp is definitely usable... but it's different.

That said, I sold all my tube amps and just use the stock digital emulations of guitar amps in Logic Pro. I got rid of almost all the analog gear that was heavy and required maintenance (e.g. new replacement tubes cost $200) because I didn't want it weighing me down as I got older.

GCC 11 (2021) std::visit was slower than virtual dispatch.

GCC 12 (2022) optimized std::visit so it can be faster than virtual dispatch.

https://shubhankar-gambhir.github.io/posts/your-stdlib-imple...

Apple doesn't see individual transactions when Apple Pay is used at retail stores' tap-to-pay terminals. The secret card payment token is sent from the phone to the credit-card's issuing bank and bypasses Apple servers. In this way, using Apple Pay is more secure and private than plastic cards because the real card number details remains hidden from the merchant.

The iPhone does contact Apple servers to add a new card to the digital wallet. Apple servers then contacts the issuing bank to get the secret token the bank generates and then puts it in the digital wallet. Conceivably, the "add a new card to digital wallet" could also have been done without Apple in the middle but it would require a much more convoluted, less secure, and more user-hostile workflow to do it. (e.g. the end user would have to know what bank endpoint to contact, manually enter the long and cryptic digits of the secret token, or maybe scan a QR code on a computer screen that's vulnerable to interception and phishing.)

When people say software is "expired", "obsolete", "legacy", "limited shelf life", etc ... they're not talking about whether somebody somewhere in the world has the ability or idiosyncratic desire to continue running that old software.

Instead, it means the software's ability to be practical and usable in relation to the rest of the current computing ecosystem. E.g. In this perspective, Win95 MSPAINT is "expired/obsolete" because it can't open .PNG and .JPEG files. In today's world, .PNG/.JPEG files are much more common than the .BMP files that MSPAINT 95 can open.

I still have an old 16-bit Microsoft C/C++ v 7.0 compiler from 1992. Did it expire?!? Well, not literally. There's no ticking time bomb in it that checks the system clock and refuses to run. Instead, the issue is that it doesn't have the newer C99/C++98/C++11 features and I can't use it to compile today's ffmpeg source code. That's what people mean by "expired/obsolete".

Appliances with mandatory wi-fi is a bad trend. The mid-tier dishwasher from Bosch locks the Eco(nomy) energy saver cycle, delayed start, etc functionality behind a smartphone app. This requires connecting the dishwasher to wi-fi and using the smartphone to create a Bosch online account. That's what the whole Jeff Geerling complaint video was all about.

https://www.youtube.com/watch?v=5M_hmwBBPnc&t=4m21s

A person's perspective on the older dev tools being "superior" to today's newer tools depends on the things they want to build.

I had jobs working on Foxbase/FoxPro for DOS and migrated those apps to FoxPro for Windows, and Visual Basic 3.0 to 6.0 ... and I don't look back at those with the same positive nostalgia.

Classic VB was "simple" but every project at each company had a different hodge podge of 3rd-party VBX/OCX add-on controls to do anything non-trivial. E.g. 3rd-party calendar date picker, report writer, etc. VB didn't have a decent datagrid so everybody bought a 3rd-party one. In contrast, C# WinForms standard controls included a usable datagrid with data binding out of the box.

In a FoxPro for Windows project I was working on, we needed to open .zip files. FoxPro didn't have that functionality so the company paid an extra $300 for the FoxPro Library Construction Kit[1] and I hand-coded a .zip file parser in C Language to be called by FoxPro code. Instead of FoxPro dev work being simple, it's complex! Today's Python or C# can trivially open .zip files with builtin modules and functions so devs don't waste time on writing low-level C code or use 3rd-party libs.

With old 1990s tools, you can't do "simple" tasks such as getting a UTC timestamp, use a regex expression, or retrieve a web page with an http call, etc without calling Win32 API functions or 3rd-party tools.

If one wants to do things beyond the limitations of classic VB/FoxPro, the newer dev tools like Python/C# etc absolutely do make things easier and faster.

[1] https://www.scribd.com/document/384159949/Ms-Foxpro-Develope...

https://stackoverflow.com/questions/53401654/why-was-stdbit-...

Multiple stories have reported that ANE came from Apple's self-driving car project that got canceled. (Makes sense since CNN is used for vision-related machine learning and enables cars to analyze their surroundings.) They spent 10 years and ~10 billion on research & development on a product that never got released so Apple is probably happy they're able to salvage some of that ai technology and put it in iPhones and Macs.

The gp's analogy maps better this way:

  roads = ip packet network routing, DNS, telecommunications cabling
  racist conventions/meetups = social media platforms like Facebook

(Yes, people do "hate traffic" but that not's the same as "hating roads". Anyone who has travelled on unpaved dirt roads or gravel trails that make their teeth rattle will appreciate having paved roads. And that appreciation doesn't change even if a lot of KKK racist members also use roads.)

The author Lawrence Ulrich references research from the Insurance Institute for Highway Safety. Why would it be "obvious" that they are paid PR shills for Tesla/Waymo?

I'm jaded and cynical so I can accept that they may be secret PR mouthpieces but isn't it reasonable to expect a little evidence rather than just throwing out a random accusation?

The author literally labeled that room the "Upstairs Office".

The rest of the house (kitchen, family room, etc) that's not dedicated to LAN computers looks like a normal Euro/Scandinavian type of clean minimalism aesthetic which a lot of people like.

My home currently has a lot of "traditional" style furniture and decorations hanging on the walls which some might call "warm & cozy". But others would disagree and think of it as "grandma's house" and as I've aged, I tend to agree. I'd like to eventually dial it back and redo the interior to be more minimalistic but I have other higher priorities than remodeling the house.

He spent a month trying different repairs (replacing pump, etc) that didn't work and then finally stumbled onto the electrical relay as the root cause. This is the deep link to the video I used: https://www.youtube.com/watch?v=3Gm_2qISYvk&t=2m41s

>So why couldn't you?

Maybe I eventually could have fixed it if I spent weeks on it and replicated all his failures but I didn't have to because ... he uploaded a video to help me. His video was the breakthrough I needed because it identified the particular relay. I actually had to watch more Youtube videos to learn how to actually replace the relay because the board is encased on epoxy resin and I had no idea how to deal with it. Various Youtube videos showed ideas of using an exacto knife and Dremel rotary tool to cut through the plastic case on the other side.

>, and I don't understand how one couldn't read about a fuse on a forum or in a manual and diagnose with a DMM.

One could hypothetically read the text of fixing a single relay of that particular washer model on a forum ... if... that guy in the vid hypothetically wrote a post on a forum... but he didn't. Sometimes, the mode of sharing is Youtube instead of a forum post. I can't control what other people do.

I did eventually find the official Samsung service manual PDF file and had to download it from some sketchy warez website because end-consumers are not supposed to have it ... but it only talks about board-level repairs ($250) instead of isolated repairs of replacing a single faulty relay.

Without hypotheticals or exaggeration, Youtube has literally saved me thousands of dollars. Showing how to fix cars, plumbing, ice makers, sewing machines, coffee machine, sprinkler systems, etc.

A lot of info on Youtube is not available in alternative forms such as books or blogs with just words and images.

E.g. A random person uploads a video on how he repaired my particular washing machine by isolating the relay that broke. It's not in blog form because the guy is not an HTML expert or WordPress user. Instead, he simply used his smartphone to record a 10 minute video of what he did and uploaded it to Youtube.

Was I "fine" before Youtube?!? In the past with that type of situation, I would have spent $1000 on a new washing machine instead of spending $2 for a new relay part and soldering it myself. There was no equivalent resource available to show me how to DIY repair it. Trying to avoid $1000 by calling an appliance repairman wouldn't help because these days, they charge a $150 trip & diagnostic fee just to show up ... and then in the end, they say the electronics board that's fried is discontinued so they can't get the part which means the only the only remedy is to buy a new washing machine. So I would end up paying a guy $150 to tell me to pay another $1000 for a new washing machine... for a total of $1150. Youtube helps in avoiding all that. As a knowledge base for DIY learning how to repair random stuff around the house, there is no alternative to Youtube.

I just ordered a new Mac Studio M5 Max 128GB $5899 ($6400 with tax) to be able to run the bigger "consumer size" models in the 70B parameter range (~96 GB). That said, I have no illusions that this expensive setup with a Qwen Flash coding LLM will be comparable to a $20/month subscription. Even upgrading to an even more expensive Mac Ultra 256GB for $10000 to hold a bigger model still won't be comparable. Apple hasn't shipped my Mac yet and I'm still considering cancelling it and downgrading to a smaller 64GB RAM config ($4299) to save $1600.

Why did I initially spend the extra $1600 if I knew ahead of time that it wasn't as good as cloud AI? Because I thought I could use some local LLM for the easy tasks or when I hit cloud rate limits. No issues with privacy so that wasn't part of the motivation at all. I just wanted some local AI capability to augment a subscription. I've not totally convinced myself of the cost/benefit of this.

Based on today's consumer hardware landscape, you're paying very high prices for crippled capability compared to the cloud AI subscriptions. We're also in a transition period where the next iteration of hardware improvements have some compelling features for local AI. Apple's upcoming M7 (2027 or 2028) is anticipated to have better GPU and neural engine to help with prefill TTFT. AMD Strix Halo is about to release 192GB system which is a big upgrade to their current 128GB ai pc. Maybe apply my $1600 savings towards those newer products. Those future products will still be very expensive but maybe the cost/benefit will be better.

Project Valhalla, which includes the effort to add value types was announced in 2014. They've been working on it for a while.

As for "what changed" ...

Back in 1990s when Java was conceived, there was an idea that CPUs in desktops had plenty of extra cycles that were being wasted and could therefore be used to reduce mental load on developers. It was the same "cpus are cheaper than developers" idea that is repeated today with "tokens/cpu are cheaper than developers". With that philosophy, James Gosling talked about Java's "everything-is-an-object" as a mental simplification for developers. All the extra indirections of pointer-chasing to box unbox primitives and/or iterate through arrays of objects wasn't seen as a penalty (again, "CPUs are cheap; devs are expensive").

However, the later evolution in 2000s of CPU hardware vs RAM hardware changed that performance tradeoff thesis: https://en.wikipedia.org/wiki/Random-access_memory#Memory_wa...

Now having value types that are contiguous in RAM is a big deal for performance. Avoid a bunch of pointer chasing. Even C++ best practices were affected. E.g. the traditional tradeoffs you learned from from classroom textbooks of linked-lists being faster than arrays for middle-of-list insertions was no longer always correct in the new world where CPUs are caching adjacent RAM areas to try to reduce the memory wall issue. So O(n) could be faster than O(log n) depending on the size of the data structure and interactions with RAM pre-fetch, etc.

Sorry for not being clearer. I don't like the MacBook's noise when the fans turn on.

The Mac Studio has bigger heat sinks to delay the need for thermal management -- and if its fan does need to turn on, the bigger size means it's still silent instead of the high-pitched whooshing noise the tiny fans make in the MacBook.

Having owned 3 MacBook Pros since 2008, the decision to make my next computer be a Mac Studio came down to (1) MacBook thermal throttling that slows down CPUs when it starts to overheat and (2) easier upgrade of Mac Studio SSD with after-market storage module whereas the MacBook requires more complicated disassembly and hot air gun to dislodge the surface mounted SSDs.

I have a brand new M5 Pro MacBook Pro I don't like it when the fans turn on. The Mac Studio will be faster and quieter for the same workloads.

There are several gaps in your assertion about USA restaurants being overstaffed with servers.

#1 the mathematical relationship between servers and income is questionable: Servers acting as quasi commissioned salespeople by upselling patrons on "another beer?" or "anyone here want to order desert?" ... can be time-staggered interactions across multiple customers as the server rotates among their assigned tables.

Let's say, a restaurant has 20 tables and initially has 5 servers. Each server rotates among their assigned 4 tables. For a single turnover of 1 set of 20 tables, the diners have been asked(upsell) "Do you want desert?" 20 times. Let's say the owner wants to "overstaff the # servers" to be 1-for-1 and have 20 servers to 20 tables. The # of upsell events is still the same at 20. In what scenarios do overstaffing servers increase restaurant's income? (On the other hand, understaffing servers causes diners to twiddle their thumbs for half an hour after they finished eating because the overbusy server hasn't gotten them the final bill yet which causes less turnover of the tables which leads to less restaurant income.)

It's also not clear why you need tipped servers to upsell. Fast food places like McDonalds have trained minimum wage workers to constantly upsell... "Do you want fries with that? Do you want to upsize that drink?"

#2 the economics equilibrium of what tipped servers want to be paid and whatever staffing levels the restaurant owners want. Trying to overstaff the restaurant means waitstaff notice they don't work as many tables which means their tips (thus total income) is lower. This causes them to quit, which then causes the restaurant to keep trying to hire new waitstaff. Many restaurants chronically run "shorthanded" because of this negative feedback loop. (Which is one of the causes of extra delays between the hostess seating the diners and the time the waiter finally shows up.) Therefore, adding more servers to increase restaurant income isn't going to work.

>USA restaurant staffing is widely studied

The only studies I found analyzed restaurants not being able to hire staff including the servers. No study talked about restaurants having overstaffed servers in the USA as a proven driver of extra income.

EDIT to reply: >In Europe a typical place with 20 tables will have 2-3 servers and no runners. We go from 8-10 floor staff down to 2-3.

Your premise doesn't work for USA because with the hypothetical American restaurant that only has 3 servers with no runners and those 3 all sharing the workload "as a team" for all tables ... still means those 3 servers want to work for tips. That negates your parent post saying the higher # of staff is the barrier to eliminating tipping.

Instead, the barrier to end tipping in the USA is the inertia of the ingrained culture where servers expect tips and patrons keep paying them.

There are several high-profile restaurants in New York City, etc that tried to eliminate tipping by raising prices and they eventually reverted back to traditional tips.

>Hopefully it is clear how 5 servers dedicated to 4 tables each and backed up by runners can do a lot more upselling than 2-3 staff doing team service.

It isn't clear because those same lowered server count of 2-3 can still ask the same upselling questions... "Do you want desert?" Asking that question isn't mathematically constrained by the # of servers. Instead, it's constrained by the # of tables.

In many USA restaurants, the waitstaff tips are also shared into a pool with the runners, busboys, and kitchen staff. The % may not be equal however.

>What you are noticing is that many chains have a "full hands" rule:

But that contradicts the idea that "USA restaurants almost always over staffed there." The chain restaurant could just "overstaff" with dedicated table runners with no need for a "full hands" rule.

It doesn't seem like USA restaurants are overstaffed nor do owners have the incentive to overstaff. The very common scenario is the hostess seats you at the table and the waiter doesn't even show up for 10 or 20 minutes to take the order. The patrons are frustrated and wondering why it's taking so long. That's a symptom of understaffing where the waiter is handling too many simultaneous tables.

American chain restaurants also use the team model. The server that writes down the order often isn't the same person bringing out the hot plates of food. Maybe less of team than Europe because the waitress taking the order will typically be the same one refilling the drinks.

It's the white tablecloth high-end restaurants where the one waiter is the only person handling all interactions with the table.

Be aware that tar doesn't preserve creation/birth times and keeping that original metadata is important to some people if the target file system can record it. Robocopy preserves/transfers creation times by default and recent rsync versions (3.2.3 2020-08-06) can do it with the extra option --crtimes.

It's only an issue when people take that phrase very literally. People have common sense to understand that things have multiple causes and a chain of events. NASA has "Root Cause Analysis" (singular) all over various official documentation and it doesn't stop them from understanding that the failed O-rings were not the single root cause of the Challenger explosion. Another cause was management normalizing the deviations of previous unsafe datapoints of prior launches which let them greenlight the launch in freezing temperatures. Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations. It wasn't The Rogers Commission that found the multiple causes; it was NASA engineers and management themselves explaining the multiple causes as they were interviewed by the Rogers Commission members.

For whatever reason, alternative jargon such as "Root Causes Analysis" (plural) or "Proximate and Distal Causes Analysis" isn't as widely used.

There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.

The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.

Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.

I think it's as simple as comparing the the community dynamics of 2 different timelines:

- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0

- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0

Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.

Deep link to Chris Lattner interview where he says he learned lessons from Swift being rapidly released as open source meant that early design decisions that were suboptimal caused quick revisions. This caused a lot of complaints when later revisions to Swift caused breakages. This caused a lot of stress for Chris & the Swift team so he says he didn't want to repeat that for Mojo.

https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=2h22m05s

Sure, one can simple redo the exact same playbook with Mojo and iterate out in the open with early versions, and when people complain again about their code breaking, he can "just ignore it" but he didn't like that experience with Swift.

Your suggested alternative of moving all photos to a laptop doesn't work for the people who prefer having all their photos accessible from their smartphone. That's the usable UI that the constant sync to cloud services gives them. The tradeoff is the cloud storage subsciption costs.

Also, transferring all photos to a laptop creates a single-point-of-failure if the laptop dies. Recovering photos becomes even more complicated when the internal SSD is encrypted with macOS File Vault or Windows BitLocker. Yes, photos in cloud storage isn't really a "true backup" in the 3-2-1 best practices sense but it's still more durable against catastrophic data loss than a single laptop.

The self-hosted Immich photo server is just one way to enable smartphone access to all photos and avoid paying for cloud storage. That's the reward for the "overkill" setup.