varunnrao

> Was he very skilled back then when he did it?

> I fear the current state of our industry eliminated the possibility for not-great, not-skilled juniors to embark in these journeys

I think both sentiments are a product of their times.

Was porting an OS to a new architecture an extremely skilled thing? 100% then and 1000% today. With each new stage of advancement and increase in the layer of abstraction away from the core metal, newer developers no longer need to know how to program at the lowest level like targeting a processor architecture directly.

Software development from the 1950s till the rise of Windows as the standard was targeted not towards systems like we do today but towards processors and architectures. Processors at that time were simpler to write for. You could get the datasheet for whatever was the latest processor from a magazine, understand it inside and out and start writing software for it. Today I do not think there are more than a few dozen people who understand the x64 line of Intel processors at the same level. So times have changed. We write for operating systems now and not processors anymore.

I think that this is neither good nor bad. It just is simply how it is. I'm sure that people who worked on computers in the 1950s at the assembly level would have been complaining in the 1970s about people writing programs in C/Pascal. And so the cycle continues.

In fact, I think that the current state of generative models that output code is the perfect scenario to separate the wheat from the chaff. Their power function nature gives a clear divide between people who worked in software for the paycheck and those who love technology for it's own sake.

I think what ultimately led to Sun's downfall is a combination of what ESR [1] and joelonsoftware [2] have previously covered.

1. Sun didn't become the defacto desktop platform because they lost out to WinNT. So they lost out on the consumer market. 2. Custom server hardware and software makers like Sun and Silicon Graphics were the fashion till Google and later on Facebook came around and built their own data centers with consumer hardware and specialized software to overcome the inherent unreliability of that hardware. And anyway ever since web-based software became a thing your device is practically a console a la Chromebooks. So they lost the server market.

The only option left was to serve the high end HPC market like labs or even banks but that didn't make business sense since that's increasingly niche because those customers would eventually also want the effects of commoditization.

[1] - http://esr.ibiblio.org/?p=6279 [2] - https://www.joelonsoftware.com/2002/08/30/platforms/

You're right. The hardware right now can't run useful models.

But that's why I think they have a couple of years to sort out their software issues. When useful models can be run on their devices they have to be ready. The hardware advantage can only be an advantage when they have the software to run useful applications. Hopefully they don't get stuck in the typical big company bureaucracy and ego matches and instead can make a change for the better.

I agree. The AppleScript/Apple Event Manager thing is an example of treating macOS like a second class citizen in the ongoing iOS-fication of the Apple Ecosystem. The point of macOS for me is that it's simple to use for most beginners but allows more advanced users to add complexity through tools like Apple Script and Automator and the underlying Unix base.

Like you say, an MCP server integrated with AppleScript/Apple Event Manager would instantly hook up any LLM with virtually all Mac apps. More Mac devs will then be incentivized to support these features. For people who find AppleScript un-intuitive, JavaScript is also supported. And in my view, this is a revolutionary way to use my computer - a very Star Trek way of using the computer.

I would say it's more like the internal Xerox machines that were built in the mid-1970s at PARC. Most people have no idea how to work with those machines. By the time the 128K Mac came out, people understood what a GUI interface was and knew how to use them - it's just that the Mac in particular was limited by it's hardware.

imo, Apple are actually ahead when it comes to the hardware side of the whole thing. Their vertical integration gives them an edge not many can match, when it comes to running ML models. It's a no-brainer for Apple to reduce the barriers for devs to build really cool native Mac/i{Pad}OS applications and incentivize them to leverage the built-in AI/ML abilities to a greater extent. The iPhone in part took off _because_ of the whole app ecosystem that got built around it. Sure they might take a loss in their services revenue in the short term but they get to be _the_ AI platform for at least the next decade and half - both on-device and server side with their new Apple silicon servers.

It's just that most Apple software seems to suck in some fundamental way right now. I don't know if it's a technical issue (SwiftUI being meh when compared to UIKit for example) or a culture issue or the money coming in insulating management from accountability. Software execution has been lagging behind the excellent hardware execution for almost all of the Tim Cook era. They desperately need someone like Scott Forstall to come in, kick butts and get stuff going again.

They ideally have a couple of years while waiting for Moore's Law to catch up to turn around their software side. Otherwise, it's a real shame that all that great hardware is just being used to run Electron B2B SaaS apps.

It's really wild how Mister Rogers Neighborhood had this slow, thoughtful cadence with long pauses, quiet moments, no flashing graphics or over-the-top antics. It engaged the audience (mostly kids I guess) with something calm and sincere. You don’t see that much anymore.

