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"
    }

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.

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

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.

The Neo is getting a lot of praise because it's all modular and screwed together. That should make it very easy to repair and also for Apple to do iterative upgrades, but that makes it bigger and heavier and size/weight does matter to people. Hence this thread.

If you're using OpenCore Patcher, it's important to install the root patches to enable graphics acceleration. Otherwise it'll be ridiculously slow.

her review: “this thing is HUGE :( :P ”

The M1 Max I replaced it with was the opposite. I don't think I heard the fans for the first month. But it was much larger.

Based on the fanless Air, I strongly suspect an M1 Max in the old chassis would have been totally fine for non synthetic workloads and an M1 Pro would probably have been fine in all scenarios.

But I think they over corrected on the chassis design when they were shipping borderline faulty products and haven't walked it back yet.

I'm a dev and the MBP line is definitely overkill for me. The 15" MBA handles everything I can throw at it.

Kind of hard to see that as "HUGE" in comparison. Bigger? Yes, but not really huge.

Doesn't need to be super fast or fancy, just extend the life of device a little more.

Soldered internal storage and ram is fine if I can store my non-essentials in a cheap drive. Or my essentials in a way that is recoverable if device fails. iCloud helps for photos and families, but it's still far too slow if you don't live near it.

I think "generated comments" is a pretty hard line in the sand, but "AI-edited" is anything but clear-cut.

PS - I think the idea behind these policies is positive and needed. I'm simply clarifying where it begins and ends.

All this stuff is in flux. I thought a lot about whether to add the "edited" bit - but it may change. What I deliberately left out was anything about the articles and projects that get submitted here. There's a lot of turbulence in that area too, but we don't yet have clarity, or even an inkling, of how to settle that one.

Edit: what I mean is this: while most of those submissions aren't very interesting, some really are. Here's an example from earlier today:

Show HN: Vanilla JavaScript refinery simulator built to explain job to my kids - https://news.ycombinator.com/item?id=47338091

How do we close the aperture for the lame stuff while opening wider for the good stuff? That is far from clear.

If you're going to say that the AI said X, Y, Z, provide a rationale on why it is relevant. If you merely found X, Y and Z compelling, feel free to talk about it without mentioning AI.

> If you merely found X, Y and Z compelling, feel free to talk about it without mentioning AI.

I think you're seeing this as too black-and-white, and missing the heart of the issue.

The purpose of mentioning AI is to convey the level of (un)certainty as accurately as possible. The most accurate way to do that would often be to mention any use of AI, rather than hiding it.

If AI tells me that it believes X is true because of links A and B that it cites, and I find those links compelling, then I absolutely want to mention that AI gave me those links because I have no clue whether the model had any reason to bias itself toward those sources, or whether alternate links may have existed that stated otherwise.

Whereas if a normal web search just gives links that mention terms from my query, then I get a chance to see the other links too, and I end up being the one who actually compare the contents of the different pages and figure out which one is most convincing.

Depending on various factors, such as the nature of the question and the level of background knowledge I have on the topic myself, one of these can provide a more useful response than the other -- but only if I convey the uncertainty around it accurately.

In my experience, LLMs hallucinate citations like crazy. Over 50% of the times I've checked, the citation either didn't exist, or it did but didn't support the LLM's assertions.

This is true not just from the chat, but for Google AI summaries.

When the references are more often wrong than not, you can understand why many will simply downvote you for bringing LLM citations into the conversation. Why quote a habitual liar?

(If you look at my other comments, I'm actually in favor of using LLMs in some capacity for HN comments. Just not in this case.)

> In my experience, LLMs hallucinate citations like crazy. Over 50% of the times I've checked, the citation either didn't exist, or it did but didn't support the LLM's assertions.

Note that those are specifically not the cases where the AI is citing "sources that I feel appear plausible."

(I also don't find over 50% hallucination to be accurate for Google AI summaries in my experience, but that depends on your queries, and in any case, I digress...)

> When the references are more often wrong than not, you can understand why many will simply downvote you for bringing LLM citations into the conversation. Why quote a habitual liar?

To be clear, I do understand both sides of the argument, and I don't think either side is unreasonable. I've also had the experience of being on both sides of this myself, and I don't think there's a clear-cut answer. I'm just hoping to get clarity on what the new policy is as far as this goes. I'm sure it'll be reevaluated either way as time goes on.

I should point out that I'm not saying 50% of the AI summaries have an error. Merely that the references it provides me don't state what the summary is claiming. The summary may still be accurate, while the references incorrect.

However, that's probably not critical enough to formally add to the explicit guidelines, so it's probably fine to leave it in the "case law" realm—especially because downvoters tend to go after such comments.

The comments thing is a lot more intimate in the sense that anyone posting comments is inside the house.

I have a kid with severe written language issues, and the utilisation of speech to text with a LLM-powered edit has unlocked a whole world that was previously inaccessible.

I would hate to see a culture that discourages AI assistance.

> I would hate to see a culture that discourages AI assistance.

Mostly I think the push back is about ai assistance in its current form. It can get in the way of communicating rather than assisting. The cost though is mostly borne by the readers and those not using the AI for assistance. I have seen this happen when the ai adds info and thoughts that were tangental to the original author and I think, but I can not verify times where an author seems to try to dig down on the details but seemingly can not.

These rules are always fuzzy and there's always a long tail of exceptions. All the more so under turbulent conditions like right now. I wrote more about this elsewhere in the thread, in case it's useful: https://news.ycombinator.com/item?id=47342616.

https://news.ycombinator.com/item?id=47326351

Yes, please at least have a carveout for accessibility. I definitely have dictated HN comments in the past, and my flow uses LLMs to clean it up. It works, and is awesome when you're in pain.

It's better to communicate as an individual, warts and all, than to replace your expression with a sanitized one just because it seems "better." Language is an incredibly nuanced thing, it's best for people's own thoughts to come through exactly as they have written them.

So yeah, it can change the character of your writing, even if it's just relatively subtle nudges here or there.

edit: we suggested that he disable that feature to help him learn to write independently, and he happily agreed.

1. A system that suggests words, the child learns the word, determines whether it matches their intent, and proceeds if they like the result.

2. A system that suggests words, and the child almost-blindly accepts them to get the task over with ASAP.

The end-results may look the same for any single short document, but in the long run... Well, I fear #2 is going to be way more common.

The phenomenon was observed in religious philosophy over a millennium ago (https://terebess.hu/zen/qingyuan.html).

Now that it is, I just turn tab completion off totally when I write code by hand. It's almost never right.

I have mixed feeling about it. On the one hand, you're right: carefully considering suggestions can be a learning opportunity. On the other hand, approval is easier than generation, and I suspect that without flexing the "come up with it from scratch" muscle frequently, that his mind won't develop as much.

A "click to see more about why this answer fits" crossword, on the other hand...

    Shoal, Hasty, Lobby, Vogue, Gunky, 
    Sheep, Theft, Linen, Slime, Fluke, 
    Hydra, Dizzy, Lance, Shred, Buyer, 
    Attic, Guava, Awake, Stank, Hoist,
    Mogul, Squad, Roost, Skull, Bloom,
    Mooch, Surge, Vegan, Scene, Cello,

If I had to guess at a riskier 20%... Guava, a fruit some people may not have had; Gunky because it's slang; Mogul, Vogue, and Mooch were borrowed from other languages; Cello is something people may have heard more than read; Hoist.

That's a good point and could very well be true. I just know I've played plenty of games where I was mad that they didn't show the meaning. So let's say its 5% for native speakers, and up to 20% for non-native speakers - that's still a golden opportunity to expand vocabularies. And honestly it can't be a lot of work to add a couple lines of static text. At worst it would be ignored, and at most, help people learn more interesting words.

A certain amount of friction is necessary, at least if the goal is to help the person learn or make something original.

As an adult, I do too. As a middle schooler, we absolutely used word processors’ thesaurus features to add big words to our essays because the teachers liked them.

Anyway before that she HATED the thesaurus. And she could tell when students were using it to make their writing more fancy pants.

I had two teachers who called us out on this, and actually coached us on our writing, and I remember them fondly. (They were also fans of in-class essaying.)

The others wanted to count big words.

It is definitely not true that it is better for a poster to communicate like an individual when it comes to spelling and grammar. People ignore posts that have poor grammar or spelling mistakes, and communications that have poor grammar are seen as unprofessional. Even I do it at a semi-subconscious level. The more difficult or the more amount of attention someone has to pay to understand your post, the less people will be willing to put in that effort to do so.

[It looks like MS Word 97 had the ability to detect passive voice as well, so we're talking 30 year old technology there that predates LLMs -- how far down the Butlerian Jihad are we going with this?]

There is no need for that here beyond maybe spellcheck. Use your own thoughts, voice, and words.

> HN is for conversation between humans.

If it is enhancing that instead of detracting and wasting peoples time it does not seem to be against the spirt of the rules.

That is from dang's post in: https://news.ycombinator.com/item?id=47342616

That whole post is clarifying for the intent of the new rule(s).

"Don't post generated comments or AI-edited comments."

What about non-native speakers? Can they not use translation software like google translate any more?

"Don't post generated comments or AI-edited comments, except for translating to english"

What about cases of disabilities?

"Don't post generated comments or AI-edited comments, except for translating to english and when used as assistive technologies."

Some translation tools and assistive technologies are still going to case the same issues that we have right now so maybe limit the technologies used

"Don't post generated comments or AI-edited comments, except for translating to english and when used as assistive technologies. Technologies x, y, z are not allowed a and b and similar can be used for translation c and d as assistive technologies"

But we do not want to spend time/effort on filtering technologies and/or people into the above categories.

In the long run we likely will come up with technologies that most everyone is satisfied with using in different use cases, spelling grammar, assistive, maybe even tone, and others.