suspended_state

https://en.wikipedia.org/wiki/Brontosaurus#:~:text=For%20dec...

So, who is correct?

How do you compare a system where the communication channel goes only one way in a single country to a system where everyone potentially contributes to the content and is distributed over the world?

How does one country legislate the content of a company based in another country?

Do you think that censorship is a better solution?

Some sense of perspective: https://news.ycombinator.com/item?id=46273466

So you were criticizing the C language syntax, without considering the context which it was designed in.

Just to give this context a little bit more substance, Pascal was designed to work on a mainframe which could address up to 4MB of RAM, with a typical setup of around 1MB (it's actually not the real amounts: the CDC-6600 the values are 128Kwords, but it had 60 bits word). These machine were beasts designed for scientific computation.

The first C compiler was implemented on a PDP-11, which could handle up to 64KB of RAM, and had 16bits words.

I assume that these constraints had a heavy influence on how each language was designed and implemented.

Note that I wasn't aware of all these details before writing this comment, I had to check.

See: http://pascal.hansotten.com/niklaus-wirth/zurich-pascal-comp...

Regarding the C compiler, it is likely that the first version was written in assembly language, which was later "translated" to C.

An early version of the compiler can be found there: https://github.com/theunafraid/first_c_compiler and does look like assembly hand converted to (early) C.

I don't really know what you mean by "worst-designed syntax". Do you mean that the design process was bad, or that the result is bad?

I'm not sure I understand this article, but the argument you present seems to be that when considering P and NP as relational objects, they don't have the same signature, thus cannot be compared, so the statement "P = NP" is meaningless?

You should probably have linked the whole work which is briefly referenced at the end of the article, and isn't yet indexed by search engines. I found it by myself:

https://zenodo.org/records/18107880

The linking stage could perhaps be performed at process launch by a privileged task?

See this comment thread: https://news.ycombinator.com/item?id=46494183

Isn't a virtual ISA like an intermediate representation? It doesn't have to include static addresses, only symbolic references, which could be resolved at launch time.

What I meant, and indeed it was poorly explained, is that an address shouldn't be just an integer freely manipulable by any instruction. The microcode will obviously know how to an manipulate an address, but the ISA as a whole doesn't have to, and in fact shouldn't, with the exception of a few specific instructions. What I am advocating is that addresses should constitute a separate type, which isn't a simple alias to integers. I think that this is what capabilities are about.

Code has to have addresses for calls and branches.

Does it mean that at that level an address has to be an offset in a linear address space?

If you have hardware powerful enough to make addresses abstract, couldn't also provide the operations to manipulate them abstractly?

But that address doesn't have to be visible at the ISA level.

There are channels in place to discuss security matters in open source. I am by no mean an expert nor very interested in that topic, but just searching a bit led me to

https://oss-security.openwall.org/wiki/mailing-lists

The good guys are certainly monitoring these channels already.

Indeed nobody does that, because it would just be pointless, it doesn't expose the real issue. Is a security vulnerability a symptom, or the real issue though? Doesn't it depends on the purpose of the code containing the bug?

Are memory leak fixes described as memory leak fixes in the logs or intentionally omitted as such? Are kernel panics or hangs not described in the commit logs even if they only happen in weird scenarios?

I don't know nor follow kernel development well enough to answer these questions. My point was just a general reflection, and admittedly a reformulation of Linus's argument, which I think is genuinely valid.

If you allow me, one could frame this differently though: is the memory leak the symptom or the problem?

If it is faulty, then it's not a bug, it's a flaw.

The problem with that argument is that the reports don’t necessarily come from the organization for whom it’s an issue.

You can already say that for the majority of the bugs being fixed, and I think that's one of the points: tagging certain bugs as exploitable make it seem like the others aren't. More generally, someone's minor issue might be a major one for someone else, and not just in security. It could be anything the user cares about, data, hardware, energy, time.

Perhaps the real problem is that security is just a view on the bigger picture. Security is important, I'm not saying the opposite, but if it's only an aspect of development, why focus on it in the development logs? Shouldn't it be instead discussed on its own, in separate documents, mailing lists, etc by those who are primarily concerned by it?

It's difficult to really know what was the intent without seeing the actual prompt of the painter.

Comment [intentionally] designed to look like generative AI.

https://copilot.microsoft.com/shares/W9krzb8CuhT5zRE5hZzjE

Papermaking, printing, gunpowder, compass, porcelain, paper money, abacus, iron plow, wheelbarrow.

I stumbled on this:

https://lobste.rs/s/qoqfwz/inverse_parentheses#c_n5z77w

which should provide the answer.

I think ungrouping make sense if you consider reverse parentheses as a syntactic construct added to the language, and not replacing the existing parentheses.

For instance, using "] e [" as the notation for reverse parentheses around expression e, the second line showing reverse parenthese simplification, third line showing the grouping after parsing, and the fourth line using postfix notation:

A + B * (C + D) * (E + F)

=> A + B * (C + D) * (E + F)

=> (A + (B * (C + D) * (E + F)))

=> A B C D + E F + * * +

A + ] B * (C + D) [ * (E + F)

=> A + B * C + D * (E + F)

=> ((A + (B * C)) + (D * (E + F)))

=> A B C * + D E F * + +

So what ungrouping would mean is to undo the grouping done by regular parentheses.

However, this is not what is proposed later in the article.

Possibilities include reversing the priority inside the reverse parentheses, or lowering the priority wrt the rest of the expression.

Shouldn't there be an argument for best effort? If the issue has been removed as soon as it has been detected, doesn't it count for something?

You're correct.

Sure, I guess you can understand what I said that way, but that's not what I meant. I wasn't thinking about the implementation, but the specifications.

Read again the quote I was refering to if you need better context to understand my comment.

If you have good formal specifications, you should be able to produce the corresponding code. Any error in that phase should be considered a bug, and yes, a typo should fit that category, if it makes the code deviate from the specs.

But an error in the step of translating the requirements (usually explained in natural language) to specifications (usually described formally) isn't a bug, it's a translation error.

got a surprisingly good result

the output wasn't even recognizably Danish

How would you know that it's good then?

Careful, HN isn't your average IRC channel.

A formally verified program can still have bugs, because the spec (which requires specialized skills to read and understand) may not satisfy the intent of the requirements in some way.

That's not a bug, that's a misunderstanding, or at least an error of translation from natural language to formal language.

Edit:

I agree that one can categorize incorrect program behavior as a bug (apparently there's such a thing as "behavioral bug"), but to me it seems to be a misnomer.

I also agree that it's difficult to tell that to a customer when their expectations aren't met.

I think it does indeed make a lot of sense in the particular example given.

But what if we add 2 extra nodes: n5 dependent on n2 alone, and n6 dependent on n3 alone? Should we keep n2 and n3 separate and split n4, or should we merge n2 and n3 and keep n4, or should we keep the topology as it is?

The same sort of problem arises in a class inheritance graph: it would make sense to merge classes n2 and n3 if n4 is the only class inheriting from it, but if you add more nodes, then the simplification might not be possible anymore.

Your comment is funny, but please note: it's not drawing a pelican riding a bike, it's describing in SVG a pelican riding a bike. Your candidate would at least displays some knowledge of the SVG specs.

I don't know what GP meant, but I can give an example of how I understand it (disregarding the spurious "the" in his comment): in a type system with sub-typing, your expression could be statically typed to return a certain type, and at runtime return any of its sub-types.

For instance, in typescript you could ascribe an expression with the type Any, yet the actual runtime type will not be Any, it will be any concrete type.

In object oriented languages, you may define a hierarchy of classes, say with "Car" and "Truck" being sub-classes of "Vehicle", each having a concrete implementation, and have an expression returning either a "Car" or a "Truck", or maybe even a "Vehicle". This expression will be statically typed as returning a "Vehicle", yet the dynamic type of the returned value will not necessary be (exactly) that.