I sometimes wonder if a show with that same deliberate pacing and emotional intelligence could even succeed today or if it would get buried under all the noise.

> In fact the whole British imperial project was largely glossed over. But lots of coverge of the Romans, Vikings, Normans, the black death and the two World Wars.

I feel that this is a major source of why Britain (and Europe to a larger extent) is unable to come to terms with reality on a majority of issues today - immigration, foreign policy, economic policy etc. They simply have not come to terms with the loss of their empires and the wealth they brought. So they choose to not teach it. This leads British institutions today to have a serious colonial hangover whether they know it or not. The operating paradigm is still an outdated one in many cases.

They teach students what they think made Britain great -- the Romans, the Norman invasion, the World Wars, Churchill etc. -- while actually glossing over what made them great: Empire. It really brings to mind a line from the Thor: Ragnarok movie - "Proud to have it; ashamed of how they got it". The British people today might not have an idea of their Empire but the effects still linger on in their former colonies.

By and large, I kind of echo what OP says here.

Go is at a weird place where the standard library is big that third party libraries aren't really required but not that big that it can do everything. So like OP says there is a huge thing with Go projects (and devs) about reinventing the wheel for each project. While sometimes this is fine (and even welcome because it offers you flexibility and customization), it is mostly really slowing down someone who wants to write a full-featured application with auth/ORM/web security etc.

You either have to write your own or try to use something that is actually really behind from what you're used to. And coming from a Python, all batteries-included ecosystem it's actually nuts. Our small team would have to dedicate a huge chunk of dev cycles to write our own plumbing. Dev cycles that we could have used writing business logic that actually made us money instead of writing yet another auth.

But having said that, I don't think Go is the language to write these kinds of apps in. So if you're trying to use Go to do that, you're obviously going to run into roadblocks. It's like trying to cut through metal with a pair of gardening shears. Can it be done? Yes. Can I choose the size and design of the shears? Yes. Can I modify or create my own shears? Yes. But is it the most efficient or appropriate tool for the job? Probably not.

IMO Go is ideal for server/CLI applications or even for web apps that interact with other services completely behind your network. But for most other things you're better using something else. Or you use it if your customer really wants to use Go and wants to pay you.

Go is like a tool used to build the plumbing and internal systems of your house, but not the house itself. Using Go is similar to casting and forging your own water pipes. Some people enjoy getting into the details of crafting those pipes, but most of us just want to install them and focus on the rest of the construction.

This is not a technical point but does anyone know which font was used to typeset the logo? It looks really nice and clean.

> It was to stress how the ludicrous track-record of Microsoft anticompetitive practices, establishing and sustaining a decades-long monopoly, barred non-expert and non-enthusiasts from experiencing (possibly favourable) alternatives.

My point served to counter this very statement.

There are alternatives (Linux, macOS, FreeBSD etc. etc.) but none are favorable like you say. A big part of why this is the excellent job that MSFT did as a technical force looking to consolidate Windows as the OS standard all those years ago. The efforts taken by them to ensure broad based application support and customer research and support on Windows has contributed to the continued perpetuation of their monopoly. Were they ever the most technically advanced option? No. Is any of their software products absolutely perfect and without deficiencies? Also no. And yet they are possible the leading software company in the world. This is NOT solely due to their anticompetitive practices. Saying so is a form of denial about the true state of things.

I gave Canonical and Ubuntu as an example of someone else who has tried to step in the breach and failed to force out MSFT as an alternative for non-experts and non-enthusiasts. Ubuntu and the FOSS community are many things but friendly to beginners and non-technical people is not one of them. There have been tremendous advances in the past decade but we're nowhere close to this being the Year of the Linux Desktop. The bottom line is that mainstream (i.e. non-technical and non-enthusiast) consumers will choose to put their money where they get the best value and that remains MSFT and Windows.

This might be a contrarian view to the rest of this thread but I think this is a decisive move by Microsoft. AI-enabled OSes are a part of the future (for mainstream consumers at the very least). By sticking with Recall despite the initial backlash, I think Microsoft is showing they're a serious player.

MSFT would not risk their enterprise and government business with features like Recall if they weren't sure that it had a need and requirement at some level. Fundamentally, MSFT isn't a company that preempts the needs of their users and haven't been for the past 25 years. They've lagged behind mobile and then cloud because none of their main customers thought they were important. They face they're going on the front foot is indicative that they have a larger strategic play going on here.

