The telling part about uselessness of that window is that the most visible difference between StarOffice 5.2 and OpenOffice.org 1.0 was that equivalent of this window was removed. It got reintroduced probably because it makes packaging LibreOffice for macOS easier.
While it may not be essential for experienced users, I think it is very important for beginners.
Imagine you know nothing about LibreOffice, except that it is an office suite. You download the thing, install it and now what? Most people expect to have something called "LibreOffice" that can be launched and does something sensible. That's what the start page is for.
It is also the reason why it is a good spot for a fundraiser. It tells new users that LibreOffice takes donations, but it will not get in the way of experienced users who already know how LibreOffice work as they are likely to skip the start page entirely.
> running identical software on multiple computer systems is the name of the software-architecture game
In the railway signalling industry (which for historically obvious reasons is obsessed with reliability) there even is a pattern of running different software implementing the same specification, written by different team, running on a different RTOS and different CPU architecture.
This is also true of the space shuttle. The failover '5th' processor was running an implementation done by a completely different sandboxed team to hedge against institutional or systemic errors not caught by the first team. So much thought put into these systems.
This, in the context of 'modern vehicle safety standards' still makes me cringe when considering the "safety" put into modern autonomous vehicle systems.
All the magic of Smalltalk is in the development tools that work by means of introspection into the running image, writing source code in text files causes you to lose all that. Add to that the fact that Smalltalk when written as source files is quite verbose.
Smalltalk does have standard text source file format, but that format is best described as human-readable, not human-writable. The format is essentially a sequence of text blocks that represent operations done to the image in order to modify it to a particular state interspersed with "data" (mostly method source code, but the format can store arbitrary stuff as the data blocks).
One exception to this is GNU Smalltalk which is meant to be used with source files and to that end uses its own more sane source file syntax.
i did not say replay was impossible. i said the statement in the article was overly broad, which it is. If it said "a single result could be hard-coded", it would be fine. but it said the function is constant, which it need not be.
But even that need not be true. here is how you could design that dongle to require no persistent state on RX and still not allow simple replay.
There is this kind of webdev-adjacent niche where the model of using documentation (or even intentionally sub-par documentation) as a marketing funnel for consulting and/or "Pro" versions is a thing. These projects are somewhat vocal about vibe coding killing their business models. If these projects really create any meaningful value is another question.
While that is often neat solution, do not do that by simply XORing the numbers with constant. Use a block cipher in ECB mode (If you want the ID to be short then something like NSA's Speck comes handy here as it can be instantiated with 32 or 48 bit block).
And do not even think about using RC4 for that (I've seen that multiple times), because that is completely equivalent to XORing with constant.
Comparing single-purpose declarative language that is not even really turing-complete with all the ugly hacks needed to make DOM/JS reasonably secure does not make any sense.
Exactly what you can abuse in XSLT (without non-standard extensions) in order to do anything security relevant? (DoS by infinite recursion or memory exhaustion does not count, you can do the same in JS...)
> Although XSLT in web browsers has been a known attack surface for some time, there are still plenty of bugs to be found in it, when viewing it through the lens of modern vulnerability discovery techniques. In this presentation, we will talk about how we found multiple vulnerabilities in XSLT implementations across all major web browsers. We will showcase vulnerabilities that remained undiscovered for 20+ years, difficult to fix bug classes with many variants as well as instances of less well-known bug classes that break memory safety in unexpected ways. We will show a working exploit against at least one web browser using these bugs.
They are about libxslt but Mason Freed doesn’t want you to know that. They could contribute a rust project which has already implemented XSLT 1.0 thus matching the browsers. But that would good software engineering and logical.
reply