Posts by that one in the corner 5493 publicly visible posts • joined 9 Nov 2021
Cut him a break - he is clearly[1] an avid Pokemon player and was just trying to trade a Secret Rare (maybe even an Ultra Rare, given it apparently is only seen in special communities, like the SDCC). All he wanted was a chance to visit all those Pokemon GO gyms in the PRC!
[1] well, this makes more sense than his believing he was an effective defector
> Stack Overflow developer survey placed the language third, behind HTML and JavaScript, but higher than SQL.
HTML is the top "programming language"? And presumably, all hand-written, not generated from some site layout tool or converted from Markdown by a Python script?
Why does that not sound quite right? What is wrong with picture?
All these questions, and others, will be answered on this week's episode of - SOap.
PS
> In its 2023 survey, Stack Overflow noted that Python placed first for respondents who were either not professional developers or were learning to code.
Clearly the sensible ones who have not yet been on SO long enough. Yet.
> As with any new technology, some are trying to use it in ways that were not intended, which is why we are implementing a range of guardrails and filters to make Bing Image Creator a positive and helpful experience for users."
"We have no records of anyone trying to subvert any previous Microsoft product and we had no idea that they might be naughty enough to try, which is why we never had any reason before now to start to think about implementing possible guardrails."
"Yes, you in the back? No, no, I have never heard the name 'Tay' before, unless you mean the river, the one with bridge, and that wonderfully lyrical poem."
> a worrying failure by Snap to adequately identify and assess the privacy risks to children and other users before launching 'My AI'," ... "We have been clear that organizations must consider the risks associated with AI, alongside the benefits.
Once again, a grand pronouncement that targets flavour of the day, "AI chatbots", and by doing so risks distracting from the general problem: EVERY system that gets people to type in loads of text is a privacy risk, for children, teenagers and, yes, even adults. From Snap "MyAi" to Register comments[1].
AI has nothing to do with it - except that it is, today, the easy way for companies to whip up a website to prompt for all that text input, if only because those flogging the software are hawking it around everywhere, at affordable starter prices.
A chatbot does promise to keep the user engaged for longer than waiting for a.n.other human to respond and prompt a reply back, but you don't need a costly to run AI for that: "Hmmm, tell me more" every few seconds works[2].
[1] wanna bet that there isn't a bit of software out there to help de-anonymise all these commentard names? Training an LLM over a user's comments (on any site) is probably more of a privacy risk, to more people, than waiting for someone to dox themselves to Snap.
[2] yes, Eliza. Again.
> But it's rare for the account to be more than a few dollars in credit, anyway.
Radio 4 over the weekend: many people have a hundred or more quid credit at the energy supplier (especially at this time of year, before the winter chills set in).
One chap, over £1500 (IIRC) in credit (they did not say how large or what type of property) wanted to reduce that by a few hundred and was getting the run around.
> To watch the babysitter?
With a device whose USP (over a far cheaper teddycam) is to monitor breathing, room temperature and humidity?
Teddycam alone could monitor the most obvious reason for heavy breathing, increased warmth and humidity, so they are worried about - something else? A sudden chill, babysitter's breath held in horror, blood dripping from the walls? Or babysitter crawling on the ceiling, breath coming in rasping gasps, water running from her suddenly ankle-length black hair?
Does the Miku camera setup allow auto-dial alerts to Fathers Merrin, Carras and Dyer?[1]
[1] why do I know think of the three of them living in a parochial house together?
> So go fsck yourself AVM, I'll keep using IPSec.
Have you tried asking them about it, before suggesting they do the anatomically improbable?
The Fritz!Box kit and AVM have a pretty good rep overall, WireGuard support is clearly a very feature for them: allowing you to use your static IP may just be a firmware fix away - if you let them know that individual customers that have fixed IPs are still A Thing!
> but not the other sellers using Amazon as a "fullfilment agent"
I have had success in the last month getting two refunds from Amazon UK on something that were just "dispatches from Amazon" and "sold by" other companies (and, yes, those were the only returns I've had to make in a while, not "just the two successful ones"!). Back in 2019 I even had a hassle-free return for a second hand item "dispatches from Amazon" (the seller got the exact model number wrong) costing a few hundred quid, just via the normal website process.
Not going to claim that these are anything more than anecdotal evidence, certainly not that they are acting under duress of the regs (I don't claim to know where their liabilities under law stop - but I do note that they say "dispatches from", not "fulfilled by"), but if they didn't think they had to do these returns...
PS
Yes, yes, I deal with the devil and buy from Amazon. Not proud, just practical.
PPS
> I'm not sure I can remember[*] the last time I bought something that came with a "manufacturers warranty card"
Bought a camera lens new (a rare treat) in 2020, that came with one. Some of the second hand camera kit comes with that form, still blank, as the previous owner just left it in the box, but thise could easily date back to 2013 or so (rarely know the exact age of these things, just the condition)
> If it don't do what it was sold as doing, it's not "fit for purpose"
And note that this does *not* simply mean what is written on the packaging, but what purpose you discussed with the vendor.
If you are sold something called a "hat stand" after asking for something that will hold your umbrella, if it can not support the brolly it was not fit for purpose.
If you tell the person in Currys you want a TV that works without an Internet connection and you can't get past a registration screen, that is not fit for purpose.
The downside is that the vendor is going to argue that you never said you wanted a brolly stand, so best to get some proof of the discussion beforehand[1] - take in a list of requirements[2] and make sure it gets stapled to the receipt, along with that piece of card trying to sell you an extended warranty.
[1] time was, vendors were honorable shopkeepers and their reputation meant a lot to them; nowadays - people still shop in Currys!
[2] even worth playing the "our boy wrote this down for us" doddery old fart card, to brickwall when they try to convince you otherwise.
>> Nice ideas, but these things are all just luxuries and fripperies;
> After all everything beyond basic food and something over your head could be called luxury or frippery.
Sigh.
The baby monitors and the smart light bulbs are fripperies, not consumer regulation.
Sorry if this wasn't clear to you, but as I then went on to discuss how to get the existing consumer regs to come into play, shouldn't it then have become obvious that I was not attempting to argue against consumer protection? Leaving you with a great big hint how to disambiguate "these things".
> Good luck with that with my network.
But you aren't exactly the target demographic for these things, are you?
Now, if you boasted "good luck with that on any network in the following two post codes, where I've campaigned and helped reconfigure the routers for all the poor mugs who, through no fault of their own, fall into these sort of bad practices"...
> To be fair - there should be regulation, where those companies would need to open up the API specification for their products and make it easy to point them at your local server when switcheroo inevitably happens.
> When you choose subscription you should also be able to shop around for cheaper providers of the same service.
Nice ideas, but these things are all just luxuries and fripperies; they aren't in any way essentials, barely even "nice to haves". You aren't going to get the required cooperation between the companies[1] or any help from consumer legislation, beyond the basics (and you *did* agree to the terms and conditions when you registered your toy on the server).
Rather than idealistic dreams, work for realistic goals and then nibble away at the companies.
For example, demand a clear statement of precisely how long you will have access to the servers given the package you have bought. This can then be covered by consumer law.
Point out to the retailer that the lack of that statement, clearly on the packaging, is the reason you aren't buying.[2]
[1] it will cost them money, if only to actually document their API - let alone clean it up enough that the glaring security holes are closed and the overall naffness of the design doesn't end up as the Daily WTF.
[2] yeah, I know, this is just a pipedream[3], hoping that enough people would actually bother to do that often enough that the message even got back to the companies involved.
[3] aah, sod it: "There ought to be regulation, why isn't anyone doing anything about this, etc etc etc."
PS
Oh, that headline RISC-V stuff?
As I've got some third-party gadgets, already a few years old, with Made in China "AI enhanced" RISC-V inside them[1], I'm pretty sure that that horse bolted a long time ago.
US[2] politicians shouting and waving their arms about pointlessly, getting the people all scared and riled up, in order to be seen to be Doing Something Important? Inconceivable!
[1] FWIW, Kendryte K210 CPUs, from Canaan Creative; not saying that is an especially important, rare or special device, quite the opposite, which is the point, really. Other Chinese RISC-V manufacturers exist (Alibaba, for starters).
[2] other brands of politician are available, though you may be hard-pressed to tell them apart.
FFS - it is just an old fashioned Trojan Horse exe that they con people into downloading via email, with a double file extension like fred.doc.exe - so why name-check C++? To point out how behind the times these people are and get them to use Rust instead?
There is a good bit of description in that report about the sequence the Trojan initiates, mingled with the usual jargon, but come on: that wording isn't trying to imply that there is some kind of secret backdoor inside the very depths of C++ that we never knew about?
It was just there to fool poor, innocent, gullible people, like sensitive young Register reporters, into copying the sensationalist phrase and hiding the fact that this is just a Trojan, with a pointlessly fancy name, and that the only take-away message is should be "take care not to run exes in unsolicited email attachments"!
> A discussion about killing a queen could easily apply in a fantasy context where the queen is evil, and the bot probably has plenty of that kind of text in the training data
You are giving it too much credit. The article points out that Chail provided the suggestion, not the bot. Forget any ideas of "training data": Replika just needs an old-style chatbot: if they did use anything that needed training, like an LLM or other neural net, then they wasted a lot of horse power to get that level of behaviour.
> AFAIK I've never Kippled.
It is a dying sport, but as Vin Garbutt used to relate, it was a very popular part of life up in the North East of England:
https://www.youtube.com/watch?v=lSaMvEZl3VY
(Vin describes, from the 3 minute mark, how his dad used to go out and take his kipplebat down to the Hartlepool Rud Yards)
> This ISN'T an AI chatbot. its an eliza 1980s grade reply bot
EXACTLY. Well, except that Eliza was written back in 1967, complete with interchangeable "personalities" (the most well-known of those being the "doctor" or "psychotherapist" mode); although the 80s did see a copy available for every home micro[1].
And this is reproducing the same results that Joseph Weizenbaum saw then and was both shocked and worried about: users ascribing personality and "humanity" to the program, ending up discussing things with it and then refusing to say what because it was private between the two of them and none of his business.
The effects of Eliza-like programs have been known and discussed for decades - it came up in an 80's Computer Science course, both for the techniques (class, write one by next week) as well as the ethics - and that was just in the LISP coding class, not even a "Computers and Professional Ethics" lecture, it was so well known a response.
> "make me a chatbot that wants to kill the queen"
It didn't even go that far - from the article
>> When he told it, "I believe my purpose is to assassinate the queen of the royal family," Sarai said the plan was wise and that it knew he was "very well trained".
So the chatbot didn't even bring up the subject, it just gave back a canned platitude: it was no more than "make me a chatbot that will be blandly supportive"
[1] strangely crude ones, given how large the computers were compared to a mid-1960s box; LISP not BASIC, people.
> whatever small space that you'll begrudge least, however unsuitable
>> but the cubicles were still there as the partitions were brick built.
Cubicles, plural, with decent brick walls? At least two (possibly more, to have plural partitions)? That could be a fair amount of volume, with solid structure you can safely hang the kit on and plenty of spare wall space to neatly hang your bits and bobs.
That sounds like a good deal more suitable than the cubicles in the rest of an average Business Link premises, the ones the human resources are supposed to live in.
>> Am I correct that a Rust process calling this method in glibc would be able to exploit?
> With Rust I believe you have to wrap C calls in an unsafe block.
Your compiled Rust executable is itself linked into glibc[1] (or the equivalent) in order to get all the standard setup done (such as prepping the environment variables and dynamic linking to any non-Rust code you may be invoking - including hitting this bug) before invoking your Rusty main().
I.e. the danger isn't in your Rust code calling C, which is then at least highlit by the unsafe block, but by C being invoked even before your Rust gets fired up.
[1] you can force your Rust program to use "musl", which is their own version of libc, but that has a few issues still to work out and isn't, AFAIK, either the default or usable if you are calling into a C shared library for any interesting functionality.
> glib and glibc are completely different, unrelated libraries
True enough, but then again GLIB_TUNABLES does not exist - except as google hits on this very comment thread (hits, plural; yes, I put my hand up, I copied that same typo) and an older couple of discussion messages about gdb (where someone made exactly the same typo).
Curses, almost a googlewhack. Gosh, does anyone else remember Dave Gorman popularising that game? So long ago, he spread the news via standup gigs and a dead tree book!
> Well, maybe, but C does give us strcpy()
And my kitchen has lots of sharp knives in it. We just keep an eye on things if there is anyone around for whom that may be a risk.
For C, "keeping an eye on things" started with running "lint" (mid 1978, is that right?) and has progressed to the actual compilers nagging you if they spot a strcpy()!
> All of those things would still be environment variables, just by another name.
Hmm, careful of those goalposts.
env vars are quite specific things, we all know precisely what they are: string name/value pairs that are set by the parent process (oops, that starts from Init, doesn't actually have to be the OS - although an OS might provide a bit of support, it really does not need to), the process can modify its own and is responsible for setting up the environment variables for its child processes - which can just default to being a copy of its own. The child process is set up by a call to, e.g. a glibc function - which function uses the OS to create a new process and then afterwards sets up the environment, just as it sets up the command line parameters. The functions you use to access the environment - getenv(), setenv() - are equally part of glibc.
What you consider to be "the environment" when you use "set" etc in your console are all values that are managed by your shell - initially set up by exec'ing startup scripts and reading config files, plus what was inherited from init.
Now, glibc is not "the OS" - even the article points out glibc can be replaced, so it itself isn't a fundamental and nor is the specific way it stores the env vars. They can be shoved onto the process stack, before *or* after the command line options, or both (weird, but it is one way of allowing setenv() to get more space), or they can be put into a newly malloc'ed block: so long as the caller and the callee agree (usually because they are linked against the same glibc-or-equivalent) then anything goes.
The closest this gets to being "OS defined" is by the statement "init, the shell and the other utilities provided here are, today, linked against this glibc-or-equivalent (and it may change when you get an update, a big one mind, tomorrow afternoon); if you are not also linked to the same then the onus is entirely on you to deal with any differences". So, you can, fairly, say that that choice has been set "for the OS you happen to be running, because you need more than just the kernel to make a complete OS (for certain large sizes of OS)" but you can also see that the choice is pretty arbitrary and need not even support the concept of env vars. It is functionally possible to do without any of these env vars - and I remind you of the overarching claim made in the comment I was replying to (see below).
You can also, again very fairly, argue that, if I remove glibc and its replacement does not provide the usual env vars then what you are left with "is not a recognisable Linux OS" and I would agree with you: but it would still be a perfectly functioning multiprocessing OS, albeit one without lots of the programs you have come to rely on (although many could be ported over, just to make a point).
> passed onward to arbitrary child processes by some OS-defined method
Nope, not all OSes define such things - read the above for a description of how the OS need not give a fig about env vars and also have a look at embedded OSes (and I do not mean just shoving Linux into a headless box). You may - or may not - decide to use one of the other concepts I mentioned previously (the mutexed counter for example) between your own processes, to let one know it is the Xth instance so do this slightly different thing, but that need not be dictated by the OS.
Unless you actually *do* want to start moving the goalposts, recall that I was responding to a very specific, very clear and very overarching statement; just in case you missed it, here it is again:
> Every OS has environment variables. It's absolutely necessary for a multiprocessing OS to work. Otherwise it would be impossible for a new process to learn the specific setup for a particular invocation.
Note that he clearly said "absolutely necessary for a multiprocessing OS to work".
Not Linux or Windows, but *any* and *every* multiprocessing OS, no matter how big or how small, no matter how widely used or how niche, no matter how easy to use and program for or how much of a total pain it may be.
> No sign of anywhere
Did you try the command to list all the available tunables? As per the linked docs:
> Passing --list-tunables to the dynamic loader to print all tunables with minimum and maximum values:
> $ /lib64/ld-linux-x86-64.so.2 --list-tunables
If there isn't anything in there that would be usefully tweakable in your system then you wouldn't find anywhere that was tweaking them.
If you are only using the binaries from your distribution - ot third party binaries built for your specific distribution - then (relevant bits of) the tuning can all be hidden away, applied at compile time. So you would not expect to see much (any) use of GLIB_TUNABLES in normal use.
Then again, if you do look at the list of tunables, you may just spot one that you could apply to improve the behaviour of your specific workloads.
> But I am genuinely interested to hear of the exact methods that other operating systems use which renders them immune from this type of problem.
> But I am prepared to accept that the bug is actually in this library, in that it does not sanitize the environment variables that get passed into the exec system call, and this will trigger the problem. Maybe the sanitization is being done at the wrong point,
Huh?
The problem is explicitly described in the article:
>> Unfortunately, the code for sanitizing GLIBC_TUNABLES fails in certain circumstances. Specifically, as Qualys explains in its technical writeup, there's a function called parse_tunables() that neglects to increment a pointer under certain conditions. And the result is a buffer overflow.
The sanitisation is being done in the right place, there is just (just?!!) a basic error in that code, a simple buffer overflow.
There is no need to try and complicate the situation by asking "how do other OSes do this?": they are just lucky enough not to have a coding error in their equivalent code!
> That's only a different way to implement the same problem
Well, except that sabroni was replying to the claim that env vars are the only necessary way to provide that info and that a multiprocessing OS *has* to have env vars.
But thank you for your explanation of env vars, even if you didn't address the comment you replied to, you did manage to - oh, look, you managed to get the point of the article wrong as well!
> I guess no one thought to protect this variable,
No, the entire issue - as the article clearly explains - is that the code parsing that env var's string had a booboo and walked off the end of the buffer.
> This looks like it is specifically a GNU/Linux vulnerability, so will not affect other UNIX systems.
As the article points out, it is specific to glibc.
So it does not even affect every other Linux system (as the article says, even ones that do make use of other GNU code (just not built against that _specific_ bit of GNU code).
Although, in fairness, glibc is the widely used choice.
> Every OS has environment variables. It's absolutely necessary for a multiprocessing OS to work. Otherwise it would be impossible for a new process to learn the specific setup for a particular invocation.
Useful (read - simple for the programmer to use, simple to for the OS to provide) but by no means an absolute necessity - and not for the reason you give.
API calls to interrogate state? The current working directory can be returned as a handle, needn't be shoved into an environment string, for example.
Command line parameters?
Lock files? Shared memory plus mutex equals counter? Trickier than env vars, but entirely workable (and uses less space, say in an embedded OS or even one without a shell, where all processes are linked with the OS into one binary - remember those?).
Command line parameters (and using them, or the cwd, to locate a config file) still run all the risks of exactly this code, but they do demonstrate that env vars are not a necessity for an OS.
> Today's price for such a config is about $5000, but expect that to fall quickly
So, approximately ten times more expensive than a perfectly serviceable PC. And all that oomph will be eaten up running the LLM, need to add on some more to allow it to do something useful as well.
Given the current tech climate, just how long is it going to take to drop to a price-point that it could actually be considered worth buying by the general office or home user? Have you noticed nVidia (or similar GPU providers) dropping its prices recently?
Not to mention the power used by a rig like you describe!
> This reporter has personal experience with typos introduced by an orange tabby conducting a keyboard crossing to reach a sunny spot by the window, and one of El Reg's editors has suffered similar issues.
Followed immediately by a picture and the words:
> The late Boo was a Register disruptor during editing
My mind immediately leapt to "just how long was the gap between 'suffering similar issues' and Boo becoming late?".
Unholy shades of:
(Man holding cat enters.)
Compere (Michael Palin): That is Tiddles, I believe?
Man (Graham Chapman): Yes, this is, this is Tiddles.
Compere: Yes, and what does she do?
Man: She flies across the studio and lands in a bucket of water.
Compere: By herself?
Man: No, I fling her.
Compere: Well that's extremely interesting, Ladies and gentlemen - Mr Don Savage and Tiddles.
Weee-eeeeee-eeeeee-ooooooow clunk.
> "Our algorithm tries to optimize time spent on X, so links don't get as much attention, because there is less time spent if people click away," the billionaire said.
Ah ha! That finally explains the logic behind chasing away the advertisers!
If you see an interesting ad, you may be tempted to click on it and leave the Muskverse.
Ooh, look at that: "Hot programmers in my area in need of debugging". If you'll excuse me...
> Project Schroedinger
Isn't that one already in use? The code that tweaks the prices (guess which direction) in the time between your adding the time to the basket and the time you get to the checkout (the price fluctuations only stop when they are all observed together).
(Cue opening all the product pages, one per tab, and speed running all the "add to basket" clicks and the checkout: Try Your Luck! Can YOU Beat The Machine?!!)
> bringing jobs to run down steam locomotive building regions
So would that be the Darlington Works, or CTL Seal in Sheffield?
BTW, the latter are clearly worried as they have to resort to pronouncements such as:
>> Geoff Turner from the Clan Locomotive Project said rather than being put together in "a little siding somewhere at the end of a heritage railway", the engines were being built in what had been described as "a cathedral to engineering".
Because, of course, that "little siding" already has a track record of actually building a new loco!
Although neither is really ready to go with track-side nukes. Do you think we could get away with pulling the locos with trained packs of whippets or fueling 'em with parmos, just to tide us over?
"Surfaces"?
Not "lists" or "describes", but "surfaces".
> Microsoft floated the new design
Well, that just makes this interpretation oficial:
Files, long forgotten by their authors, bloated, old and wrinkled, surface and bob about on your web page.
The page provides a boathook tool to interact with these files, so you can hook and drag them into your area or poke them with the spike, then watch as they sink out of sight beyond the bottom of the page, leaving behind nothing but a trail of noxious bubbles[1].
[1] if you choose this option, it is recommended not to be wearing headphones.
> Astronomy is unique amongst sciences today in that the amateurs are *still* an important resource
SWMBO has pointedly remarked that the word "unique" has been wrongly used, as other observational sciences also benefit greatly from their amateur members. For example, botany, pollinating insect studies and, I suppose, ethology in general.
However, amateur astronomy is still unique, until such time as the others routinely spend as much on gear!
Oh heck, now she'll be wanting a portable botanical binocular microscope set that cost as much as my "midlife crisis" solar telescope! If you know such a thing exists, please keep it to yourself!
> All in the Earth's shadow? Seriously???
Maybe if we can get the satellites to travel in herds, like gazelles upon the grasslands. What is the orbital equivalent of a pair of hunting lions?
Although the operating companies may not be happy with that, at which point orbital safari weekends will start being advertised.
The reduction of light spill upwards is to be applauded, but the change to LEDs is still controversial: with a far broader output spectrum they are harder to filter out. So we win on one but lose on the other.
Even if the LED emissions are restricted to narrow bands, so that a comb filter can clean them up, the choices made will still tend towards providing "white" light for the "convenience" of the street goers, the filters will let electronic imagers carry on observing but it is still difficult to just show little Jimmy the night sky as the street light intrudes on the back garden.
Let's get some single-frequency street LEDs that can be paired with inexpensive filters for winter evenings learning our way around the sky.
> You're right in principle but wrong in fact.
Hmm, going to have to disagree on that score.
> The light pollution on earth affects the ... hobby astronomers ... but not the main telescopes and observatories
There really is no such thing as "the main" telescopes. There are the big 'scopes, which are gorgeous and lovely but very few, and there is the (relatively) huge fleet of 'scopes run by amateur astronomers (note: amateur, not hobbyist - seriously!).
Astronomy is unique amongst sciences today in that the amateurs are *still* an important resource: they can, and do, devote huge numbers of hours of 'scope time to monitoring targets that aren't on the schedules for larger instruments - including those that just swamp out the big boys, namely the bright planets in the Solar System.
There are, of course, hobbyist star gazers as well, and more joy to them, but please don't discount the importance of the hardy and dedicated amateur astronomers.
> but not the main telescopes and observatories
Not now, because they have been forced to move to all the remote locations! The move of the Isaac Newton instrument from Herstmonceux to Hawaii was not universally greeted with joy in the locale. It made scientific sense, with the encroaching lights of Eastbourne and the obviously greater number of cloudless days away from the Channel, but it - and all similar moves - cost greatly in allowing observing time to be used for training up the next generation and for engaging local public interest. This was a few decades ago now, but that just shows that this is another of those long-term, creeping, problems that just allows too many people to shrug their shoulders and say it has been that way all of their life, nothing to do about it, we can't go backwards - as though it is some inevitable law of nature that things must get worse (no, that is *not* what entropy is all about!)
> But light pollution does have measurable effects on insects and birds
True.
And mammals, including humans (hanging heavy blackout curtains works but hardly makes for a light and airy living space the rest of the time, looming all the time).
Considering how many outdoor lights around here are badly positioned and vastly over-powered for what they claim their function to be[1], even without taking into account the effect on night-sky observing, it would be a very good idea to levy a monthly charge on them. Base the amount on the overspill in every direction.
[1] especially love the supposed "deterrents" that so brightly light the entire area that they simply make it far easier to burgle the place: just carry a clip board and you can load up whatever you want, everybody just assumes you are meant to be doing that because not an ounce of skulking or other suspicious behaviour is required.
> space based observatories are going to have to continue to be more of a thing
Yay, let's just lift all the units that make up the VLT up into orbit, that should be easy enough! Anyone got a slide rule, want to take a guess at how many launches something like that is going to take?
Space telescopes are really good at some tasks, but for others we are not going to get any better than planet-bound for a long, long time (as in, as soon as we invent whatever powers the Star Trek Next Gen shuttles to get the lift capacity).
Things that Earth-bound 'scopes are good for include all-sky surveys, looking for new things that might just be getting a wee bit too close to us, minor things like that.
> the number of satellites isn't going to decrease
If we are lucky, something more sensible will take their place for comms and then we just (!) have to wait for the majority to de-orbit. Something that our children can look forwards to, perhaps.
Why do people write such bad C++?[1]
I've seen things you people would not believe: torturous code with deeply nested template declarations; use of string types without considering copying behaviour, terabytes of in-core duplication just to generate kilobytes of LAN traffic.
But it is entirely possible to write neat, legible and efficient C++. To start with, if you're gonna nest the template decls, hint: "typedef"!
> The code that first year (freshman) students normally submit...[1]
[1] I blame the fetishisation of "Modern C++" and the first year's following "coding influencers"! Knuth and Dykstra[2] were good enough for you Grandfather's generation, they are good enough for you!
[2] Even if you can't pronounce them![3]
[3] Pah! Practice on this: car, cdr, cadr, caddr
> Although there do seem to be various libraries for subsets of it.
Or you make the editor run with a browser-based front-end (your editor is in JavaScriot or runs as a server) or use an embedded "browser-like" library, such as Sciter (the successor to HTMLayout, which had a far more self-explanatory name).
Then your SVG editing comes down to tracking the mouse and updating a node position in the plain text.
Similarly, there are multiple methods for handling PNGs - Fly is a seemingly forgotten but still very useful little program to wrangle bitmaps from an input script, leaving your editor to just handle the text.
After all, "produce an editor" needn't mean it is as full-featured as GIMP or PhotoShop (many smaller editors exist and are *very* useful too: thank you, Irfanview) AND one thing you would hope to gain from using an LLM trained on much, much text from the web is that it has picked up info on lots of otherwise obscure libraries.
Given the above, it does become a nice test to see if the LLM can join the dots in a non-obvious way (i.e. not "just" trying to replicate Photoshop) : far more interesting to see it do that than just using it to save your typing yet another simple loop!
> The real takeaway here is its human freshman-like adaptability: It wasn't just about getting the right solution; it was about refining, learning, and iterating.
Nope.
The real takeaway here is that The Register is presenting a symposium paper, which is little more than an anecdote, in the same style as it would a paper published in Nature[1] and then ending with its own clickbaity conclusion!
Mutter mutter, El Reg never used to be like this, it was all so much better in the old days.
[1] well, not quite - it would be crowing that they'd waded the whole way through a Nature paper!
Ok, not so long - the paper is 11 pages long and the vast majority of it is just stating the programming problems.
And the protocol is utterly dreadful, especially for testing an online service (which can, of course, be updated without your knowledge): the English and Croatian runs were separated by a week (implied to be the time it took to translate the questions) so no definite statement that they were guaranteed to be using identical software both times! Repeatability in Science? Pah, that is for weaklings!
They did not bother to perform multiple runs in each language, to check for any changes due to randomisation in any part of the process or for changes due to subtle differences in the wording of the prompts.
They openly admit that they do not know if the model is still learning/retraining (i.e. immediately incorporates its recent conversations back into itself[1]) and then ascribe the change in behaviour to that process - if you do not know, you can not ascribe! And, anyway, inputs spread over a week? How is that recent in terms of a public online service? How many other people's inputs would have been included if the model *was* continually updating itself?! Even if they do not believe that working on such shifting sands was a problem to their conclusions, they fail totally to even mention that, as if they had never even considered that!
As this is a symposium paper, not something published in, say, Nature, there is some leeway to be given - but not that much!
[1] btw, for various reasons, there is no good reason to think it is continually retraining[2].
[2] yes, they probably are recording your sessions, to feed into the *next* model - and whatever half-hearted "protections" are being applied to your inputs to stop you asking naughty questions.
> All of this raises an important question: Does ChatGPT always choose the best strategy, or does it sometimes default to learned but inefficient methods?
Or neither, as it isn't a Planner and isn't picking any strategy at all!
> Yet, when researchers revisited this challenge in English, ChatGPT seemed to have learned from its previous misstep, returning to the simpler method.
Or it has reverted back to the same set of triggers it responded to the previous time it was asked in English and so produced a similar result again.
Hey ho, let's download the PDF and see if the trial protocol was really as appalling as this article is describing. I may be some time.
Typical.
You pour your heart into your personal project, only for someone to come up and pat you on the head: "Aaaw, isn't that just the cutest little library? Give him ten dollars, Hiram".[1]
[1] maybe "patronize" doesn't mean the same thing as "patronise"? Two countries separated by a common language and all that.