Coming to the product itself there appear to be sufficient controls in place on Recall. It's opt-in even if it cannot be uninstalled. It's all on-device and allocates specific space on the PC. I can specify if I don't want it to take snapshots of certain apps and it doesn't take snapshots of private browsing by default. IT teams can manage Recall through policies AND users can have further fine grained control over their settings beyond that. It's great that MSFT have included these right from the start because if we're frank, not all other tech companies would have thought it through.

Personally, I wouldn't use Recall but I can see the appeal and usefulness -- for both consumers and IT teams. You ask your computer what you did on so-and-so date and it'll tell you? That's great and what computers should do -- take cognitive load off of our minds. Plus it's a great audit trail in the office.

My only gripe with it -- as with anything MSFT really -- is security. I'm not entirely sure MSFT would be able to stop people writing malware that explicitly steal Recall data. I hope they have safeguards but being closed source that's the best we can expect unfortunately.

I know HN users are more likely to be anti-MSFT and more tech savvy than the average consumer -- it's a bit like the tech enthusiasts buying smart products and the senior engineer living alone in a forest off-grid. But what we have to remember that we're the exception than the rule. Most people are tech-illiterate and have no inclination towards learning more or towards spending more time with their computers. Products like this are for them.

> It should be forbidden to ship PCs with Windows preinstalled, unless the user made it a conscious purchase decision (and offered to choose between several options).

I don't know where you're buying PCs but where I'm from there is always an option to buy the PC with FreeDOS at a discount of about ~$20-30 compared to the Windows version. Lately, I also see an increase in Ubuntu computers.

> But then you can bet Microsoft lobbying won't let that happen.

I feel "MSFT lobbying" isn't charitable at all to what MSFT and their devs have achieved. You have to give credit where it's due. MSFT have spent a lot of time, effort and dev years ensuring that their customers can run their software without breakage and downtime. This is a non-trivial aspect that most people who don't use Windows often dismiss. MSFT have made themselves the standard platform because of their broad support. This is no mean feat. Canonical has tried for almost 20 years at this point and have barely made a dent with Ubuntu.

What I find really interesting is that all these studios who ran TV channels for so many years fumbled the bag when it came to streaming.. It's like all these people who basically were in content distribution didn't really wise up to the next, new thing in their business even as it happened in front of their eyes.

It's pretty wild that Paramount+/Disney+/Peacock or whatever really struggle to get going, especially given that they provide access to top shows that people really want to watch. It's like having Breaking Bad-esque product but really screwing up when it comes to wanting people to watch it.

Given the extent to which the tech behind streaming platforms -- storage, CDNs, tie-ups with telecoms -- have been standardized (and democratized, to some extent) by big players like YouTube and Netflix, you would think that a basic ad supported layer of any of these studio specific platforms would make many multiples of what they actually need to put in to setup a basic platform.

The tech's cheap and they already have the content. Most of the older content would be relatively low traffic -- hell, most of these old topical Comedy Central late night shows barely broke a million views when they were new and I don't think jokes about Saddam Hussein and GW's folksy demeanor would click now. How much would it really cost for any big studio to let people view these archives? Am I missing something big that causes somebody like Paramount to go $14B in debt trying to get people to use their streaming service? Is it a function of the business they're in or is it just a case of LA movie studio types not understanding tech?

I always find that whenever such topics come up for discussion Ted Gray had the best take - https://theodoregray.com/BrainRot/.

With AI and specifically LLMs, I feel many of the points raised here about 25 years ago still stands. Any LLM based learning isn't meant to push students into thinking about the problem or even guiding students along the path to the correct answer. It's mostly about returning some answer -- mostly right but not really of a good quality. As pointed out in Ted Gray's article, any assisted learning mechanism should work towards making the student think about the problem at hand and reason their way through it. It's an aide to the human teacher because, it being a machine and most importantly software, can adapt to each and every single student's ability and work at the student's pace instead of 3 periods of an hour each per week. An LLM by definition is the opposite. It gives you the next most probable character without any idea of what it's saying. There is a lot of work being done on this ofc, but what's available today isn't a reasoning aide/teacher.

I hadn't come across the ScriptForge library before so I just looked it up. It looks pretty cool and definitely looks like how MSFT should have worked on including Python in Excel. From my quick look, it looks like ScriptForge is primarily a BASIC which supports Python(?). So I can only imagine how much more powerful a Python specific library could be given the differences in Python and BASIC themselves.

> What I expected was a VBA editor for Python and maybe a library for Windows to access Excel objects from a Python script in a cmd or powershell prompt.

