> I swear the anti-AI crowd would all be picking to die if you each had a choice between immortality and living to 85.

It really depends on the cost of immortality. At the very least, it would have a psychological impact that some people may feel is undesirable.

> None of you is writing punch card programs.

> None of you are building vaccum tube logic.

Perhaps none of us, but some people certainly do. We are intellectual creatures. Some of us do things out of pure curiosity. Can we create multinational corporations out of it? Almost certainly not. Can we create businesses out of it? People do so all of the time. There is a market for produce from small farms, hand crafts, heck, even vintage computing.

> None of the things we build today are going to last. Your programs will be meaningless in a hundred years. Probably closer to ten years.

Try telling that to people who are trying to retire legacy systems. Sure, most of them have been modernized. Perhaps they have even been modernized to the point where none of the original code exists. Yet the core ideas still exist since it turns out to be incredibly hard to discard things.

The old ways of writing software will continue, even if they are nowhere near as popular. Call that irrational if you want. I call it human.

The article seems to be fairly clear about this: it is Google focusing on Google phones (so unlocking the bootloader should not be an issue) and they did mention that the kernel would have to be replaced (albeit for other reasons).

I would think the main factor against such clusters is cost. Even if the four year old phones are free, they have to be dismantled, tested, and supporting hardware/software has to be developed. All of that would have to be done on an ongoing basis. While Google may have the volume to be able to build uniform clusters with a given generation of hardware, generations are measured in months. Using four year old hardware also trims four years off the expected life expectancy of the components, and that is comparing like to like (not consumer grade hardware to server grade hardware). I've got to wonder how all of that extra work affects the carbon-footprint they are trying to reduce. It would probably be more effective to increase the use life of the phone as a phone.

All of that is fine for a research project or, on smaller scales, hobby projects. It would be extraordinarily difficult to make it commercially viable.

I pretty much agree with everything you said. But I think there is a chance for this to be commercially viable if it is offered in a different way. I,e not just raw cloud computing maybe you can run games on these clusters and jack the price a little. This is highly dependant on the virtual age of these clusters if they survive 10 of continuos work maybe there is a chance

I wonder if this is a research project about mitigating the risk of not being able to procure compute hardware if the AI industry soaks up all available hardware manufacturing capacity and raw materials?

I wonder if someone's trying to work out if they can keep GCP alive when there's no ram or cpu to be bought at any price because the AI companies (including the AI division in Google) and Nvidea have completely broken commodity compute hardware supply chains?

i don't think that the ai hype will destroy compute procurment for normal cloud opertaions but you can be sure that it'll be used as an excuse to jack the prices a lot.

Manned missions would still have constraints. In some cases, they would be far greater (e.g. due to the necessity of keeping the astronauts alive). Where there are fewer constraints, it would be intertwined with the cost of sending people to Mars. They may be able to travel faster, but a lot of that is going to be because of a larger energy budget. It is doubtful they could travel further, since there are still going to be limits on how far they could travel (humans need infrastructure). That said, perhaps they could cover a larger area (within a smaller radius) than robots. Risk is also a limiting factor, and it is a far bigger one with people. Humans may be more flexible, but you aren't going to have those romantic scenes of people scaling down steep slopes or spelunking in caves. It could be done, but the chances of something going wrong will inhibit it.

While on the topic of human flexibility, it is important to understand that it will be limited due to the resources available. What we saw on Apollo 13 wasn't the product of people trying to expand beyond the mission objectives with what is on hand, it was a last ditch effort to save the Apollo crew. They could afford to do unintended things with the equipment on hand since the only other option was to admit defeat then let people die. Even the very much fictional The Martian was based upon that premise. Treating it as a thought experiment: the primary response was to terminate the mission and evacuate. The part about the lone survivor on Mars was about ditching every mission objective in the name of survival. It would be very difficult to even create a fictional narrative of a human team going beyond the abilities of a similarly appointed robotic mission without abandoning reality altogether.

Different people are going to have different experiences, based on what they had and what they used it for.

