Posts by abend0c4 788 publicly visible posts • joined 10 Mar 2023
It's a pity English doesn't really have reflexive forms, found in other languages, that substitute for the passive, because:
the Xyzzy driver error handling fixes itself to avoid a NULL pointer dereference
would also deal neatly with the shortage of kernel maintainers.
Having booked for other airlines via an OTA (I don't recommend it if you care if the flight is cancelled/delayed as the interposition of a 3rd party really complicates things, but you can sometimes save some money), the responsibility of the third party stops at selling a ticket and providing a booking reference. You still have to go through the airline check-in procedure and that's the point at which they collect nationality and passport details. Some other airlines at that point allow the passenger to provide alternative contact details so they get notified about late changes to the itinerary rather than relying on the OTA passing on the messages, but they don't do additional verification checks - ie they accommodate OTAs and don't try to frustrate them and their customers.
This seems to be solely a feature of Ryanair and, if other airlines aren't doing the same, their explanation of why it's necessary and proportionate should be quite interesting.
What would actually be considerably more use to me would be for the many mobile operators who currently block it to permit WiFi calling beyond their national borders (and no, VPN + turning on airplane mode is in most cases no longer sufficient). But it's all about revenue, not utility. At least in theory - the reality is that however hard telcos try to push up their revenue the price of their services seems to continue to fall.
It's always difficult to tell what's specifically novel about a patent because they're written in such obscure language and also depend on the cumulative result of a series of claims.
I'm struggling to discern what's here that wasn't part of the IS-IS routing protocol which started life at the end of the last century and was not then considered to be novel technology - except that perhaps it overlays an existing network and there is selective participation. IS-IS used a mechanism of point-to-point neighbour links to distribute a link-state routing database around a network.
I think you'll find that began when the "social" networking algorithms figured out how to incite physical human conflict. Bolshie cars are just a bit of additional softening up.
I think we're safe in the UK until there's sufficiently widespread adoption of the "smart" kettle to permit an all-out assault on teatime.
CPUs these days are not constructed around their instruction set - and these problems seem to have nothing to do with the instruction decoder. The problem is the race for speed which means the transistors keep getting smaller and more functions are closely integrated to shorten signal paths. All that leads to heat and less tolerance for variations in conditions as the chips run closer to the technology boundaries.
I think there's a genuine question as to whether the race is worth the candle. The relatively short time for which many of these chips can run at full speed makes them most suitable for interactive environments where they can respond more promptly to short bursts of activity, but you'd hope your server or bit-barn processors spent most of their time running at full-tilt (or you've wasted some of your investment). There are obviously a whole bunch of external tradeoffs in terms of the physical space required, power consumption, cooling requirements and MTBF - about which I know very little - but I do wonder if we're straying away from the optimal tradeoff in pursuit of marketing headlines.
insta-context switch
In the days when I used to travel a great deal, I found it took a certain amount of time on arrival at the next airport before I could decode the sounds coming out of the tannoy into a recognisable language - and knowing where I was didn't help. Now, when I spend a lot of time in one European country, I find if I've been watching British TV or listening to Radio 4 and then go out, I'm tongue-tied for 5-10 minutes until my brain catches up with the change of context. I knew someone who was a simultaneous translator and seemed perfectly capable of maintaining both contexts at the same time. I guess I've just got a single-threaded brain.
Apart from the potential for data gathering, the primary purpose of landing pages seems to be to get people to agree to terms and conditions. I'm sure that's a huge obstacle to those who wish to flout them. Presumably it's a liability thing, but I can't see they serve a genuinely useful purpose.
The thing is that "COBOL" is usually used as a shorthand to mean COBOL/CICS/IMS or COBOL/CICS/DB2. CICS in an IBM teleprocessing monitor and IMS/DB2 are respectively hierarchical (yes, that ancient) and relational database producs. The "COBOL" is liberally interspersed with embedded CICS (and/or database) commands that are translated by a preprocessor that can either be standalone or integrated into the COBOL compiler. Using CICS also means that most of the traditional COBOL I/O statements are unavailable.
So COBOL as it is usually practised may contain very little actual COBOL.
However the check box is not ticked and it is impossible to tick anyway.
If you have unticked Allow Firefox to send technical and interaction data to Mozilla, the option to Allow web sites to perform privacy-preserving ad measurement is greyed out.
If you haven't, it appears to be on by default.
And it goes back a long way. Back in the 80s, I couldn't believe how bad IBM's software development tools were (even the "online" options were just resource-hungry wrappers around batch compilation and the buffered screens made editing unnecessarily tedious) compared with not just their competition but with industry norms. Their networking was belated and messy and their midrange systems clung to the cardpunch/lineprinter model long after minicomputers had obsoleted it.
What IBM had in its favour was well-engineered and solidly reliable hardware - and ruthless hardware sales teams. The software was always considered an unfortunate necessity to support the hardware sales. These days, IBM seems to believe everything it does is an unfortunate necessity to support its income and appears to be basing its business model on entitlement rather than engineering. Not that it's the only culprit.
The really mindbending part of this is that there are two separate technologies deployed. In the north of England and Scotland it's a wide-area radio network (apparently proprietary) operated by Arqiva. The southern part of the island uses moblile phone technology. Those two contracts are presumably intended to avoid a monopoly supplier, but simply lead to two entirely separate sets of problems in poor signal areas. And of course Capita sits on top of the whole edifice, presumably so the headcount doesn't get added to the civil service.
So, we have a bunch of quasi-monopolistic operations and incompatible implementations largely set up to maintain the fiction that we have functioning competition in the energy supply sector, even though the price cap and various other government regulations mean the supposedly "independent" retailers have little freedom of movement, except to go bust with energy customers forced to pick up the cost.
The French run their smart meters over the powerline network, which isn't perfect (long rural cables, for example), but seems to work more reliably in the general case.
The Victoria Line has been automated since it opened in 1968 (and the technology had been tested on the District Line since 1963) and now many other lines don't technically require a driver for all or part of their operation, so the reasons we still don't have driverless metros in the UK are worth considering.
Basically, we have the technology but lack the infrastructure you need to deploy it successfully. Britain in a nutshell.
There was a concerted effort to ensure standardisation and compatibility that manufacturers these days would decry as unwarranted government interference. That was partly because the lack of spectrum meant that there wasn't really the option of a free-for-all, but by the 50s (in America) and 60s (in Europe) it had such a hold on popular entertainment there'd have been riots if the system had been arbitrarily broken.
There are even still vestiges that linger on in digital TV - the vertical resolution of standard definition video is 480 pixels in the US (the number of visible lines in the NTSC system) and 576 in PAL countries for similar reasons.
There's probably a lesson for today's manufacturers in the marketing advantages of products that are obviously part of a supported ecosystem, but perhaps one they are not predisposed to acknowledge.
But, there again, I thought a bassinet was some sort of low-pitched woodwind instrument, so what do I know?
I think the problem is that the proselytizing for Rust can be rather overblown and even disingenuous.
This particular post is a case in point, starting out by saying how "easy" it is to introduce Rust into your codebase and then going on to suggest that you might have to write a compiler back-end for your target processor, recompile the basic libraries and work around the Rust convention that allocations always succeed - not a normal characteristic of embedded environments. As opposed to, say, just using the supported tools that come with your development board.
Rust's static analysis is clever and comprehensive but I'm not (yet) convinced the complexity it adds (particularly in lifetime annotations) is warranted. In an asynchronous environment, particularly when you have a mixed environment with other languages and/or direct interfaces to hardware, there's a limit to how far static analysis of the Rust portion of the code is going to get you.
There's a good case to be made that C is the programming equivalent of the unguarded circular saw, but that doesn't mean that Rust is the appropriate alternative. There are good ideas in Rust but C is so ubiquitous it's going to need a very different notion of "easy" before Rust makes much of a hole in its deployment. I think you could probably make a great deal more headway with memory safety using a Typescript approach (a more disciplined version of C that compiles to standard C) which could take advantage of the existing toolchains (and, indeed, code) rather than requiring new ones.
Incidentally, even with uBlock turned off, this Google Security Blog post was not visible in Firefox with my default security settings and I had to resort to Chrome to read it...
It may be an encouraging sign for technology suppliers that they get to foist on to their customers more of the ever-increasing cost of remediating the deficiencies in their commercial products, but I'd be more encouraged if the law started tightening up on those "fit for purpose" disclaimers.
I think, in fact, he waged a successful campaign to have kippers restored to the breakfast menu on the Brighton Belle - an all-Pullman service that staggered on until 1972.
Incidentally, the BBC has periodically filmed an accelerated version of the London-Brighton service and has a version with 3 different eras side by side in which the different indicator technologies can be clearly seen near the start.
I have a certain amount of sympathy for both sides in this case.
Adding more lines of code implies more maintenance and it's already hard to find maintainers - needing specific skills from an even smaller set of potential candidates isn't going to help.
Equally, we've probably all been in situations where NIH-syndrome has led to foot-dragging.
However, the real problem is seems to me is that the scope, benefits and timeline of Rust for Linux are ill-defined. Indeed, they don't appear to be mentioned anywhere on the project website. It seems mostly focused at present on providing the infrastructure for writing device-drivers in Rust, but acknowledges that deprecation of duplicate drivers in Linux means there are unlikely to be Rust replacements for current drivers. The highly hardware-dependent nature of drivers makes them a good place to shake down the mechanisms by which you'd run Rust code in the kernel, but so much of the memory management is done by the Linux driver framework that you would imagine the gains from Rust's memory safety might be fairly modest - and in any case have to await hypothetical future drivers for devices for which no driver currently exists. I don't see any roadmap for introducing Rust into other parts of the kernel, or any analysis of where the benefits might most be felt.
Of course, there is also the problem that transformational change in a project like Linux is very hard to achieve - it's mature, its stability is critical and it proceeds mostly by discrete incremental changes to is myriad components. You have to start with what you have - and that includes the people as well as the code - and juggle the various competing requirements.
In open source, the solution to a particular problem also depends on the interests of the people working on it. In this case, the only people working seriously on memory safety in the kernel seem to be Rust developers. I can't help feeling it would be a very different conversation if a group were considering adding Rust-like features to a version of C that could over time be incorporated into the existing code.
Like politics, it's the art of the possible and that means not only having a solution but persuading other people to adopt it.
I think I've mentioned before that one of the problems with automatically translating video subtitles is that language is only part of the context of the communication. How you translate "copy that", for example, depends on whether the speaker is currently holding a radio or a sheet of paper. Effective communication depends on the entirety of the shared experience.
I've no doubt the enthusiasm to adopt AI will expose all sorts of limitations that perhaps should be foreseeable but will be brushed aside for as long as possible. However, what will be most fascinating are the "unknown unknowns" which may also emerge.
Should I be surprised that it worked?
In general, yes - unless you're absolutely sure of the provenance of the bits and pieces there's a good chance that either some critical bit is missing or that something is simply broken. Having said that, he chose to start from a fairly promising point. Unlike the earliest PDP-11s, whose CPUs were made from multiple cards with their own backplane, the KDF11-B in this 11/23+ is a single QBUS card containing DEC's second microprocessor implementation of the CPU and so has a lot less to possibly go wrong. And having two memory cards increases the chances that at least one will work.
The QBone is probably cheating a bit, but I/O devices are typically large/rare/mechanical so acquiring them working can be a significant challenge and expense.
there's nothing about AI that requires it to search private channels
The core feature of "Large Language Models" is their being "Large" - they depend on having ingested vast screeds of data. The problem is that, to get enough data, they need data that at least some people would prefer them not to have: either because they own the copyright or because they'd imagined it to be private. Having ingested that data, it's always going to be a challenge to prevent it emerging.
Processors used proper 5.0v supplies
The PDP-8, for example, had supplies of +10V and -15V (and logic levels of -3V and 0V) - and core memory is primarily current-driven rather than voltage-driven. Early NMOS microprocessor designs like the 8080 required +12V and -5V as well as +5V. The 6800 only had one external 5V rail but generated the additional voltages internally, The 6502 (1975) used depletion-load NMOS and was entirely a 5V part. I think Intel Pentiums went from 5V to 3.3V around 1994/5, so that constrains your childhood to 1985 +/- 10 years.
it will just run and run
Unfortunately, we also have the other development paradigm in which code is continuously delivered and hence, presumably, needs continuous reconfiguration. But where the cost of the eternal development and deployment resources are mysteriously absent from the financial calculations.
... are, as it happens, what Moxie Marlinspike was reported here of bemoaning recently.
I get the distinct impression that in the search for "flexibility" we're simply piling Pelion on Ossa and risk reaching the point at which the minimum resources needed for some "scalable" applications aren't that much different from the peak resources required if they were (literally) left to their own devices. Alibaba claim their approach reduces CPU load on the application servers by up to 70% - that's a mind-boggling waste of resources in the status quo ante.
This is the second report here of a SIGCOMM paper detailing the use of eBPF filters to allegedly improve network performance and I can't help feeling it's a glaring symptom of a problem rather than a solution to it. Apart from the layers of complexity (and the need to manage them), I'm instinctively wary of applications protocols messing around with the routing layer they're using to communicate with each other: it's always been a challenge to keep even simple routing algorithms stable in the case of frequent topology changes and, even setting aside the added potential for bugs in the screeds of extra code, any failure to understand the subtle interaction between the various layers is a potential source of new instability.
Of course, part of the increased efficiency simply comes from moving the functionality outside of the compute nodes and into the network infrastructure - where it still has to be paid for, but the claim is that the network infrastructure is already doing most of the required work already and most of it was being duplicated unnecessarily.
The real question is, of course, how did we get into this situation? How, in the pursuit of resource efficiency, have we come to solutions that are apparently so resource-hungry and so impenetrable - but no-one really noticed? Marlinspike, perhaps rightly, points the finger at the "ballooned" ranks of the large engineering organizations, but this bloat is not just a red flag for performance, but for security too.
But can’t they build mini nuclear plants rather than using gas?
I'm fascinated that this response comes before What a pity LLMs appear to be economically unsustainable. If mini nuclear plants were genuinely viable, should we not be using them instead of gas for our present energy consumption? Seems like everyone is being blinded by the reflection of dollar signs in other people's eyes.
DEC built far too many things. You could have a PDP-8, a PDP-10, a PDP-11, a PDP-20 or a VAX and an almost infinite catalogue of different operating systems. And the performance differences in the various model ranges were often imperceptible because competing teams were allowed to develop similar products which marketing were left struggling to differentiate. None of it really mattered when the only competition was from mainframes, but when the microprocessor came along they were effectively doomed because they didn't have the economies of scale to sustain silicon development for their proprietary market and were entirely the wrong, ponderous, research-heavy sort of organisation to produce cutthroat commodity hardware in volume.
It's not just about having engineers or book-keepers in charge, it's about having the right people in charge for the realities of the market at the time. Or, at least, not having the wrong people.
To be fair, the Agile Manifesto doesn't say much about anything, except in the vaguest of terms.
It's as difficult to blame it for any specific failures as it is to credit it with any particular success.
The biggest difficulty with it, in my view, is that it's the work of software developers, putting themselves front and centre. I think what Marlinspike might be getting at is that software developers are not necessarily the founts of wisdom they may believe and it can be difficult to challenge them when they're seen as the linchpin. Also, perhaps, the typical Agile approach is to start with coding and then refine it later: that doesn't really encourage thought and understanding of the problem before you start - or indeed later, provided the code appears to "work".
It's not just about being able to design your own processor, but also about being able to change your CPU supplier without having to make significant changes to your software. Though if you look at the myriad different features that may be present in different models of ARM, Intel and AMD processors - and their various physical form factors - that might not be as easy as it sounds.
There's nothing, as far as I'm aware, that would prevent the big players from introducing RISC-V chips (and having microcoded processors would be a head start), but designing working silicon is quite hard - especially if you also want bleeding-edge performance - and the profit comes from the proprietary knowledge behind it. So, I'd be very surprised to see performant RISC-V processors free of any kind of IP encumberances, at least in so far as their implementation on the wafer is concerned. There may be a niche for cheap "open" designs to be added as control planes to other devices (there's already a version of the ESP-32 WiFi module with a RISC-V core, for example) where there's added value.
Open source software may be able (for now) to depend on contributors moonlighting from their day jobs, but fabs have high fixed costs and in the end they'll only make what's profitable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