This is exactly it. The killer feature for including any modern scripting language in Excel. Both XlxsWriter and openpyxl can r/w from Excel files but I have to manipulate the data using another library like `pandas`. Instead if MSFT gave a library which I can import into a Python script and use like

  import msft_excel_lib as xl
  data = xl.get('A1:A3')
  sum = xl.sum(data)
  xl.write("B3", sum)

would be much better than whatever it is they have shipped today without having to make much changes to anything else. I wouldn't even grudge them if they say that this library can run under some weird virtual environment found only within Excel to maintain product retention.

The issue really rears its head when we consider that most are in the second category but "modern" frameworks like Next.JS don't really cater to that market.

I used React for a long time to build frontends for my REST APIs. When I started, CRA was the standard to get started with. CRA got deprecated and I wanted to shift to Next.JS since that seems to be a little more full-stack and I wanted built-in routing instead of relying on react-router. Once I got going on Next.JS everything turned out to be connected to Vercel. Even the tutorial at one stage expects you to sign up for a Vercel account. This really turned me off of React because there doesn't appear to be a single framework for people who want to build the latter category of web apps without either a) tying together multiple disparate modules/libs or b) signing up with 1 framework with 1 vendor. Either option doesn't appeal to me.

I shifted over to Angular (despite everything) because it seems to have finally stabilized and has a pretty good feature set for what I'm looking for. Plus build times on Amplify have really come down. Build times for similar sized apps take around 4 minutes(!) for React applications and routinely under and about 1 minute for Angular applications. I honestly just want a frontend framework where I can build a foundation fairly quickly and just get on with building features instead of worrying about if dependencies have suddenly been sunset or if the author made some breaking change to some key library I don't even interact with directly and right now this is Angular.

Python on LibreOffice appears to be more concerned with moving GUI elements and not enough with manipulating cells. There doesn't appear to be a straightforward library/module which helps me access specific cells and get their values. This would be a greater value proposition than allowing me to control Calc as a puppet using a Python script which seems to be their main idea.

I was quite excited when I heard Python was coming to Excel but the execution pretty much guarantees that adoption is going to be horrible. If I as MSFT wanted to get people to write Python scripts that can take advantage of Excel's great abilities this is probably the worst way I could have gone about it. A ham-fisted, cloud-first feature implementation that is basically jammed into the product without appropriate contextual abstractions is a pretty poor way to get things done. Given that Excel itself has a strong tabular object model built in, why would a DataFrame be required as a separate construct?

> We wanted an alternative to VBA, but got an alternative to the Excel formula language

Optimistically, I would guess that the powers that be inside MSFT wanted to show they "integrated" Python into Excel but didn't really want to mess too much with a product that has stabilized over the past 30 years. Cynically, I would say that they've messed up the implementation on purpose so they can put a bullet through the "Python in Excel" idea without actually doing anything useful.

A much better way to add Python (or any modern scripting language really) to Excel is to 1. Make a special library that can be called from the language and which only works with Excel. 2. Bundle a minimal interpreter so that the scripts can be run locally without pushing everything to some godforsaken Azure datacenter. Make this a downloadable plugin for all currently supported versions to ensure backwards-compatibility.

This is a much better way to ensure that Python becomes the glue language for Excel. There are so many applications where reporting, analysis and visualization can be better achieved through automation using scripting languages. VBA is old, limited and is yet another thing for someone to learn if they want to script any Office product. All of these are hurdles that can be easily removed. I guess though that the part that really sucks is that these are all things that the MSFT of the 80s/early 90s would have done in a heart beat if it meant more people would use Excel (they built in bugs from Lotus 1-2-3 for God's sake) but I guess it's a different story today when everybody does use Excel.

I agree with the essence of what you're saying.

It's always been my opinion that the FSF screwed the pooch when it came to spreading their message. This starts right from their very name - the "Free" Software Foundation. Anyone of didn't know their message would understand them to be a group arguing that all software should be free of charge. This is completely orthogonal to their actual message of software having the ability to be easily understood and customized as needed by a tech-savvy user who has fairly compensated the original authors. They aimed for and missed badly the sweet spot message that all software should make simple things simple and complex things possible.

This expectation that users should not have to pay for the apps/software they use has partly lead to the dystopian landscape that is our ad-supported modern software experience. Users today think they're entitled to the same standard for all software they use. They expect LibreOffice Calc to be having the same feature set as MS Excel while at the same time paying nothing for it.