Nobody can predict what Apple will do tomorrow, but as of today, they aren't really pushing Siri/Apple intelligence really hard particularly after initial setup. None of most of the above for example.

I don't know what happens with Home Edition, but I though the pushback was mainly from Insider Preview?

You can't even select a cell on notepad without a freaking copilot button pooping up every single time. Same on word, that's maddening !

You could argue that windows isn't Microsoft copilot 365, but then, why do people even use windows ? It's always because of the office, my bad, copilot 365 suite.

I think OS level integrations that are opt-in, not opt-out, may even be popular. But they have to be done carefully and tastefully.

Do you know what you'll be moving to to replace what Workspace provides (email/IdP/calendar/Chrome policy management?)

The whole Gemini thing is just a massive embarrassment for Google I really can't follow their thinking, you'd think that after the Google '+' debacle that they would have learned their lesson not to cannibalize your old products to launch a new one.

The closest to useful it's been is in the GCP console, but it seems to decide at random to forget context, and it might just be Gemini Flash with minimal thinking, which tends to mean it's just repeating things it's already said.

Fixing long-standing complaints, removing Copilot from obnoxious places, improvements to Windows Update and Windows Explorer stability/microstutter/lag, etc.

I congratulate them on seeing sense, and I congratulate Apple on another victory with the Neo. Kind of frustrating that's what it took for Microsoft to finally listen to their userbase.

The author of this commitment is the same person (Pavan Davuluri) spearheading move of Windows into an Agentic OS: https://www.windowscentral.com/microsoft/windows-11/windows-...

My reasoning is from bitter experience. I saw too many these honest talks/commitments - it always this pattern when product/company starts to decline. Suddenly somebody with technical background shows up talks about past mistakes and what need to fix. Even sometimes holds discussion, which is usually very reasonable. But as time goes there only cosmetic changes with excuses like lack of resources, market wind changed this time, too hard make changes due politics and etc.

The only thing I'd add is that not only did he tweet the infamous tweet that caused the backlash, Pavan ridiculed those in the backlash (since deleted). Also, Satya still spews the same "agentic OS" narrative as recent as last week.

So, I hope for the best, but I don't plan on taking them at their word.

Look where we are now.

Unless you really think we've reached the pinnacle of user interface with repetitive clicking around and menus.

The problem is with shoving AI down user's throats. Make it an option, not the only option.

Maybe? For a couple of decades, we believed that computers you can talk to are the future of computing. Every sci-fi show worth a dime perpetuated that trope. And yet, even though the technology is here, we still usually prefer to read and type.

We might find out the same with some of the everyday uses of agentic tech: it may be less work to do something than to express your desires to an agent perfectly well. For example, agentic shopping is a use case some companies are focusing on, but I can't imagine it being easier to describe my sock taste preferences to an agent than click around for 5 minutes and find the stripe pattern I like.

And that's if we ignore that agents today are basically chaos monkeys that sometimes do what you want, sometimes rm -rf /, and sometimes spend all your money on a cryptocurrency scam. So for the foreseeable future, I most certainly don't want my OS to be "agentic". I want it to be deterministic until you figure out the chaos monkey stuff.

As I use AI more and more to write code I find myself just implementing something myself more and more for this reason. By the time I have actually explained what I want in precise detail it's often faster to have just made the change myself.

Without enough detail SOTA models can often still get something working, but it's usually not the desired approach and causes problems later.

typing "open hackernews" into copilot instead of clicking the browser and typing hackernews?

99% of OS interactions already boil down to 2 clicks and a search phrase.

- "Plan my summer vacation with my family, suggest different options"

- "Look at my household budget and find ways to be more frugal."

There are thousands of things I can think of when it comes to how an agentic OS would work better than the current Screen Keyboard paradigm. I mean all these things I could now do with Claude or Codex and some of these things I already do with these tools.

> Plan my summer vacation with my family, suggest different options

What part of this does an agentic OS help with? My OS doesn't know my travel preferences, family size, work schedule, etc.

These are more appropriate tasks for a smart assistant.

What specifically does an agentic OS UX look like beyond giving claude access to local files and a browser?

huh? ... this reads to me like you don't need an "agentic" OS to do the things you'd want to use an "agentic" OS for..?

like... it seems you just don't want a keyboard to do the same things you've already been doing? ... is that the crux of it?

https://www.youtube.com/watch?v=Bmz67ErIRa4

i feel like someone high up in microsoft probably has this pinned in a epic or something somewhere

I think you and I have very different meanings of "intelligent", "understands" and "gets it done"

https://www.youtube.com/watch?v=GV01B5kVsC0

See how that sounds a bit silly? It's because it presents a false dichotomy. That our choice is between either the current state of interfaces or an agentic system which strips away your autonomy and does it for you.

There's everything wrong when "agentic" means that the regular bread-and-butter functionality of the OS becomes unusable.

Communicating and predicting desires, preferences, thoughts, feelings from one mind to another is difficult.

Fundamentally the easiest way of getting what you want is to be able to do it yourself.

Introduce an agent, and now you get the same utility issues of trying to guess what gifts to buy someone for their birthday. Sure every now and then you get the marketers "surprise and delight", but the main experience is relatively middling, often frustrating and confusing, and if you have any skill or knowledge in The area or ability to do it yourself, ultimately frustrating.

