Posts by MarkMLl

Why the end of Optane is bad news for all IT

Yes, /but/...

This is something that Liam and I have been sparring over for the last ten years or so.

The first thing I'd say is that on Linux- in fact I'd hazard any modern unix- everything /isn't/ a file: network interfaces aren't files, sockets aren't files, USB devices aren't files... and even in the case where some device or OS interface /does/ exist as a name in the filespace it very often needs a specialist API which controls it via IOCTLs.

Second, if we do magically decide that we can do without secondary storage and have everything inside the application program(s) like a 1980s home computer or like a PDA how do we organise it and ensure that it will scale?

I can sympathise with Liam's uneasiness at the idea of having data which isn't immediately accessible to the CPU. However, what is the alternative? There really does have to be some sort of organisation even for something which has a single-level addressspace, and if we assume that the leading contenders are environments like Lisp or Smalltalk we have to ask: how is internal data organised, and in particular how is any form of security implemented?

The original Smalltalk books (Goldberg et al.) casually remarked on cases where system owners were free to change low-level details. However the early non-PARC implementors were quick to point out that such things made systems virtually unmanageable since there was absolutely no way that a program (some species of object bundle) could make any assumptions about what already existed on the system.

To the best of my knowledge, there is no persistent single-level environment where every object has an owner and well-defined access rights. Hence there is no way of saying "this stuff belongs to the user and can be read by nobody else", "this stuff belongs to the underlying environment system and can only be updated by its maintainers", and "this stuff is the intellectual property of some middleware bundle released as open-source, and if modified it can no longer be passed off as The Real Thing".

As such, I have reluctantly decided that the idea of file-less flat systems is a non-starter.

CHERI-based computer runs KDE for the first time

Re: A way to go!

> I agree with Tony Hoare.

"Many years later we asked our customers whether they wished us to provide an option to switch off [bounds] checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

The bottom line is that by ignoring most of the available hardware protection capabilities in an attempt to make software appear to run slightly faster, Microsoft et al. have left their systems vulnerable to any amount of bugs and malware. Even ignoring the cost of theft and extortion, the time wasted scanning for potential problems and fixing any that get through is vastly greater than the time they were able to save.

Re: Capabilities you say?

> You mean like the Manchester MU5 of the late sixties?

...which shipped in '74, some fifteen years after Burroughs started working on their descriptor-based architecture which was released commercially in I think '63.

I admit to being slightly dubious about the ultimate provenance of that architecture. The tag that indicated whether a word in memory was data or a descriptor might have been a side-effect of designing hardware to run ALGOL, which later turned out to have broader applicability.

Tavis Ormandy ports WordPerfect for UNIX to Linux

OK, but just what /is/ this?

Well, I remember people running WordPerfect multiuser on CCP/M-86.

But just what are we looking at here? Is this a fairly straighforward compilation of available sources, or is there some sort of shim involved in the same way that Linux used to offer shims to support the APIs of some of the established unix flavours? And how's the UI handled: curses/termcap or something more esoteric?

Confirmation that a modern Linux distro remains compatible with legacy software is at least as big news as the availability of Lotus or Wp for a current OS.

Google calculates Pi to 100 trillion digits

If that were the case, then somewhere embedded in the digits of pi are the digits of pi... a statement which is either trivial (if we allow the perfect overlap) or paradoxical.

Export bans prompt Russia to use Chinese x86 CPU replacement

Who cares?

The bottom line is that you don't need a supercomputer to read propaganda.

And it doesn't matter whether that propaganda comes from Vlad the Insane or Elon the Erratic.

Debian faces firmware furore from FOSS freedom fighters

Jenny List, writing at https://hackaday.com/2021/01/29/why-blobs-are-important-and-why-you-should-care/ , suggests that many controller ASIC contain bought-in IP which might include firmware provided under NDA, the source of which quite simply can't be made public.

As others have said, this is hardly a new problem. In addition, Debian does have various binary firmware collections in the "non-free" area of its main repository.

