Beggars belief...
...that the first thing the investigators did wasn't look at the command history.
178 publicly visible posts • joined 29 Jun 2019
But initially Pascal supported neither libraries nor ways of extending the language using inline assembler, so the only way of implementing WriteLn() was by building it into the compiler. The input and output media was fairly well standardised: cards etc. as declared by the control deck wrapped around compilation and execution.
Pascal did get to support include files and other $-prefixed directives fairly early, which were arguably the legacy of Wirth's experience with a Burroughs mainframe at Stanford. That machine did as well hew to the ALGOL-60 standard and ignored the change in the -63 revision, hence my earlier quip that Wirth might simply not have known about it.
I don't know where completely-separate compilation (i.e. not relying on $include files) originated, but I believe that it was supported by the IBM Mainframe that replaced the Burroughs one at Stanford.
In any event the industry owes a substantial debt to Wirth for the type-safe parameters introduced in Modula-2 (but not, I believe, in the original Modula). Even if most language implementers didn't go to that degree of trouble.
Pascal's implementation of Write(), WriteLn() etc. in the core language, without having support for indeterminate types and varying numbers of parameters ("polymorphic" and "variadic" in today's terms), and without support for the : separator Wirth used to indicate the desired formatting, was an utter disaster, since it meant that (a) only a core language developer could maintain those functions and (b) developers of extension modules (classic example: to support complex numbers) could not use the same format.
If you look at it in the context of modern core languages which /do/ have polymorphism, variadic parameter lists (or at least arrays), and possibly decent macro and/or generic capabilities: yes, flexible WriteLn() etc. is very nice to have. But the maintenance problems of that type of design decision were understood in the early 1960s, and after trying it in Pascal Wirth recanted in his later languages.
By all means: find a way of adding arbitrary separators etc. to the core language, provided that it doesn't impact the compiler efficiency. By all means, find a way of generalising variadic and polymorphic parameters. But do so in a way that non-core developers can use in their own compilation units, since that both keeps them happy and reduces your own maintenance burden... and make sure that the compiler still fits in memory.
Regrettably, reliable information on the original Modula is scarce: about all I'm aware of is https://www.research-collection.ethz.ch/entities/publication/f94b0c0c-ac24-4c2c-b88b-31c9a0bd902f which is dated 1976.
Compared with Pascal, it loses its predefined I/O: which was enormously problematic since WriteLn() etc. needed to be defined in the compiler.
It also appears to define that structured parameters were completely opaque across modules: an undeniable improvement in robustness, at the cost of substantial extra code for what we'd now call "getters" and "setters".
Pascal's "dangling else" issue is solved by using the same type of syntax as Modula-2. Wirth never attempted to use- and possibly wasn't aware of- the hack in ALGOL-63.
Compared with Modula-2, it lacks the well-thought-out rules for "compatibility" and "assignment compatibility" which potentially leaves it about as fuzzy as is Pascal.
It does have to be said that some of the problems inherent in available Pascal dialects are arguably the result of ill-considered "improvements" in the Borland and UCSD implementations, for example the way that a loop control variable has no defined (i.e. reliably predictable) value on completion even though it is in scope... unless a break has been used in which case the value is reliable.
But the fact that Wirth was working on successor languages only about five years after releasing Pascal says a great deal. As does the fact that the surviving Pascal community refuses to recognise that even Wirth appeared to regret some of his early design decisions.
We selected PostgreSQL for commercial use in around 2000, since while we were prepared to use something commercial we /really/ didn't want sales calls every month or to find details of what we were doing leaking. After the SOLID Database Server ("with Bonsai Tree Technology(tm)") vanished into IBM the options were fairly sparse: MySQL didn't have adequate support for transactions, and we /really/ didn't want to tell customers to whom we were demonstrating our service that we used something with such a tacky name: most of them still had IBM mainframes.
The version at that time was IIRC 6.5, and while sniffing around the source (which we purchased from the .org on a CD) I found hooks for tertiary storage, i.e. offloading seldom-used data to a tape library or similar. That code- removed shortly afterwards- was written by Sunita Sarawagi, presumably as part of her PhD at Berkeley ("Query Processing in Tertiary Memory Databases") before joining IBM.
...from the film "Jupiter Ascending". https://jupiter-ascending.fandom.com/wiki/Advocate_Bob
Notably at one point he found himself in an antagonistic situation with another android of the same series (with IIRC a different-coloured tie): which is probably a fair comment on current AI.
The situation was eventually resolved by a cameo appearance of Terry Gilliam.
It is of course fair to argue that somebody with really old hardware won't be able to connect it to newer machines which lack an ISA or even parallel PCI bus. However, IIRC it's been demonstrated that you can use something like a Raspberry Pi Pico to bridge a PC's LPC bus to an ISA socket, although I suspect that doing so would be incompatible with bootloader signing etc.
However if somebody really did have good reason to run an older card and if he'd already fixed the bus issue, in the case of network devices he might be able to use a Packet Driver wrapper: /if/ such a thing were still runnable and preferably in user mode.
The alternative would be for NDISWrapper to be resurrected, which I'm sure the kernel maintainers and system managers around the World would /love/.
"But they have a flying product. A product that's been tested and seen by the MoD - and they've got a contract where they have to produce a certain amount within 6 months to get the full payment. And the point about the drone world, at the moment, is that most drones are basically obsolescent within a year - maybe much quicker - so make 'em quick and get 'em used. Then upgrade the design and make more. Until development slows down, you actually want a tech move-fast-and-break-things attitude."
OK, that's encouraging. But I note that the articles says
"We asked the MoD how much this deal is worth. A spokesperson told The Register the contract has yet to be signed, so the information is commercially sensitive, but it is understood to be a multimillion-pound figure that will include integration, technical support, and end user training."
The thing that bothers me however is the "veteran-founded" bit: the CEO is a veteran of Cambridge and MIT and the chairman a veteran politician.
"Veteran", particularly in defence circles and most particularly in the context of our putative ally the USA, has a very distinct meaning. It shouldn't be cheapened.
"71. Capture was an in-house Post Office Ltd accounting system used in some branches between 1992 and 1999.[156] It predated Fujitsu’s Horizon software, which was introduced in 1999.[157] At least 19 versions of the software were deployed during this period, with up to 2,500 “users”.[158] In January 2024, press articles began reporting that, like Horizon, the Capture software was capable of generating false shortfalls, and there were known errors and bugs in the software.[159] In April 2024, DBT commissioned an independent investigation into Capture by forensic accountant auditors, Kroll."
"156 Capture operated as backoffice software, similar to an excel spreadsheet, into which sub-postmasters entered daily cash and stock information. The software aggregated these figures and transferred them onto weekly balance sheets, which sub-postmasters printed and submitted to the Post Office. Kroll, Independent Investigation into Capture Accounting Software, 10 September 2024, p1"
https://committees.parliament.uk/publications/52110/documents/289545/default/
So presumably in this context that means "in-house written", rather than being another ICL monstrosity. However the report goes on to identify the sort of shortfalls etc. that Capture implied, and that around fourteen people had been disciplined.
My first thought there was that with that history, the Post Office etc. should have been a bit more cautious when it came to Horizon; however it turns out that Kroll (the auditors) were only looking at this in 2024.
Now, /El/ /Reg/, couldn't some truncated version of that appeared in the article, rather than just throwing in the name "Capture" without explaining that that specifically affected PO staff rather than being some wider government SNAFU?
In the case of FPC it /was/ Debian's problem: they were rejecting it on the basis that it /can/ use GTK2 and provides a precompiled interface unit, and were apparently ignoring attempted clarification from the package maintainers.
Please note that I am not trying to be an apologist for anybody here, but there are three groups of people involved: the FPC developers, the maintainers of the FPC Debian package, and the core Debian team.
FPC does not /require/ GTK2 (it is not a graphical tool), in the same way that it does not /require/ the USB interface libraries or a slew of database interface libraries even though it has precompiled interfaces for them.
The Lazarus IDE and the Lazarus Class Libraries (LCL)- which obviously are graphical- are distinct from the Free Pascal Compiler, and while the development teams obviously talk to each other they are largely distinct. The fact that the Lazarus team has been slow moving away from GTK2 /is/ their problem, not Debian's.
Debian appears to have no concept of the fact that a development tool can have Separate Compilation (with strong type checking etc.), and assumes that if a package includes a precompiled interface unit then any libraries used by that interface unit are hard prerequisites for the entire package. That's wrong, that needs to be fixed, and that's Debian's problem.
My understanding is that the FPC issue (that it has precompiled units which support the GTK2 developer libraries) and the Lazarus IDE issue (that on Linux its preferred widget set is still GTK2) are distinct.
The FPC issue appears to have been resolved. It wasn't strictly a problem of the FPC project itself, but appears to have been caused by a combination of Debian policy and a (possibly automatic) checking procedure which refused to believe that a development tool which fully-supports separate compilation didn't require the libraries for everything it referenced (i.e. not just GTK2, but standards like libusb where the compiler etc. is entirely happy if the underlying libraries aren't present).
I also believe that the maintainers of the Lazarus IDE for Debian have resolved the matter by having separate support packages for the various widget sets.
It is unlikely that the F-35 has a "kill switch" which could be activated mid-mission. There is however a risk that IFF codes could be manipulated in realtime.
It is unknown whether mission setup has to be cleared by America.
It is likely that the major software updates applied every couple of years have a "not to be flown after" date embedded in them.
It is certain that a Pentagon-ordered interruption to the parts supply chain would brick the aircraft.
Are you absolutely sure? Canada has put a substantial amount of money on the table to cover Lockheed's purchase of long-lead-time components, but I've seen nothing published which says that those parts could not be transferred to some other suc^H^H^H purchaser.
-----8<-----
“Yes, the government is paying a small amount in order to have options,” Carney replied. “That’s useful for our defense and to have options in our negotiations with the Americans.”
Such ‘long-lead’ funding typically refers to advance procurement for components that must be ordered well ahead of final assembly. This step is used to preserve production timing and keep delivery options open.
----->8-----
https://www.aerotime.aero/articles/carney-confirms-canada-payments-14-additional-f-35a
Noting of course that the Gripen- as manufactured by Saab- still uses an American engine and they've said they're not changing that.
However nobody seems to have picked up the fact that Saab's commitment to supply full technical information to Canada would obviously include the details of the engine interfaces, with the Gripen using the Ada programming language with which Bombardier is apparently familiar.
And that Bombardier already uses Rolls Royce engines.
And that the GlobalEye aircraft being offered to Canada as part of the package are based on a Bombardier airframe with Rolls Royce engines.
I don't think that there's been anything definitive yet saying that Canada will buy Gripens, but TBH I'd be surprised if they didn't. And in that context the money that they've just put on the table to allow Lockheed to buy long-leadtime parts for another batch of F-35s does not necessarily mean that those F-35s will be purchased by Canada.
"According to a video published by Lockheed Martin in 2017, the F-35 Lightning II is updated through the Autonomic Logistics Information System (ALIS)."
AIUI the ALIS servers were replaced by ODIN about four years ago.
However it's important to note that this is reportedly just the server at the base, which still needs a Lockheed backend: I note the reports that the UK has a logistics centre at Sealand and don't know the extent to which there is a *single* Lockheed backend and the extent to which this is penetrated by the Pentagon.
AIUI the actual computer which attaches to the F-35 is a Panasonic Toughbook, with an (optical?) FireWire interface implemented as a PCMCIA card.
I agree with Liam FWIW: even if Thunderbird isn't perfect, it provides a useful focal point for developers to collaborate when working out how to talk to commercial services such as Gmail.
Another thing its that its message threading is better-than-half-decent (possibly because of its legacy of being used for Usenet) and its searching facility is similarly fairly good. I mention this in the context of having had to trawl through my Gmail account to find stuff relating to various "legal crap", and I'm well overdue for moving all routine stuff over to a non-Gmail address with local storage.
> The only other mail server it's likely to pass through is the sender's.
Disagree. As policy, we've been sending time-sensitive emails directly for the last 30 years or so to people who pay for our service, and by now we are very much in the minority: most people assume that anything not using one of the big service providers as a "Smart Host" can be blacklisted.
The difference is that when we send mail directly we can find out when something's jammed and /why/. If we used a Smart Host, even one provided by a specialist like AAISP, there would be no way that we could find out what was going on without 'phoning them or waiting for the timeout.
> Medion, not Mediatek (the latter wasn't even mentioned in the article).
>
> Medion is a brand name of computers and electronics products sold across Europe in chain stores like Aldi, Lidl and a number of consumer electronic stores.
>
> Mediatek is a manufacturer of SoCs, some of which use ARM IP.
My apologies to Liam and everybody else for confusing the two.
Mea maxima culpa.
> You surprise me, Mark.
That's been on my resume for 30 years or so :-)
So what relevance does Mediatek have to this article? Are you actually saying "if you want an ARM-based laptop look at this one from Mediatek? Because what you wrote was
"[...]and in a somewhat unusual move, it hinted that the Medion SPRCHRGD 14 was the model it aimed to OEM."
which implied that Tuxedo intended to stay involved with the architecture and form-factor by buying something in.
The fundamental issue is that it should be the fleet operator's responsibility to update firmware etc., and the manufacturer should not have been allowed to retain direct access.
Obviously the operator should be open to the possibility that there are "backdoors", but the fact that the manufacturer is open about having access means that something went very badly wrong in the procurement process.
> Although the late great Niklaus "Bucky" Wirth wasn't directly involved, Ada's syntax – and its strong typing - are visibly inspired by Pascal.
At least some of the ALGOL-68 "Minority Report" authors were involved in the early days.
"The European community was especially responsive, particularly valuable since language research had been more active there than in the United States over the previous decade. ONR London paid several academics (Dijkstra, Hoare, Wirth, ...) to provide inputs, but we got more valuable aid from European industry." -- http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm
In practice it owes more to ALGOL-68 and Modula-2 than to Pascal.
> Compiled language don't do the kind of type conversions that run-time-typed languages do (can't say about Python - its years since I did a few experiments with it). I've actually used both Algol-W and Pascal (long long ago), and neither does that sort of thing.
But (choosing the trivial example) they do promote byte to word and so on, sometimes with very unclear definitions of sign propagation and so on: I was reading the ALGOL-W manual and some of Hoare's contributions a few days ago.
One of the peculiar things about the Pascal community is that the members almost always express the view "everything Wirth did is perfect!" until somebody suggests that some part of the language be upgraded to be compatible with some of his later ideas.
> TRUE, FALSE, UNINITIALIZED, and ERROR
I once worked on a preprocessor for documents to be submitted to Ventura Publisher, and working from memory there were something like seven states of a flag. I really can't remember the details after 35 years or so, but it's very easy to imagine there being separate states for "undefined", "undeclared", "true-but-may-be-overridden" and so on.
I was thinking the other day that it's interesting that some of the earliest "surviving" languages (ALGOL-W and Pascal) plus of course C have type as an attribute of a variable and massage the result of an expression to allow it to be assigned. This automatic type conversion is a real hazard, particularly where assignments are chained.
As I understand it Python v3 does the exact opposite: variables are initially untyped but an expression has a type.
And Wirth's later languages tightened up the assignment and automatic conversion rules a great deal.
It appears to be fashionable for commentators to argue that type-safe languages aren't needed since the majority of recent security vulnerabilities etc. are logic errors rather than simple off-by-one or use-after-free. But that ignores the fact that a high proportion of current software is 20+ years old and that dozens of errors have been weeded out over time: sometimes resulting in real damage to individuals and companies using them.
Strong typing would have prevented many of those errors getting into production code. As such anything that can be done to promote it is a Good Thing, particularly if it has some chance of being applied to legacy code since rewriting it risks introducing more subtle logic errors.
There are so many groundbreaking products that the Mozilla Foundation has "misplaced", that in any reasonable industry the executives would be accused of pilferage.
HTML editor: at least that lives on as Kompozer, and has actually been enhanced over the years to support CSS.
Visual Javascript: vanished without trace, possibly inside Sun.
Various server-side stuff: ditto.
At the very least, they could have been a viable competitor to WordPress. As it is they're a one-trick pony that gets a bit of new bling every time it's pased on to a new management team.
"Multiple other projects also use the vast linked data store that underpins ubiquitous internet encyclopaedia Wikipedia, and some of them are helping the fight for democracy."
So considering that El Reg reports that the US executive has its sights on people who don't agree with it in the Library of Congress and Copyright office, one has to ask: what jurisdiction does the Wikimedia Foundation operate under, and to what extent could the US government^H^H administration^H^H no let's be honest here TRUMP screw it around now that its underlying agenda has been highlighted?
> C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable".
Looking at this in the context of the ALGOL family, the thing is that there's so many different issues. The first one that people think about is using braces rather than begin/end: but in the overall scheme of things that's trivial (potentially just a macro expansion) and is immediately eclipsed by such things as the dangling-else issue (fixed in some ALGOL-derivatives, hacked around in others, ignored in many including C and Pascal).
Then there's things like declaration order: some languages put a type followed by things to be associated with that type, others do it the other way round.
But the elephant in the room is infix notation: C (and most other ALGOL derivatives) embraced that since it was basically a convention that every schoolboy had been familiar with for centuries, LISP (and APL, Forth and Smalltalk) thought they could do better and- I'm tempted to say- arguably harmed the industry and the underlying technology by fragmenting the notation.
Although you and I have argued about this several times, and I've usually pointed out that if a peripheral can't adequately distinguish between parentheses and braces then one should look at its font handling and question whether it really is the best tool for the job.
After all, there's plenty of more serious related issues: 0 vs O, l vs I, l vs 1 and so on: and those comparisons will look different to every one of us depending on browser and OS.
> So am I reading the PDF right, that LISP-2 stalled when they ran out of memory on their development machine?
>
> Shame, that.
Leaving aside the situation at SDS, according to Waychoff John McCarthy was seriously pissed by the fact that Burroughs wouldn't tell him how to circumvent their mainframe memory protection, and as a result replaced Stanford's B5500 with an IBM S/360. And it was years before IBM had working virtual memory, hence the old joke about the letters standing for "I'd Buy Memory"...
No, MNG is something different entirely: as you'd see if you took the trouble to check Wikipedia before posting.
The problem appears to be that MNG is "all singing, all dancing" with relatively large files and a complex decoder as a result. APNG is generally simpler, and has the advantage that a decoder that doesn't understand it as a PNG extension will still display the first frame.
In any event, the belated endorsement of APNG has to be applauded since it will hopefully avoid further duplication of effort.
Most PDAs and featurephones had some sort of pointing device: a four-way rocker or similar, and multiple buttons.
What is really so difficult about the idea that screen areas that /can/ be clicked on should be visually distinct, and should have popup hints telling the user what he is about to do, at least until he is familiar with the UI?
Smartphone screens are- and always have been- capable of far more resolution than early Macs, Windows or GEM systems: and arguably outperform the Xerox workstations on which the WIMP metaphor started off. There's really no excuse for walking away from well-established design principles that allow anybody familiar with one family of systems to quickly adjust to some other.
When Windows started pushing a common user interface in the early '90s there was a lot of hot air asserting that it would "stifle innovation". I was no lover of Microsoft (having dealt with them commercially) but I certainly never promoted that viewpoint, and I think that history demonstrates that a system based on menus and a two- (or possibly three-) button pointing device is vastly superior to one in which every application program requires the operator to memorise an arcane list of key-combinations that grew larger with every release.
I remember a specialist wordprocessor called the Redactron, from a company led by a woman and promoted as freeing women from drudgery. But /boy/: despite having a fancy keyboard the poor girl operating it had to memorise a truly obscene number of shortcuts.
By all means: /allow/ keyboard shortcuts in the design philosophy. By all means, /allow/ fancy context-sensitive areas of the screen (multi-finger zoom etc.). But for people who do not use that particular piece of software dozens of times a day, provide the universally-understood menu system as a fallback.
However, I have to admit at this point that perhaps I am being reactionary, and perhaps I am advocating a "traditional" solution because I am unfamiliar with the design guides published by the various 'phone OS suppliers (Apple, Google) and the people who would like their app to look like it works on a 'phone even if running on the desktop or in a browser.
But I'm still left bothered by the suspicion that most smartphones are used only as terminals to Facebook and Twitter, so really those are the only UIs that the vast majority of users need to be familiar with.
Half the problems start when one or more of the people involved in the debate does so from a position of incomplete information and limited experience. They get worse when they insist that their viewpoint is so important that they are entitled or even obliged to argue from a position of ignorance.
I remember a friend who worked at- IIRC- Red Hat, who started discussing user interfaces with some colleagues and was surprised that none of them had heard of the CUA (Common User Access) guidelines: which had of course been invented by their corporate parent IBM, and for a long time were broadly respected by Microsoft.
Now that obviously was ancient history, and he's observed in the past that many of the currently-active "professionals" are actually younger than Windows '95 and NT which form the foundations of "Windows as we know it". But one would have thought that /somewhere/ there would be a record of hacks that had been found to work and idioms which were universally understood, and that this would be taught.
Which leads us to the demise of the organised WIMP user interface, in favour of the utter mess which- IMO- we have when considering Android etc. Why did it happen: was it simply because nobody recognised that the UI worked and was worth respecting? Was it simply because nobody had managed to /explain/ to the new generation that it worked? Was is because corporates felt that they couldn't attract new blood if they weren't given groundbreaking work to do?
And I wonder how many times this has happened in the past. Mainframes were swept away (until people realised that they needed centralised databases). Minis were swept away (until people realised that they needed some sort of multitasking and interprocess communications). Windows- at least in its classic form- has been swept away, and replaced by "UI de jour" either implemented directly on the screen or in a browser. Script-based unix startup has been swept away and replaced by systemd...
And every damn time, there are people eager to argue the notional advantages of the new system. Whether or not they understand the old one.
> The rule of thumb is that you can expect the printed part to only have 30% of the strength of thesame part in the same plastic, but injection molded.
That rule of thumb needs a further term, even for plastic. "You can expect the printed part to only have 30% of the strength of the same part to the same design in the same plastic, but injection molded."
Using 3D printing you can add strength members to a part in locations and at angles that would be completely unattainable in a (single-part) moulding, and fill relatively-unstressed parts of the body with a structural foam of appropriate (and varying) density.
So in practical terms you might be able to make something which fits into the same volume, but by reconfiguring reinforcing ribs etc. is not only of comparable strength but is also significantly lighter.
Leaving aside the current crap about 3D printers, predatory behaviour from John Deere and the like: this is something that's been brewing for years after the army brought certain facts to the attention of a Congressional committee.
Basically, they'd been put in a position where they were obliged to buy off-the-shelf kit, which invariably had a "return to supplier" repair policy.
The example given at the hearing was that of portable generators failing in IIRC Afghanistan, which the army's own mechanics were entirely capable of repairing but weren't allowed to.
Frankly, I'm surprised it's taken this long to sort itself out.
Definitely worth investigating. You will find a high level of compatibility with the various "standard" Pascal implementations (ISO, Turbo, Delphi and so on), and it's fairly trouble-free particularly on Windows or Linux.
And the Lazarus IDE gives you very good debugging facilities.
There's mailing lists and a forum which is generally helpful, until some retard starts off yes another "Why isn't Pascal more popular when it's better than everything else?" thread.
My position is that it will probably "see me out". But I'm not entirely happy with the bloat that's crept into the language, or- as I've said somewhere above- the documentation situation.
Actually, FPC and Lazarus have supported all Raspberry Pis from v1 onwards, and before that other ARM platforms like the NSLU-2.
They've never supported IBM mainframes and a number of others- notably the Itanic- haven't got very far, but apart from that their platform coverage is comprehensive.
> I need to mention here that the book does not go into Windows programming, OOP, software components, or the Lazarus GUI builder.
More seriously, it explicitly says that it is omitting all consideration of the RTL (FPC standard libraries) and FCL (FPC Class Libraries).
These are, by now, utterly immense, and suffer from patchy documentation (much machine-generated), sparse indexing, and members of the user community who tell newcomers that they should be using some facility that is completely unfindable unless you know where to look.