When that completely didn't work, we thought that augmented reality was the future of the computer, which also didn't work out.

You need a screen to be able to verify what you're doing (try shopping on Amazon without a screen), which means you also need a UI around it, which then means voice (and by extension agents which also function by conversation) is slower and dumber than the UI, every time.

Meanwhile I have yet to see any brand excited to be integrated with ChatGPT and Claude. Unlike a consumer; being a purely "reasoning-based" agent, they're most likely to ignore everything aesthetic and pick the bottom of the barrel cheapest option for any category. How do you convince an AI to show your specific product to a customer? You don't.

https://serverfault.com/questions/337082/

I see nothing about privacy, spying, forced microsoft accounts and continued locking down of windows that they've been doing.

I see that they're bringing back _some_ of the taskbar options you had in windows 10 (termed it as "introducing"), they promise to make Explorer faster, great. But they also say they're bringing more AI into windows and something about widgets that I don't think anyone cares about.

And lastly they're promising to revamp the place where you go to rant at microsoft, but they're not promising to actually listen to feedback.

Yep. That stuff makes money (via upsells) so it will never be removed.

Online accounts are fine when optional, but unacceptable when forced.

How is it even possible to spend 4-5 seconds to show a list of files in a local freaking folder?

Now all folders with media files open immediately. Also if you want no wait for video files folders, right click in the folder and select 'View -> Details or View -> List or some other option where it doesn't create thumbnails and it'll load even quicker.

I'm sorry, this is very funny to me in the context of the person upthread arguing about how great "agentic OSes" are. Some people seem to believe that we're living in the future, but I'm pretty sure we're still stuck in Windows '95.

Surely you don't mean remove all columns, and if you did you wouldn't have to also specify removing media metadata columns?

When such basic tasks are failing spectacularly, nobody can have any confidence that complex things can be achieved reliably. Instead of spying on their users and trying to squeeze more and more money from them, they should first focus on making a great product and work on making it better, not researching ways to enshitify things.

That's a why, but it raises more questions than it does answers.

I need that Drake meme here, where he's negative about the idea "Optimize the calculator layout to improve the UX" and very enthusiastic about the idea "Find ways to get incremental revenue from users of Calculator with ads or selling of data"

We're reaching Microslop levels we never thought possible. I actually think Claude Code would have done a better job.

No. "Commitment" in corporate speak is a synonym for "absolute lack of intention". That's why corps 'commit' to reducing emissions, treating employees fairly, etc, ie. to all the things they will not do. But no suit 'commits' to making money. They just make money. It's just a superficial linguistic gesture. Shakespeare got it.

Saying and doing are very different. They have passed through the "fuck around" phase, and are entering the "find out" phase of this AI journey. Lots of companies are, suddenly.

My employer trained us all on the Gartner hype cycle, tested us on how to remain level-headed before and during the peak of unreasonable expectations and now every single manager in the company is drooling over AI, saying that "this is the future, join us or find another job" and I cannot wait for the curve to come back down to a sane level where intelligence rules behavior as much as it used to. We'll see.

We’ve certainly done the “fucking around” and now we'll see if we "find out" enough to regain our sanity and our humanity.