The real problem is when installation requires non-free firmware... and the target system has no supported removable medium from which it may be loaded (not to mention the virtually-undocumented naming conventions etc.). Or even (and I've seen this on SPARC systems... anybody remember SPARC?) when the installation CD contained a blob for the SCSI controller which it didn't actually install.

The wild world of non-C operating systems

Re: REALTIME, baby.

Yes, and the first computer implementation of APL was by Breed with Wirth as academic supervisor.

Re: Jupiter ACE

Related code was used in boot ROMS from IBM and Apple at various times. It went on to be used on the One Laptop Per Child machines and never lived it down.

Re: Modula 2

I agree. Basically, Pascal was a rush job designed in between April when Wirth threw his toys out of the pram and resigned from the ALGOL-68 committee and the intake of new graduates in the Autumn.

But it made too much of a splash, and Wirth was never able to really popularise the "done right" version that was Modula-2.

What is not generally known is that Borland had an 8-bit Modula-2 that they decided not to sell themselves but licensed to IIRC Echelon (Ciarcia's company). However they didn't license the documentation, which meant that it was essentially unsellable.

The 16-bit implementation became TopSpeed, published by JPI and later Clarion.

Re: Modula 2

Yes, but if you look at Post-Wirth Pascal you'll find that just about everything that's been added is basically Modula-2 syntax, e.g. the try-finally-END and try-except-END blocks.

Re: Modula 2

However there's little reason to assume that an OS written in Prolog would actually /reason/ about what needed to be done to e.g. service an interrupt, rather than using an imperative extension to the language intended for systems programming.

Re: What about Assembly Language?

No, but Kildall had APL experience from his time at Washington https://www.cs.washington.edu/tr/1970/09/UW-CSE-70-09-04.PDF

He also had Burroughs mainframe experience, so he was well aware of the feasibility of writing an OS in a high-level language.

Re: Apollo OS

I believe that Cray also used Pascal-based OSes. However I'd caution that it's likely that the implementation language was a long way from (standard) ISO Pascal or (de-facto standard) Turbo Pascal, in the same way that Burroughs' implementation language for the MCP (ESPOL) was distinct from the ALGOLs that they used for application programming.

BeOS rebuild / Haiku has a new feature / that runs Windows apps

"relatively modern programming language"

Noting Torvalds' public fulminations regarding C++ http://harmful.cat-v.org/software/c++/linus I'm not sure it's prudent to describe Haiku as being written in a relatively modern programming language.

I would certainly agree that using a language which offers decent type checking and modularisation is better than using assembler or K&R C. But let's face it, just about /everything/ has learnt those lessons from Wirth over the last 50 years, and adopting a toolset that offers too much in the way of prepackaged objects can contribute to code which is both enormously bloated and incredibly difficult to maintain when something goes wrong in a layer which the developers normally take for granted.

And the Turing Award for best compilation goes to... Jeffrey Ullman and Alfred Aho

Re: Vastly wide of the mark

Yes, that's a good point and one I was thinking about. But I still think that the gushing way in which Aho and Ullman are described by various people quoted in the article, which omits the crucial words "contributed by documenting" etc. isn't really appropriate.

Re: Vastly wide of the mark

Oh I agree: they definitely deserve recognition for collating and documenting the field. But they definitely didn't originate it.

Vastly wide of the mark

I don't know who advises the ACM grandees on this sort of thing, but the charitable assumption is that he was working from home and the wrong side of the paywall that protects the ACM archives from plebs like us.

Everybody agrees that Aho (, Sethi) and Ullman wrote and maintained a comprehensive book describing compiler writing. But crediting them with major contributions to the field?

What about Irons (recursive ascent), Grau and Waychoff (recursive descent), Knuth (who famously wrote a mainframe ALGOL compiler over his Summer vacation), and Wirth (an undeniable "doer" and influential on just about every major language)? What about Schorre (compiler-compilers) and Richards in the UK (BCPL?) What about Hoare and Dijkstra, who laid much groundwork even if not significant compiler authors in their own right? Hell, what about Alan Kay (Smalltalk)?

Crediting Aho and Ullman as substantial contributors of original work is vastly wide of the mark, and smacks of the current tendency to lionise "media personalities" and to listen to those who make the most noise.

Arecibo Observatory brings forward 'controlled demolition' plans by collapsing all by itself

Re: FAKE NOOS!!! (recanted and concluded)

I think this wraps it up conclusively:

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

The USA will probably put more resources into investigating the collapse than they did into preventing it.

Re: FAKE NOOS!!! (recanted and concluded)

Thanks for the more recent photos which I think just about wrap this up. I'd comment that Google Maps shows a cluster of (maintenance?) buildings in the area from which that the original Twitter photo was almost certainly taken, so presumably somebody got out quickly to take a photo or there might have been a camera set up taking timelapse shots.

Finally, I think we could all do with remembering the island and people of Puerto Rico, which is much more than just a convenient foundation for the USA's astronomical facilities.

Re: FAKE NOOS!!!

I'm no longer confident in my conclusion. The tops of the pylons might show signs of fracture, and there might be debris trails in plausible locations.

FAKE NOOS!!!

That's been "photoshopped". If you look carefully the cables have completely vanished, and the towers in the "after" shot have fewer tiers than in the "before" one.

Genuine photo at https://astronomy.stackexchange.com/q/38585/7982

Which just goes to show that one shouldn't take stuff on Twitter at face value.

Worn-out NAND flash blamed for Tesla vehicle gremlins, such as rearview cam failures and silenced audio alerts

Old news

This has been knocking around for a year, see https://hackaday.com/2019/10/17/worn-out-emmc-chips-are-crippling-older-teslas/

ALGOL 60 at 60: The greatest computer language you've never used and grandaddy of the programming family tree

Re: Algol 68 is not ALGOL 60

The problem with ALGOL-68 was that when Wirth's ALGOL-W was rejected he threw his toys out of the pram and resigned from the committee. If he'd stayed but voted against the proposed standard than it's likely that a majority of the committee would have followed his lead... it was basically Wirth+Hoare vs van Wijngaarden and a number of his students whom he'd coopted.

And what exactly McCarthy was doing there is unclear, since he'd already abandoned ALGOL for Lisp.

MarkMLl

Britain has no idea how close it came to ATMs flooding the streets with free money thanks to some crap code, 1970s style

Re: Not the only Burroughs ATM story

There was something odd with the magstripe on those early dispensers: Burroughs used some sort of "pepperpot encoding" which I suspect relied more on obscurity than cryptographic rigour.

The TC500 was an interesting brute. A mechanical golfball driven by steel tapes (to circumvent IBMs patent which used steel wires), and a small disc for main memory to circumvent GOK how many patents on using a drum (in particular, I suspect, the LGP-30 which was a similar serial-logic machine).

And software was typically loaded into it using paper tape made out of recycled bog roll. Which was also used for diagnostic software, which more often than not would tear or jam with a customer breathing down your neck.

There are already Chinese components in your pocket – so why fret about 5G gear?

Re: Standards?

The bottom line is that we should be asking ourselves: if we can't make it, should we be using it?

International telecoms and cross-manufacturer operability were long ensured by CCITT standards, and I'm pretty sure that they weren't beholden to FRAND agreements. If some technique is so obtuse that somebody can claim that it's protectable by patent then it's probably not the sort of thing that we want in an international standard, even if it would appear to be desirable to keep the teenagers happy.

And while 99% of 5G will probably be teenage chatter and porn, it's the 1% which is business and emergency services that really matters.

MarkMLl

MarkMLl

One-time Brexit Secretary David Davis demands Mike Lynch's extradition to US be halted

Re: There's no imbalance in the treaty

More to the point, my recollection is that one Boris Johnson argued passionately against the "unequal treaties" we have with the USA during the very brief time allowed in Parliament to debate the 2003 agreement.

MarkMLl

In the red corner, Big Red, and in the blue corner... the rest of the tech industry

A header file might be more than just an API description

I'm entirely OK with the idea that a header file is a factual description of a library (etc.) which is otherwise opaque. The function names are a statement of fact, the types- in conjunction with documented compiler behaviour- are a statement of fact, and the order and type of parameters are a statement of fact. The names of function parameters are not necessarily a statement of fact, but can be changed without altering the API.

What I'm rather less OK with is when a header file contains macros, which are themselves functional and as such are not a simple statement of fact. In my opinion complex macros have no place in published header files, since they blur the distinction between the purely factual definition and the implementation detail.

MarkMLl

Re: Protocols. not APIs

... and a protocol is defined by the specification in one or more RFCs, without which it would be opaque. A header file is to a binary library as an RFC is to a binary protocol.

MarkMLl

Clutching at its Perl 6, developer community ponders language name with less baggage

Re: Why exactly is Perl any worse than Python?

> For decades now we've had people needing to program as part of their day job and they simply don't have the education or aptitude to be able to use something like C correctly. But that doesn't mean that they can't write perfectly reasonable code in something else that internally relies on C.

It also doesn't mean that their preference for Python or Javascript should carry as much weight as the opinion of somebody who through long experience and study knows what he's doing.

Re: Why exactly is Perl any worse than Python?

> What do the inexperienced programmers code in to become experienced programmers?

Anything that's available, but not on live projects.

That might be the reason that so many large projects these days run into enormous problems: industry and government isn't prepared to support an infrastructure of dummy runs and experiments most of which are expected to fail, so instead of cutting their teeth on- for example- a moderate-sized program which is one of many running on a bank's mainframe novice programmers are expected to be effective members of a team writing a comprehensive integrated system: and if their collective inexperience breaks it there's no fallback position.

Re: Why exactly is Perl any worse than Python?

> Yes. But for the practical purposes of this discussion (?), the vast majority of Perl use cases is pattern matching and substitution.

I'd suggest that that's unfair, and I'd point out that most of the substantial corpus of add-ons in CPAN can't be invoked directly from a search which implies that most developers recognise that Perl- once it had started to move away from its AWK heritage- was something more general.

It certainly has exemplary pattern-handling capabilities for something spawned in the 1990s. So exemplary in fact that most languages developed since are at least as comprehensive in that area.

> > Python's major problem is the significance of tabs and indentation [ ... ]

> That. We tried this once with Make. Everyone hated, and still hates, it. But no, Python had to do it again, because once is not enough. And it has nothing to do with helping code readability.

Actually, we tried it with FORTRAN which required that ordinary statements started in col 7. And in ALGOL and COBOL which might have been more relaxed about start column but in most early implementations still reserved a chunk of each input record for a line number.

"Some [preferred] the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause." -- Rob Pike https://talks.golang.org/2012/splash.article

And finally, for another 2d worth, I'd add that Dijkstra's comment about "coding bums" AIUI echoed John McCarthy's words and sentiment which were originally inspired by a certain type of student who obsessed about shaving an instruction or so off a sequence of operations in the same way that a downhill "ski bum" obsessed about shaving a second off his run.

I'm quite sure that you can write impenetrable code in any language, and would suggest that if a language comes along that prevents you from turning a hard-to-understand algorithm into a difficult-to-follow instruction sequence that there's probably some severe downsides to it. But while I'd certainly agree that some of the things in Perl give sloppy workers much more rope than they deserve, I think that the real problem is managerial: most fields of applied science /require/ adequate documentation and review, and the complexity and pervasiveness of computer software makes that requirement even more important.

Ultimately, saying "this code works even though nobody really understands it" is neither an excuse to allow the situation to continue, nor adequate justification to rip it out and redo from scratch. And selecting Python or Javascript for the sole reason that they're popular with inexperienced users is asking for trouble.

Re: Why exactly is Perl any worse than Python?

AWK is fundamentally different, in that it was designed to match patterns and insert replacements rather than to perform sequential operations with its own robust flow control. Virtually every "shop" had something like that which it used to do things like systematic modification of source files before they were compiled/assembled: I used something called Stage2 (W.M.Waite) for that sort of job.

And irrespective of whether it really was the first, by the time Perl reached v4 it offered a vast improvement when compared with the alternatives. /Much/ more significant than that offered by Python when compared with Perl etc.

Perl's major problem, leaving aside the perennial tendency of twits to advertise their superiority by writing impenetrable one-liners, was the sigil prefixes. Python's major problem is the significance of tabs and indentation, which can make it virtually unusable as a component of some larger system which emits code fragments. Quite frankly, the World deserves something better.

Beware the developer with time on his hands and dreams of Disney

Re: Printers were another prime target

132 little electromagnet assemblies, each delivering enough impulse to a hammer to bang the paper and ribbon onto the right character of the rotating drum and then get out of the way /fast/. Printing long sequences of the same character in the same column was particularly cruel- particularly when you allow that Burroughs at that time wasn't exactly renowned for its R&D expenditure and the printer electronics was basically 1960s technology.

Even worse was the "comb" of magnets interleaved with the hammers. This was inherently fragile and was inclined towards "rapid unscheduled disassembly": I'm sure I've got a few bits in a gash box since in their day they were quite usefully strong.

Don't get me going on Burroughs's power supplies, which typically had lots of transistors in parallel which were inclined to "unzip" releasing things into the atmosphere that today would be considered Very Bad News Indeed.

Re: File under "abuse of resources"

The Burroughs TD830 (certainly the "J" variant) was based on a 6800 and similarly allowed a binary to be loaded: somebody used the ISO2047 (?) character set- the one with lightning bolts etc.- for a game of Space Invaders.

Allowing that this was decades before code-signing, encryption on the leased line back to the mainframe and so on the security implications are horrendous.

Delphi RAD tool (remember that?) gets support for Linux desktop apps – again

Re: "It is the security aspect that would worry me though."

"...easier to debug": that is of course an interesting point, since neither Delphi nor Lazarus/FPC are entirely happy when debugging an app split out into DLLs on account of the large amount of memory management (strings passed as parameters etc.) behind the scenes.

Re: "many developers such as myself who are not writing off-the-shelf apps "

I think it's worth commenting that early versions of Turbo Pascal- you remember, with the "treat this like a book" licence- not only installed on multiple operating systems (CP/M-80, CP/M-86, MS-DOS) but could also be customised for different keyboard and screen types. Now that is obviously far removed from the pixel-perfect positioning and prettification that is de rigeur in current desktop application programs, but the unavoidable conclusion is that somebody took their eye off the ball and screwed up badly.

And my understanding is that the person at the helm when Borland decided that it was better off concentrating on large corporates and didn't need goodwill from small users later resurfaced handling developer relations for IBM's OS/2.

Re: A good indication of the market ...

Doesn't seem to stop corporates buying Oracle products, which AIUI are regularly presented to senior management over the heads of their technical staff.

Pascal is a bit of a pariah as far as languages go, but I tend to justify its use- where suitable- by pointing out that as implemented in Delphi (and in Lazarus, with the Free Pascal Compiler as its code generator) it is basically the final expression of what were known in the 80s and 90s as "4GLs"- in fact one might even call it the last one.

Lazarus does have the advantage that it is distributed as source and can fairly easily be rebuilt if an up-to-date binary for a particular platform is unavailable, which is particularly useful with CPUs which have multiple subarchitectures such as ARM. It also gives it a fair chance of "just working" on a platform which the core developers can't easily test, for example in the past I've relied on the fact that FPC can generate SPARC code and Lazarus supports Solaris (for x86-64) to build it without too much of a problem for Solaris on SPARC.

While FPC's support for multiple CPUs and OSes is superb, the one unfortunate thing is that Lazarus can't support alternative languages. Having something as mature and flexible as the Lazarus IDE working with a decent C++ backend would be an unbeatable combination.

MarkMLl