If you've ever used a 68000 based Macintosh, you were limited to 4 MB RAM and 1 MB seems to have been more typical. It's in a different league to be sure, black and white graphics and multitasking was optional prior to System 7 (and I don't think multitasking was shipped with the System Software until System 6). That removes a lot of the pressure on memory. On the other hand, you had early Amigas supporting both colour and multitasking. The 1000 shipped with 256 kB RAM and 256 kB ROM (though I think 512 MB RAM was more typical). For an Apples to Apples comparison, the original Macintosh had 128 kB RAM and 64 kB ROM.

Windows 3.x and OS/2 2.x were later in the game, so they were designed for systems with more RAM. They also supported virtual memory. That meant there was less pressure on developers to write memory efficient code. I'm not really qualified to judge realistic memory requirements for OS/2 since I only used Warp on a system with 16 MB RAM, but I recall many people using Windows 95 on systems with 4 MB RAM. The requirements for both operating systems were similar. It's also worth noting that Windows 3.11 was rather late in the game. The system requirements were climbing rather quickly at that point.

The "MultiFinder" extension allowing cooperative multitasking was actually included with "System Software 5", but I don't think I used it myself until System 6.

Same here. It was at least marginally more stable on "System Six."

If I recall correctly, for Commodores, the equivalent of the disk operating system was handled by the drive itself. If you wanted to do anything beyond a LOAD or a SAVE, you were effectively opening the device then sending a command to the device. The exception was getting a directory, which used the LOAD command (as described earlier) rather than a dedicated command. In my opinion, it is accurate to describe loading a special file in order to retrieve a directory listing as a trick.

Looking at the Apple II and Commodore 64, I think it is fair to say that while the BASIC environments supported varying degrees of disk command they were quite different from what we think of as command interpreters. With Unix shells, anything you can enter into a shell script can be executed from the command line, and vice versa. If memory serves me correctly, anything that could be done from the MS/PC-DOS command line could be done from a batch file (though I don't recall if the opposite is true).

It doesn't always work that way.

A personal example: I don't drive. I use public transit a couple of times a year. I am in private cars maybe once every two year. I haven't flown in about 15 years. Clearly this is a contrived example. My energy use patterns are much more typical when using other metrics. That said, it is also the flip side of being a Taylor Swift of the world. There is a point in the developed world where the millions are using much more energy than the thousands.

I said developed world because there are also parts of the world that simply don't have access to my gratuitous level of energy use. To say that they are guilty of contributing based upon the technicality that they are directly or indirectly using a disproportionately small amount of energy is beyond insulting. It is also a blatant way to paper over our responsibility.

> Globally, the poorest 50% emit roughly 4.4 billion tons to 4.7 billion tons equivalent annually, accounting for about 11% to 12% of total global greenhouse gas emissions.

The “less-developed” bottom half of the world population still produces about a tenth of the annual co2 production annually.

That means instead of potential climate catastrophe in 10 years it’d take 100 years if the top half disappeared tomorrow. Obviously an overly simplistic argument but its meant to show that the problem would just be slower but not gone if we got rid of the “wealthy”.

Now I don’t believe they’re equally as culpable. Yet I also firmly believe the vast majority would choose the same as us in developed world have if they could.

Ultimately that’s more of my point. What’s happening isn’t due to some evil plot by the ultra wealthy. It’s the result of human nature.

Some unscrupulous ultra wealthy might hasten it by a few years or a decade, but the core problem is human nature and an abundance of fossil fuels.

The “wealthy” are also the most likely to prevent catastrophe by developing renewables, etc.

Wouldn't it depend upon context?

If it is an emergency, it is a voice call. It is both immediate and conveys urgency. If it is something that you need to talk through, it is a scheduled voice call. Asynchronous communications may demonstrate respect for a person's time since it does not (need to) interrupt them in the moment, but the inefficiency results in a disrespectful waste of time for bidirectional conversations.

If it is something where you need a simple response by the end of the day, it is a text. If it requires a lengthy response, email. Never expect a lengthy response by the end of the day, or for it to be handled on devices with terrible input methods (like phones).

Anything that isn't covered by those scenarios will be largely dependent on the person.

If it's an emergency I want it in text first because I read faster than I listen to voicemails, and can do so in more spaces/contexts/environments (say, at a loud concert or eating in a restaurant), and I trust a person to write the message better than the voicemail system will transcribe a call. Certain emergency keywords sent in a text will especially alert me faster than a call would. (I have call notifications as practically turned off as possible in current operating systems [way too much phone call spam], but a measured set of notification levels for text notifications.)

I think even for emergency situations the relationship between voice calls and text messages is flipping. Text messages are immediate and can convey urgency. Phone calls are for private, quiet spaces, which take time to find (or schedule). With the death of the private phone booths in public spaces, phone calls are inconvenient to take almost everywhere now outside of one's home, but urgent text messages can be read and even acted upon just about anywhere.

Why are we talking about voicemails in the context of emergencies? If it was an emergency, I'm calling every number I have for someone until they pickup or enough time has passed that I write them off as a flake and find the next person on the list who might be able to help with whatever it is.

I think that's what I'm complaining about, too, but again from a just slightly different perspective. In an emergency I also don't want to take time to "call every number I have for someone". I don't want to worry about safe calling hours or people that prescreen every call/make every call go to voicemail (including myself). I'd much prefer to send a much faster, single text message and they either get it or they don't, and often there's a quick read receipt if they do get it.

Phone calls have so much ceremony and ritual and take so much time to play phone tag, and every single part of that, especially the phone tag, has gotten so much worse because of spammers. Phone calls just don't feel reliable anymore. It's easier to assume you are more likely to hit someone's voicemail than reach them many hours of the day. It's easier to assume people don't even check their voicemail in some cases, because they expect a text message if it was important.

I think we have different definitions of "emergency" if a text message that they may or may not see any time soon is an acceptable solution.

If it is an actual emergency, I need to know that they have received the communication in real time. I'm never leaving someone a voicemail in an emergency situation.

I think it is possibly more we have a different sense of "received the communication and feedback to the communication in real time" and the kinds of feedback we get from the medium. Text messages give immediate feedback quicker when they are received. Especially iMessage and/or RCS you have read receipts and "quick reactions" and "someone is typing bubbles" to text messages for very immediate feedback. If you have enough people in your life that never answer phone calls, the phone is a much slower way to get in touch with someone and it is missing all sorts of useful quick feedback (did it go to voicemail because they are in a bathroom or a loud concert or did it go to voicemail because they are screening calls after 30 spam calls a day got to be too much for them? did they hear the voicemail or hopefully see a transcript of it? are they going to call back or are they going to not see it for another three days or do they not pay attention to voicemail at all and just expect a text?), most of which additional messaging gets moved to text channels today among many of my friends. ("Can I call you in like twenty minutes?" is a somewhat common text message to and from some of my friends who always text before a call.) In a real emergency you should text me to try to call me before you call me if you want the likeliest results that I will pick up any phone call, but most of the time it is probably just faster to include a headline in the text itself and save us both the time and emotional roller coaster of also making a call.

In an emergency, I can often text 15-20 people in the time it takes to try to get a phone call through to a single person. (Especially with the multiplying effects of copy and paste and group chats.) I'm still probably going to follow up with a bunch of people by phone calls after the texts go out, but most of that will be by request ("can you call me when you get a chance?" texts) for details or shared emotion bonding after the key points are already distributed (and possibly some emergency conditions better).

If you're talking about the modified web pages, then disabling the licenses is intentional. If you're talking about the original decision to use certificates around 2019, it is more doubtful. Sure, they would have known the certificates would expire, they could push out a small update to remedy that, and that they would eventually stop doing so. On the other hand, doing so seven or eight years later on a platform where they could probably wait another five years and expect Apple to do the job for them (i.e. Apple isn't going to maintain Intel support forever). That seems like an invitation for angry and potentially litigious users.

Assuming the Mac folks had no interest in converging the platform in favour of the Lisa is somewhat unfair. While it sounds like some code was shared between the two platforms, the Lisa's operating system was quite different. It would have been difficult to make Lisa software operate under the Macintosh System Software. To my knowledge, there was virtually no software for the Lisa anyhow. Breaking software compatibility on the Macintosh to get the benefits of Lisa would have been a terrible business decision.

Aside from that, the MMU in the Lisa would have been a custom solution which Apple would have to support. When Motorola introduced an MMU, it was for 68020 generation machines. Apple should have been able to introduce memory protection at that point, but didn't. One of the reasons was that Apple struggled to make that next generation operating system while retaining compatibility with existing software (albeit, memory protection may have been only one of many problems). This was by no means a problem exclusive to Apple. Other platforms ran into similar issues.

Apple doesn't seem to have leveraged or combined work on (Lisa, Lisa Smalltalk, Lisa Xenix, Mac OS, A/UX, ...) as successfully as they might have. As you note, protected memory was deferred to multiple failed Mac OS successor projects (Pink/Taligent, Copland/NuKernel, etc.) Ultimately Apple gave up, acquired Steve Jobs and NeXT, and eventually successfully migrated the Mac platform to an OS with memory protection.

Since then however Apple's OS and hardware strategy has been much more coherent, with macOS, iOS, iPadOS, tvOS, watchOS etc. sharing code, and sharing SoC technology as well. Ironically this is similar to Microsoft's "Windows [NT] everywhere" strategy.

In addition to Xenix, there was apparently also a System V port for the Lisa.

That delay in shipping a memory-protected Mac was probably originally at least as much the result of upper-management politics as anything else. After Jobs left Apple Gassée cancelled Jobs’ pet project, the Big Mac which was intended to run Mac applications on a Unix base. Big Mac project leader Rich Page (and IIRC some other project members) rang Steve Jobs begging him to do something, and the rest is history.

> The Canon Cat is a good text editor. That's about all it does.

Everything I've read suggested that Raskin intended it to be programmable from the beginning, using Forth. Other descriptions suggested that, while document oriented, it was not intended to be exclusively oriented towards word processing. At least not in the sense of the (dedicated) word processors of the day. That said, I'm not surprised that user interaction was keyboard based. The project had it's origins around 1978/79. It would be about 5 years until computers were sufficiently powerful to support a coherent GUI at a reasonable price.