(that's an overstatement, early OS X were buggy too, but they just switched to Unix after OS9, so, understandable.)

it's just better than Windows, which is just aggressively bad. (and I guess Linux is eating their gamers market with Proton? but I am not a gamer)

- The OS is getting buggier, with every large update getting press coverage on scary bugs.

- The OS is getting overbearing; constant nagging for upsells on Microsoft products with terrible attach rates.

- The OS is getting focused on hype; the latest trend is AI?Let's force a new button on people that will break decades-old workflows. Let's put AI everywhere.

- The OS is getting slow; there's no focus on speed and the place where 85% of the market resides (laptops) is getting completely trounced by Apple Silicon.

- The OS is getting squeezed; under 300$ it's all terrible e-waste in six months Chromebooks. Over 500$ Apple is aggressively entering the market with the Neo. Over 1,000$ Apple has owned a commanding share of the profits there for decades.

There are 994 more problems with Windows but I've made my point; there's just no end in sight to the problems with Windows. I haven't mentioned it's become a minor part of Microsoft's profits!

They are not saying "we will remove the mandate to use a Microsoft Account." By itself, that shows their "care" is purely corporate, likely driven to calm down furious OEMs who will happily remind them Apple doesn't need an Apple Account to use a now-cheap Mac.

Also, because Nadella can't stand the word, I'll say it right here: Microslop is still making Winslop to help people make Officeslop to then upload to Slopdrive.

And, yes, I am aware that Pro/Enterprise don't suffer from this, but a LOT of computers sold are Windows Home/OEM licenses. It impacts a ton of people.

People claim, you can use Claw-agents more safely while getting some of the benefits, by essentially proxying your services. For example on Gmail people are creating a new Google accounts, forwarding email via rule, and adding access to their calendar via Google's Family Sharing. This allows the Claw agent to read email, access the calendar, but even if you ask it to send an email it can only send as the proxy account, and it can only create calendar appointments then add you as an attendee rather than destroy/altering appointments you've made.

Is the juice worth the squeeze after all that? That's where I struggle. I think insecure/dangerous Claw-agents could be useful but cannot be made safe (for the logical fallacy you pointed out), and secure Claw-agents are only barely useful. Which feels like the whole idea gets squished.

Your Gmail account vs my Gmail account. Your macOS account vs my macOS account.

Yes, I can spam you from my Gmail. Yes, I can use sudo on my Mac and damage your account. But the impact is by default limited.

The answer is to just treat assistants as a different user profile, use the same sharing mechanisms already developed (calendar sharing, etc), and call it a day.

Problem: I want to accomplish work securely.

Solution: Put granular permission controls at every interface.

New problem: Defining each rule at all those boundaries.

There's a reason zero trust style approaches won out in general purpose systems: it turns out defining a perfect set of secure permissions for an undefined future task is impossible to do efficiently.

Isn't it a question of when they will be "safe enough"? Many people already have human personal assistants, who have access to many sensitive details of their personal lives. The risk-reward is deemed worth it for some, despite the non-zero chance that a person with that access will make mistakes or become malicious.

It seems very similar to the point when automated driving becomes safe enough to replace most human drivers. The risks of AI taking over are different than the risks of humans remaining in control, but at some point I think most will judge the AI risks to have a better tradeoff.

When Anthropic is willing enough to stand behind their agents strongly enough to accept liability for their actions, we can talk.

We have a legacy Win32 application, and we want to side-by-side compare interactions + responses between it and the web-converted version of the same. Once you've taught the model that "X = Y" between the desktop Vs. web, you've got yourself an automated test suite.

It is possible to do this another way? Sure, but it isn't cost-effective as you scale the workload out to 30+ Win32 applications.

> The more capabilities you add to a interchange format, the harder that format is to parse.

There is a reason why JSON is so popular, it supports so little, that it is legitimately easy to import. Whereas XML supports attributes, namespaces, CDATA, DTDs, QNames, xml:base, xml:lang, XInclude, etc etc. They gave it everything, including the kitchen sink.

There was a thread here the other day about using Sqlite as an interchange format to REDUCE complexity. Look, I love Sqlite, as an application specific data-store. But much like XML it has a ton of capabilities, which is good for a data-store, but awful for an interchange format with multiple producers/consumers with their own ideas.

CSV may be under-specified, but it remains popular largely due to its simplicity to produce/consume. Unfortunately, we're seeing people slowly ruin JSON by adding e.g. commands to the format, with others than using those "comments" to hold data (e.g. type information), which must be parsed. Which is a bad version of an XML Attribute.

I know some implementations of JSON support comments and other things, but is is not true JSON, in the same way that most simple XML implementations are not true XML. That's what I say "opposite problem", XML is too complex, and most practical uses of XML use incomplete implementations, while many practical uses of JSON use extended implementations.

By the way, this is not a problem for what JSON was designed for: a text interchange format, with JS being the language of choice, but it has gone beyond its design: configuration files, data stores, etc...

In a programming language it's usually free to have comments because the comment is erased before the program runs; we usually render comments in grey text because they can't change the meaning of the program.

In a data language you have no such luxury. In a data language there's no comment erasure happening between the producer and the consumer, so comments are just dangerous as they would without doubt evolve into a system of annotations -- an additional layer of communication which would then not be standardized at all and which then would grow into a wild west of nonstandard features and compatibility workarounds.

But there's nothing stopping you from commenting your JSON now. There's no obligation to use every field. There can't be, because the transfer format is independent of the use to which the transferred data is put after transfer.

And an unused field is a comment.

    {
      "customerUUID": "3"
      "comment": "it has to be called a 'UUID' for historical reasons"
    }

IIRC Douglas Crockford explicitly stated that he saw people initially using comments for a purpose like ad hoc preprocessor directives.

Since EDI is meant for processing large numbers of transactions as quickly as possible, I hate to think what the move to XML did to that. I moved on years ago so I don't now whether they just threw more hardware at the problem to achieve the same thing that EDI already gave them but now with angle brackets, or whether the industry gave up on XML because of its poor performance.

Come to think of it I'm pretty sure they would have tried blockchain when that got trendy as well.

Yaml is fugly, but it emerged from JSON being unsupportive of comments. Now we’re stuck with two languages for configuration of infrastructure, a beautiful one without comments so unusable, the other where I can never format a list correctly on the first try, but comments are ok.

  command:
    - /bin/sh    
    - -c
    - rm -rf $HOME

  state: >
    {% set foo = states('...') %}
    {% set bar = states('...') %}
    {% if foo == FOO and bar == BAZ %} 
    ...

  {"command": [
    "/bin/sh",
    "-c",
    "rm -rf $HOME"
  ]}

It is more fair to say that if your document needs to contain scripting, YAML is a better choice than JSON; for the singular reason that YAML allows for unquoted multiline strings, which means you can easily copy/paste scripts in and out of a YAML document without needing to worry about escaping and unescaping quotes and newline characters when editing the document.

And if you want something like JSON that allows comments, and you aren't working on the web, Lua tables are fine.

But what can we expect from a spec that somehow deems comments bad but can't define what a number is?

A given programming language may not have a built in representation for rational numbers in general. That isn't the fault of json.

The usual complaint about numbers not being well-defined in JSON is that you have to provide all numbers as strings; 13682916732413492 is ill-advised JSON, but "13682916732413492" is fine. That isn't technically a problem in JSON; it's a problem in Javascript, but JSON parsers that handle literals the same way Javascript would turn out to be common.

Your "defense", on the other hand, actually is a lack in JSON itself. There is no way to represent rational numbers numerically.

So far you haven't really shown an example of a json number which has an ambiguous or ill defined interpretation.

Maybe you mean that json numbers may not fit into 32 bit integers or double floats. That's certainly true but I don't see it as a deficiency in the standard. There is no limit on the size of strings in json, so why have a limit on numbers?

Why did you say this?

https://dn790008.ca.archive.org/0/items/ps-doc-struc-conv-3/...

"Use of the document structuring conventions... allows PostScript language programs to communicate their document structure and printing requirements to document managers in a way that does not affect the PostScript language page description"

The idea being that those document managers did not themselves have to be PostScript interpreters in order to do useful things with PostScript documents given to them. Much simpler.

For example, a page imposition program, which extracts pages from a document and places them effectively on a much larger sheet, arranged in the way they need to be for printing 8- or 16- or 32-up on a commercial printing press, can operate strictly on the basis of the DSC comments.

To it, each page of PostScript is essentially an opaque blob that it does not need to interpret or understand in the least. It is just a chunk of text between %%BeginPage and %%EndPage comments.

This is tremendously useful. A smaller scale of two-up printing is explicitly mentioned as an example on p. 9 of the spec.

That's pretty much what already happens. Getting a numeric value like "120" by serializing it through JSON takes three bytes. Getting the same value through a less flagrantly wasteful format would take one.

I guess that's more than 25%. In the abstract ASCII integers are about 50% waste. ASCII labels for the values you're transferring are 100% waste; those labels literally are comments.

If you're worried about wasting bandwidth on comments, JSON shouldn't be a format you ever consider, for any purpose.

lol

That's inherent to the language specification, but it isn't inherent to the document. You have to have a system with rules that require that erasure.

Nothing prevents one from mandating a system that strips those comments out of JSON. You could even "compile" JSON to, I don't know, BSON or msgpack or something.

Just as nothing prevents one from creating tooling to, say, extract type annotations from comments in a dynamically typed language.

Agreed —— consider how comments have been abused in HTML, XML, and RSS.

Any solution or technology that can be abused will be abused if there are no constraints.

1. Attributes should not exist. They make the document suddenly have two dimensions instead of one, which significantly increases complexity. Anything that could be an attribute should actually be a child element.

2. There should be one close tag: `</>` which closes the last element, which burns a significant amount of space with useless syntax. Other than that and the self-closing `<tag />` (which itself is less useful without attributes) there isn't much that you need. Maybe a document close tag like `<///>`

You'll notice that, yes, JSON solves both of those things. That's a part of why it's so popular. The other is just that a lot more effort was put into maximizing the performance of JavaScript than shredding XML, and XSLT, the intended solution to this problem, is infamous at this point.

The problem of comments is kind of a non-issue in practice, IMO. You can just add a `"_COMMENT"` element or similar. Sure, yes, it will get parsed. But you shouldn't have that many comments that it will cause a genuine performance issue.

However, JSON still has two problems:

1. Schema support. You can't validate that a file before de-serializing it in your application. JSON Schema does exist, but it's support is still thin, IMX.

2. Many serializers are pretty bad with tabular data, and nearly all of them are bad with tabular data by default. So sometimes it's a data serialization format that's bad at serializing bulk data. Yeah, XML is worse at this. Yeah, you can use the `"colNames": ["id", ...], "rows": [ [1,...],[2,...] ]` method or go columnar with `"id": [1,2,...], "name": [...], "createDate": [...]`, but you had better be sure both ends can support that format.

In both cases, it seems like there is an attempt to resolve both of those issues. OpenAPI 3.1 has JSON schema included in it. The most popular JSON parsers seem to be adding tabular data support. I guess we'll see.

Using XML as a structured data interchange format is abuse. Of course the square peg doesn't fit in the round hole. You propose filing off the corners of the square, making it an octagon, so it will fit the round hole better.

  <p>
  <style>
  @scope { font-family: "Arial" ; }
  </style>
  Prospero: Where in the world is my teapot? Hello? I'm waiting! 
  </p>

To wit, it seems to me a style issue.

[1] Apple has long used XML plists for data ~ interchange or even archival storage such as .webarchive (ie just a plist flavor). Of course they soon added a simple binary version to compress out some redundancy and encoding waste.

They used an XML nested tag approach, not attributes. Maybe not well rounded pegs and holes but it has worked for them on a large scale over a long time.

1. I think attributes absolutely should exist. They're great for describing metadata related to the tag: e.g. element ID, language, datatype, source annotation, namespacing. They add little in complexity.

2. The point of a close tag with a name is to make it unambiguous what it's trying to close off.

It sounds to me like what you want is not a better XML, but just s-exprs. Which is fine, but not quite solving the same problem.

3. As far as schema support, it seems to me that JSON Schema is well-established and perfectly cromulent – so much so that YAML authors are trying to use it to validate their stuff (the poor bastards) – and XML schema validation, while robust, is a complex and fragmented landscape around DTD, XSD, RELAX-NG, and Schematron. So although XML might have the edge, it's a more nuanced picture than XML proponents are claiming.

4. As far as tabular data, neither XML nor JSON were built for efficient tabular data representation, so it shouldn't be a surprise that they're clunky at this. Use the right tool for the job.

No, they're barely adequate for those purposes. And you could (and if you have a XSD you probably should) still replace them with elements. If you argue that you can't, then you're arguing that JSON does not function. You can just inline metadata along side data. That works just fine. That's the thing about metadata. It's data!

You don't need attributes. Having worked in information systems for 25 years now, they are the most heavily, heavily, heavily misused feature of XML and they are essentially always wrong.

Because when someone represents data like this:

  <Person>  
    <ID>90034</ID>  
    <FirstName>Anthony</FirstName>  
    <MiddleName />
    <LastName>Perkins</LastName>  
    <Site>4302</Site>  
  </Person>  

On the other hand, if you do this:

  <Person ID="90034"  
    FirstName="Anthony"  
    MiddleName=""
    LastName="Perkins"  
    Site="4302" />

That's the problem with XML. It's so flexible it lets developers be stupid, while also claiming strictness and correctness as goals.

> 2. The point of a close tag with a name is to make it unambiguous what it's trying to close off.

Sure, but the fact that closing tags in the proper order is is mandatory, you're not actually including anything at all. The only thing you're doing is introducing trivial syntax errors.

Because the truth is that this is 100% unambiguous in XML because the rules changed:

  <Person>  
    <ID>90034</>  
    <FirstName>Anthony</>  
    <MiddleName />
    <LastName>Perkins</>  
    <Site>4302</>  
  </>  

Named closing tags had more of a point when we were actually writing XML by hand and didn't have text editors that could find the open and close tags for you, but that is solved. And now we have syntax highlighting and hierarchical code folding on any text editor, nevermind dedicated XML editors.

> 3. As far as schema support, it seems to me that JSON Schema is well-established and perfectly cromulent

Then my guess is that you have worked exclusively in the tech industry for customers that are also exclusively in the tech industry. If you have worked in any other business with any other group of organizations, you would know that the rest of the world is absolute chaos. I think I've seen 3 examples of a published JSON Schema, and hundreds that do not.

> 4. As far as tabular data, neither XML nor JSON were built for efficient tabular data representation, so it shouldn't be a surprise that they're clunky at this. Use the right tool for the job.

No, I think you're looking at what the format was intended to do 25 years ago and trying to claim that that should not be extended or improved ever. You're ignoring what it's actually being used for.

Unless you're going to make data queries return large tabular data sets to the user interface as more or less SQLite or DuckDB databases so the browser can freely manipulate them for the user... you're kind of stuck with XML or JSON or CSV. All of which suck for different reasons.

2. As far as JSON Schema, you're wrong on all acounts – wrong that I haven't seen Some Stuff, wrong that JSON schema doesn't get used (see Swagger/OpenAPI), and wrong that XML Schema doesn't also get underitilized when a group of developers get lackadaisical.

3. As far as what historical use has been, I'm less interested in exhuming historical practice than simply observing which of the many use cases over the last 20 years worked well (and still work) and which didn't. The answer isn't that none of them worked, and it certainly isn't that XML users had a better bead on how to use it 20 years ago – it went through a massive hype curve just like a lot of techs do.

4. Regarding tabular data exchange, I stand by my statement. Use XML or JSON if you must, and sometimes you must, but there are better tools for the job.

    <myobject foo="bar"/>
    // means roughly
    new MyObject(foo="bar")

    <myobject>
      <foo>bar</foo>
    </myobject>

If you want to support the wider XML ecosystem, with all the complex auxiliary standards, then yes, it's a lot of work, but the language itself isn't that awful to parse. It's a little messy, but I appreciate it at least being well-specified, which JSON is absolutely not.

CSTML is my attempt to fix all these issues with XML and revive the idea of HTML as a specific subset of a general data language.

As you mention one of the major learnings from the success of JSON was to keep the syntax stupid-simple -- easy to parse, easy to handle. Namespaces were probably the feature to get the most rework.

In theory it could also revive the ability we had with XHTML/XSLT to describe a document in a minimal, fully-semantic DSL, only generating the HTML tag structure as needed for presentation.

JSON treats text as one of several equally-supported datatypes, and quotes all strings. Great if your data is heavily structured, and text is short and mixed with other types of data. Awful if your data is text.

XML and other SGML apps put the text first and foremost. Anything that's not text needs to be tagged, maybe with an attribute to indicate the intended type. It's annoying to express lots of structured, short-valued data. But it's simple and easy for text markup where the text predominates.

CSTML at first glance seems to fall into the JSON camp. Quoting every string literal makes plenty of sense in JSON, but not in the HTML/text-markup world you seem to want to play in.

I wouldn't say we fall into the JSON camp at all though, but quite squarely into the XML-ish camp! We just wrap the inner text in quotes to make sure there's no confusion between the formatting of the text stored IN the document and the formatting of the document itself. HTML is hiding a lot of complexity here: https://blog.dwac.dev/posts/html-whitespace/. We're actually doing exactly what the author of that detailed investigation recommends.

You can see how it plays out when CSTML is used to store an HTML document https://github.com/bablr-lang/bablr-docs/blob/1af99211b2e31f.... Having the string wrappers makes it possible to precisely control spaces and newlines shown to the user while also having normal pretty-formatting. Compare this to a competing product SrcML which uses XML containers for parse trees and no wrapper strings. Take a look at the example document here: https://www.srcml.org/about.html. A simple example is three screens wide because they can't put in line breaks and indentation without changing the inner text!

It's particularly gratifying that you can easily interpret CSTML with a stream parser. XML cannot work this way because this particular case is ambiguous:

  <Name

That's why we write `<Namespace:Name />` as `:Namespace: <Name />` - it means there's no point in the left-to-right parse at which the meaning is ambiguous. And finally CSTML has no entity lookups so there's no need to download a DTD to parse it correctly.

I don't think anyone designs formats this way, and I doubt any popular formats are designed for this. I'm not that familiar with enterprise/big-data formats so maybe one of them is?

For example: CSV is great, but obviously limited, and not specified all that well. A replacement table data format could be binary (it's 2026, let's stop "escaping quotes", and make room for binary data). Each row can have header metadata to define which columns are contained, so you can skip empty columns. Each cell can be any data format you want (specifically so you can layer!). The header at the beginning of the data format could (optionally) include an index of all the rows, or it could come at the end of the file. And this whole table data format could be wrapped by another format. Due to this design, you can embed it in other formats, you can choose how to define cells (pick a cell-data-format of your choosing to fit your data/type/etc, replace it later without replacing the whole table), you can view it out-of-order, you can stream it, and you can use an index.

It looks neat when you illustrate it with stacked boxes or concentric circles, but real-world problems quickly show the ugly seams. For example, how do you handle encryption? There are arguments (and solutions!) for every layer, each with its own tradeoffs. But it can't be neatly slotted into the layered structure once and for all. Then you have things like session persistence, network mobility, you name it.

Data formats have other sets of tradeoffs pulling them in different directions, but I don't think that layered design would come near to solving any of them.

https://industrialdigitaltwin.org/

(Disclaimer: I work on AAS SDKs https://github.com/aas-core-works.)

If we really wanted to make a UTF-8 data interchange format that needs minimal escaping, we already have ␜ (FS File Separator U+001C), ␝ (GS Group Separator U+001D), ␞ (RS Row Separator U+001E), ␟ (US Unit Separator U+001F). The problem is that they suck to type out so they suck for character based interchange. But we could add them to that emoji keyboard widget on modern OSs that usually gets bound to <Meta> + <.>.

But if we put those someplace people could easily type them, that resolved the problem.

But, binary data? Eh, that really should be transmitted as binary data and not as data encoded in a character format. Like not only not using Base64, but also not using a character representation of a byte stream like "0x89504E470D0A1A0A...". Instead you should send a byte stream as a separate file.

So we need a way to combine a bunch of files into a streaming, compressed format.

And the thing is, we already have that format. It's .tar.lz4!

But you don't have to use all those things. Configure your parser without namespace support, DTD support, etc. I'd much rather have a tool with tons of capabilities that can be selectively disabled rather than a "simple" one that requires _me_ to bolt on said extra capabilities.

A simple dsl can be implemented in many programming languages very cheaply and can easily be verified against a specification. S-expressions are probably the most trivial language to write parsers for.

JSON is also pretty simple, but the spec being underspecified leads to ambiguous parsing (another security issue). In particular: duplicate key handling, key order, and array item order are not specified and different parsers may treat them differently.

Thus people go with custom parsers (how hard can it be, right?), and then have to keep fixing issues as someone or other submits an XML with CDATA in or similar.

And it works more or less OK until someone comes along who doesn't know that you don't use X, and it's in the standard so your implementation isn't standards-compliant and we'll go with your competitor over there instead because unlike you they do support it.

And so, over time, all the crap that "everyone knows" you don't use, gets activated and used. Speaking from experience here, not an invented edge case.

It's a pretty well understood problem and best practices exist, not everyone implements them.

People will blithely parrot, "it's a poor Workman who blames his tools." But I think the saying, as I've always heard it used to suggest that someone who is complaining is a just bad at their job, is a backwards sentiment. Experts in their respective fields do not complain about their tools not because they are internalizing failure as their own fault. They don't complain because they insist on only using the best tools and thus have nothing to complain about.

You just classified probably every single bank in existence as "unserious organization"

In terms of interchange formats these are quite popular/common: EDI (serialized as text or binary), CSV, XML, ASN.1, and JSON are extremely popular.

I 100% assure everyone reading that their personal information was transmitted as CSV at least once in the last week; but once is a very low estimate.

Not because they use CSV's but because, as an industry, they have not figured out how to reliably create, exchange, and parse well-formed CSV's.

An organization that cared about data integrity absolutely could make CSV work. But that same organization would not use CSV because there would be no point in putting themselves through that kind of Mickey Mouse exercise.

CSV is probably the most low tech, stack-insensitive way to pass data even these days.

(I run & maintain long term systems which do exactly that).

Unless the junior developers start accepting lower salaries once they become senior developers, that is a fact. Do you mean that they think junior developers are cheaper even when considering the cost per output, maybe?

* YAML, with magical keywords that turn data into conditions/commands * template language for the YAML in places when that isn't enough * ....Python, because you need to eventually write stuff that ingests the above either way .... ansible is great isn't it?"

... and for some reason others decide "YES THIS IS AWESOME" and we now have a bunch of declarative YAML+template garbage.

> There was a thread here the other day about using Sqlite as an interchange format to REDUCE complexity. Look, I love Sqlite, as an application specific data-store. But much like XML it has a ton of capabilities, which is good for a data-store, but awful for an interchange format with multiple producers/consumers with their own ideas.

It's just a bunch of records put in tables with pretty simple data types. And it's trivial to convert into other formats while being compact and queryable on its own. So as far as formats go, you could do a whole lot worse.

ISO 8879 (SGML) doesn't define an API or a set of required language features; it just describes SGML from an authoring perspective and leaves the rest to an application linked to a parser. It even uses that term for the original form of stylesheets ("link types", reusing other SGML concepts such as attributes to define rendering properties).

SGML doesn't even require a parser implementation to be able to parse an SGML declaration which is a complex formal document describing features, character sets, etc. used by an SGML document, the idea being that the declaration could be read by a human operator to check and arrange for integration into a foreign document pipeline. Even SCRIPT/VS (part of IBM's DCF and the origin of GML) could thus technically be considered SGML.

There are also a number of historical/academic parsers, and SGML-based HTML parsers used in old web browsers.

Ah, the old "throw a bag of nouns at the reader and hope he's intimidated" rhetorical flutist. These things are either non-issues (like QName), things a parser does for you, or optional standards adjacent to XML but not essential to it, e.g. XInclude.

There are two kinds of XML parsers: those which are secure and those which are correct.

The accusation here is a defleciton. OP's point isn't a gish gallop, it's that xml is absolutely littered with edge cases and complexities that all need to be understood.

> optional standards adjacent to XML but not essential

This is exactly OP's point. The standard is everything and the kitchen sink, except for all the bits it doesn't include which are almost imperceptible from the actual standard because of how widely used they are.

Probably the same kind of person who tries to praise JSON's lack of comments as a feature or something.

IME there are two kinds of xml implementations, ones that handle DTDs and entitie definitions for you and are insecure by default (XXE and SSRF vulnerabilities), and ones that don't and reject valid XML documents.

- If you already HAVE a computer and are looking for models: LLMFit

- If you are looking to BUY a computer/hardware, and want to compare/contrast for local LLM usage: This

You cannot exactly run LLMFit on hardware you don't have.

They need to introduce something below the Standard license targeting the Neo. What I'd personally consider is:

- Standard gets 16 GB vRAM (to perfectly target the base MacBook Air). But leave it at 4-6 vCPUs to not compete with the Pro (still for general computing, not power-users)

- New "Lite" tier with 8 GB vRAM max for the Neo (4 vCPUs). Increasing to 12 GB vRAM if the Neo does.

Then you target a $89 price point one-time-purchase for the "Lite" tier. Essentially three plans, targeting your three major demographics: budget, standard, and pro/power-user.

[1] https://samhenri.gold/blog/20260312-this-is-not-the-computer...

[2] https://www.youtube.com/watch?v=PbPCGqoBB4Y

You took what I said out of context and then replied to something else. Running Parallels on a Neo is a novelty. Parallels is both what the thread is about AND what my reply was expressly about.

Nobody can reasonably read what I wrote, in context, and believe I was referring to the computer itself as a novelty.

Someone suggested that people with 10k karma and/or 10 years subscription to this site should be able to do things (such as auto-ban) to those accounts.

The account that misrepresented your comment and thus acted in bad faith is one of those 10k+ accounts.

To me, this is a data point showing the fallacy of long term subscription and/or karma accrual as evidence of their quality/good faith abilities

These won't run Crysis, but they don't need to.

The last version of Windows that felt like 4GB of RAM was performant for me with applications was Windows XP. Not that every computer running the 32-bit edition of Windows XP could even see/utilize a full 4GB of RAM properly, but at least it was fast.

Though I get by just fine with 512MB on my favorite Pentium 3 XP system. :D

A SSD would have made an absolutely massive difference.

Source: I have clients that still have 2nd/3rd gen i5 systems running 3-4 GB of RAM with Windows 10 and they're tolerable solely thanks to SSDs. Swapping that much on a hard drive would just be painful to use.

Nobody should be interactively using a computer post-2018ish (whenever SSDs fell below $1/GB) that's booting and running primary applications off spinning rust. They're perfectly fine for bulk storage drives but anyone waiting for an operating system booting off one has wasted enough of their life in the last year to have paid for the SSD. Companies that wouldn't spend $100 on an upgrade are literally throwing money away paying their employees to wait on a shit computer.

And if they can do that, they can get them (at full MSRP) for about half the price of a MacBook Neo.

Heck, you can get 8GB Windows laptops with twice the SSD size of the MacBook Neo's for a little over half of the Neo’s price (again, at full MSRP.)

Let's see one of these $300 Windows laptops with 512GB of SSD (in a reasonable format, e.g. not an SD card), a body that isn't disposable, a screen that isn't a dim potato, a CPU that's within 20% of the Neo's performance, and a GPU that isn't embarrassed to be called a GPU.

I doubt they exist.

I think you're misunderstanding, of course they do not exist. People don't get $300 windows laptops for their performance, build quality, or anything similar. Nor do they care about screen brightness, and 256GB is fine for the use case which is running word or some other simple application for as little $$ as possible.

I also got two N100 NUC like boxes with 16GB DDR4, 512GB NVMe for €115 each. Bought them as the memory crisis was starting. One is now my home assistant, the other one runs matrix.

I still use an ancient chuwi for going to the makerspace. It's still got hours of battery.

It's all ok stuff if you know what you're doing.

> Lenovo IdeaPad 15.6 inch Business Laptop with Microsoft 365 • 2026 Edition • Intel Core • Wi-Fi 6 • 1.1TB Storage (1TB OneDrive + 128GB SSD) • Windows 11

The person who approved describing its 128GB storage as 1.1TB should be hanged.

The CPU also has[0] 31% of the single core and 14% of the CPU Mark rating. The screen has 220 nits (vs 500) brightness, comes with 4GB of RAM, and weighs 30% more. At least it's half price, though.

The shopping situation for Windows laptops is utterly dire.

[0]https://www.cpubenchmark.net/compare/6268vs4227/Apple-A18-Pr...

Windows 7. Windows 10 eats about 6GB (custom IoT with a lot of things disabled).

Neo is a parody of a computer.

check your install mate

There was simply no need to upgrade, the MacMini was faster in all regards then my Intel MBP. Out of curiosity of its capability I wanted to see how gaming performs - I ended up playing through all three Tomb Raider reboots (Mac native, but using Rosetta!) at 1080p in high settings. Absolutely amazed how fast it was (mostly driven by the update to M2).

Only one thing ever made me notice the lack of RAM, and that was when I was running the entire test suite of our frontend monorepo. This runs concurrently and fires up multiple virtual browser envs (vitest, jest, jsdom) to run the tests in parallel. Stuttering and low responsiveness during the execution, but would complete in 3-4 minutes - it takes around 1 minutes on my current M4 MBP.

https://mac.getutm.app

The gap in spec is no mistake, if it was appealing enough for existing air-book users to downgrade it would cannibalise their bottomline.

The budget tier is UTM. (Also recommend any users of UTM that find it useful should consider donating, preferably through Github sponsors.)

modular USB ports; battery sans glue; trackpad

Twenty years ago, I worked part-time in a laptop repair facility for a large educational institution; this computer would have been a godsend (e.g. the first MacBooks had hundreds of screws, plastic everywhere).

For nightmares, the screwbin either tips over repeatedly, or a dropped screw poofs indefinitely. Sometimes I wake up sweated, snackycaked crumb constellations jambed up'gainst bedsheets and fattie.

Screws, everywhere. Me.

That probably bit them HARD during the butterfly days.

I skipped that entire generation, but the modern silicon keyboards are slick. My workshop computer is a 2012 MacBook "Pro" (disabled GPU), which also has fantastic keys. Best Apple keyboard ever has to be the 12" PowerBook G4, but that may just be nostalgic...

----

My major critique of the Neo is: for its intended market (younger), it should be more durable, not less — why is there no MagSafe power connector?

From a computer repair technician's POV, there will be lot$ of U$B port replacement$, due to power supply abusers (have you seen some students' charging cables?!). From manufacturer's POV: if they had MagSafe, they probably wouldn't need separate USB ports (IMHO).

It's almost guaranteed that the second revision of this product line will use MagSafe (you own the patent already!).

The USB-C port that’s already there anyway is free, thus way cheaper. No special port. No special cable in the box.

I don’t think it will come in the next revision.

There were several generations of Apple laptops that mysteriously didn't have MagSafe — I never bought one — very glad to see its return on my own M3MBAir15".

https://www.youtube.com/watch?v=5k7Lv7f-5CQ

On a rational level it isn't surprising that the "compute" part is so small, given its origins, but for some reason it still caught me by surprised seeing something barely larger than a Raspberry Pi.

But, yeah, this thing is crazy modular. I particularly want to call out how trivial it is to replace the ports, given how common of a failure point they are. With the keyboard/monitor being more involved, but absolutely still approachable.

I believe he finds just a single piece of light adhesive keeping a cable in place, everything else (inc. the battery) is screws only.

I really wish Apple would resurrect that form factor, as every other MacBook since has seemed bulky in comparison. Thanks to OpenCore Legacy Patcher[2], I still haven't gotten a newer mac. With a modern M series chip, it wouldn't have such rough tradeoffs in battery life and performance. I'd definitely buy it.

1. See step 11 on https://www.ifixit.com/Teardown/Retina+MacBook+2015+Teardown...

2. https://github.com/dortania/OpenCore-Legacy-Patcher

I sometimes travel with backpack only (cheap European airlines) and that is a big difference.