Posts by robinsonb5 95 publicly visible posts • joined 4 Aug 2022
> I'd also like to get rid of Amazon's continued insistence that I have Prime!
Someone I know tried to cancel Amazon Music a few months back. There were that many dark patterns in such close proximity I'm surprised a black hole didn't form.
My concern with summarization is that it adds another layer of separation between end users and primary sources - and one that offers an oportunity for deliberate distortion and manipulation.
The guardrails built into existing systems - however well-intentioned they might currently be - demonstrate that it's (a) possible, and (b) being actively worked on.
> Does that mean although it does have enough (l)users, nobody believes anything posted on it?
The answer is in TFA: "...given that the investigation revealed that X is not an important gateway for business users to reach end users"
Apparently if the platform only negatively impacts regular everyday people, and not corporations, it doesn't matter.
A non-technical person I know is in the process of letting a house to her friend. She was gleefully showing me a few weeks ago how she could use Gemini to write a rental agreement - and was quite dejected by my horrified reaction. She just couldn't understand (a) that the output might not be completely (or even remotely) correct, and (b) that even in the unlikely event that it was, none of us was qualified to asses its correctness. (And that's leaving aside the ethical aspects of how the training data was sourced.)
So yes, it wouldn't surprise me if that ends up being a use case for AI.
A couple of weeks ago I had a random email from someone wanting support with a website (set up in 2019) which just happens to share a name with a piece of software I wrote back in the early 2000s.
The email began: "You would not believe the hoops I had to jump through to find your email address. Thank goodness for ChatGPT!".
<facepalm>
I haven't seen the principle of LLMs described as succinctly as this before, but the sentence:
"Microsoft positions its Copilot tool as a way to make users more creative and productive by capturing all the human labor latent in the data used to train its AI models and reselling it."
displays perfectly why the whole LLM scenario leaves such a bad taste in the mouth: the human labour latent in that data was never theirs to resell.
> Also - as far as I can see it's not actually possible to create private native GitHub forks of public repos in GitHub
The example they cite is when you have a private repo that will eventually become public, fork it to make permanently-private fork and then later make the original repo public. Anything commited to the still-private repo up until the point the first repo is made public, can be accessed from the now-public repo. (As long as you know the commit hashes, that is - but unfortunately they're easily discoverable.)
The one case they talk about where the contents of private repos become publicly viewable is when a formerly-private repo with a private fork is made public.
In that case, any commits made to the still-private fork up until the time the parent repo became public are accessible from the public repo. That runs counter to users' expectations.
(Any commits made to the private repo *after* the parent one has gone public will remain private, however.)
The issue is that people are mentally modelling forks as "that's my copy of the repo, completely separate from the original" whereas in reality the fork is just a different interface to the same pool of blobs. Furthermore, while you wouldn't be able to access commits from another fork in the same pool of blobs unless you know the commit hash, github makes those commit hashes discoverable.
> No it isn't. It's supposed to be a history. In a code repo, the ability to permanently delete past changeset data should be considered a bug or design flaw. The inability to lose history is the whole point.
While that's true, when a user deletes a fork, their expectataion is that the fork is a separate repo which can be deleted in its entirety, history and all. The "obvious" mental model of what's happening is "that's 'my' copy, separate from the original." - but that's not how it's actually implemented.
I always considered UBI to be too radical to ever catch on.
Then the pandemic came along, and large numbers of people received furlough payments which, if you squint, kind of look like an at-scale trial of UBI.
Now with the world changing so rapidly thanks to new technologies, I'm almost persuaded that UBI is not only desirable but a necessity in the near future. But I think it'll only work if the problem of sky-high rents is solved first, otherwise rents will simply go up by whatever the UBI figure is. I'm hearing people talk of land taxes both as a potential solution to this and as a means of funding UBI. Any way you look at it, there are interesting times ahead.
I drive no more than half an hour in a single day, and often don't touch the car for a week at a time.
I have a little "runabout" and I'm not that fussed what the seats are like.
If I spent most of my working day on the road I'd want to be damn sure those seats were comfortable.
Oh boy - yes, both keyswitches and keycaps are complete rabbitholes, and there are so many potential combinations that someone selling a product can't possibly hope to cover them all.
Do you want your switches to click when you press them? Do you want smooth linear travel or a tactile bump? How heavy? Do you want heavier springs on the keys that fall under your index fingers?
What colourway do you want for the keycaps? Do you want them made of ABS plastic (cheaper, higher-pitched sound, less durable) or PBT (more expensive, more durable, usually "better" sounding.) Do you want cutesy multicoloured keycaps with Japanese characters or vintage Wyse terminal keycaps (yes, they'll likely fit just fine.)
And that's before you've entered the realms of stabilisers and lubrication.
But with all these options, the one that's hardest to find is the one that actually matters to me: keycaps in ISO / UK layout ("£" on shift-3, backslash cut out of left shift, '#" cut out of an L-shaped enter key - ANSI (with thin horizontal enter key) seems to be all that's served by 98% of the market.
Chyrosran22's videos on YouTube are endlessly entertaining (but NSFW) if you want to see reviews of some modern but mostly vintage keyboards, and a viscious (but well-deserved) skewering of certain fashion trends.
(Typing this on an early 90's IBM Model M.)
Be the change you want to see in the world. Encourage those who are doing things you do like, and ignore those who are doing things you don't like.
Will it make a meaningful difference? OK, probably not - but at least you'll be contributing while remaining true to yourself.
The other problem is churn.
Writing software is only half the story - even once it's 100% finished, done, itch successfully scratched, it won't be many years before something changes and it can no longer be built on current systems. I've abandoned software I wrote in the past because the subject was no longer interesting to me (I'm not going to update photo printing software when I no longer have a printer at home) - and I'm not alone in that. My leisure time is limited, I can either spend it exploring new and interesting things or I can spend it maintaining old boring things - I can't do both. If someone wants to pay me to do the latter I might consider it.
Similarly, because of the constant churn, I elected not to target either GCC or LLVM when I started a toy CPU project a couple of years ago - instead using vbcc because it's small, lightweight, and can be built in seconds. The chances are very high that it will be buildable without modification a decade from now.
That's also one of the reasons I'm now into the Retro scene. Just yesterday I revisited an old piece of Amiga code and updated it for use in a new project. There's something quite satisfying about a copyright header in a source file which reads "Copyright (c) 1998, 2014 ...."
Thing is the circumstances of the shock - not to mention the individual's skin resistance - can make a huge difference. I was fortunate enough that the last 240v mains shock I had (while twisting together wires that were supposed to be isolated), left me musing to myself "hmmm, that feels a bit spicy, what's going on here.... oh *shit*, better turn that off!" rather than throwing me across the room. I'm not blasé about it, though - I'm well aware that had my other hand been touching something earthed I might well not be telling the tale.
> Tiling windows is a MASSIVE step backward.
I can see that they'd work well if all you use is a bunch of terminal windows. Overlapping windows certainly have their advantages but there are also problems with the way they're typically implemented today - and the pop-to-front-on-any-interaction model interacts badly with drag-and-drop unless you add special-case workaround (like Windows did some 25 years back) to prevent it when starting a drag-and-drop operation.
I suspect avoiding those problems is another part of the appeal of tiling window managers. Personally I sidestep the issue on Linux by just disabling raise-on-click - but I wouldn't put money on how many more years that'll even be possible.
> Windows can now have borders, and that of the active window can be a different color, to make it more obvious which one you're typing into.
Steady on, people - I'm not sure the world's ready for that kind of innovation.
Seriously, though, now I'm getting older and less eagle-eyed I really appreciate those kinds of visual cues, and find their disappearance elsewhere extremely annoying.
Largely the same here, but the confirmation was pretty much instant for me.
Had the request been denied I'd have had no hesitation in deleting the account, and I suspect that goes for quite a lot of people who filled in the form.
Much as I loathe meta, I do have to admit they have a solid understanding of human psychology, and are pretty good at riding the boundary of the Overton window.
Indeed. I stopped using it for actual file sync some years ago, when first the Android app wouldn't run any more on my (old, but better at making phone calls than my newer) phone.
I still used the shared folders facility from time to time, because they worked just the way I wanted them to and were relatively friction free for the end-user too. I could upload a bunch of photos into a shared folder, send a link to the recipient and they could painlessly browse them, view them and download any they wanted to keep - either finely-grained or en masse. That was incredibly valuable since the recipient didn't need to be a collaborator (and thus have the storage deducted from their own quota) - or even logged in.
They've recently employed every dark pattern in the book to make it next-to-impossible to use that way, without technically withdrawing the facility - so I won't be using it any more.
Anyone know of a non-shitty alternative, or am I going back to WeTransferring .zip files?
A friend of mine has a porch with an regular lock on the internal front door but an electronic lock on the outer door. The electronic lock can be fingerprint operated (with varying degrees of success in varying weather conditions!) - but the killer feature for him is that he can give a one-time entry code to a courier, and have parcels left securely in the porch.
I thought the pigment-based Epsons were the worst for clogging (I first noticed it with the C64, C84 and MFC equivalents)?
Not that the dye-based Epsons were immune to it - my R300 photo printer eventually died to an incurable clog but that was years into its lifespan.
I always thought Canons were less prone to death-by-clog because the cartridges contain a disposable print head. Canons do seem to be prone, however, to death-by-waste-ink-counter!
I used to run a printing company, and 15 - 20 years ago Publisher files were the absolute bane of our lives. By the mid 2010s Publisher had relinquished its role as the Bane of a Printer's Life, replaced by PowerPoint. Oh, the joy of full-bleed-but-bleedless PDFs which aren't even the same shape as the piece of paper they're supposed to be printed on!
The phrase I've used for it in the past is "30 foot high Jenga tower".
I have a small amount of hope that people tinkering with RISC-V cores on FPGAs will have more appreciation for lean, lightweight software than those of us using "proper" computers, since they typically have less than a gigabyte of RAM to play with, and often as little as 32 meg - not to mention relatively slow SD card storage.
For my own toy CPU project* (not RISC-V - I was crazy enough to create a whole new ISA from scratch) I took one look at GCC and thought "no way in hell am I tangling with that" - so I wrote a backend for the vbcc C compiler instead, and an assembler and linker to go with it. The whole toolchain builds in a few seconds, and as a bonus it's lightweight enough to compile and run on an Amiga!
[https://github.com/robinsonb5/EightThirtyTwo]
Interesting - I didn't know about UASP - but it appears to be a pretty new development?
It's not performance I'm concerned about - it's lifespan.
The way wear levelling works (or at least did on CompactFlash 20 years ago, when I learned about it after killing a CF card in an IDE adapter*) is that the device does logical-to-physical block mapping, and keeps track of how many times each physical block has been written to. There's a small pool of "spare" blocks (not counted in the nominal capacity) which it swaps out when a heavily-used physical block is re-written.
When the device is brand new, all the blocks on the device are unwritten and thus in the "spare" pool - so if you re-write one small file 1000 times, those writes will go to 1000 physical blocks instead of hammering one block with 1000 writes. If you do a test that involves writing to the entire device and then don't trim it, the pool of spare blocks is now depleted to just the small number of over-provisioned blocks, so a bad write pattern can now wear out the device much faster.
[* use dd to write a disk image to the card, then mount it without the noatime flag. It won't last long!]
"Despite Universal's false narrative and rhetoric, the fact is they have chosen to walk away from the powerful support of a platform with well over a billion users that serves as a free promotional and discovery vehicle for their talent," *
Does this remind anyone else of pubs and bars expecting bands to play for free in return for "exposure"?
It's hard to root for either side here, but anything which serves to reduce TikTok's appeal is probably a net gain for humanity...
[* a continuation of TikTok's quote, omitted from TFA, but which I read elsewhere.]
Yup, my local Morrisons has done the same, with the result that I now use the store significantly less than before. The staff tell me I'm far from the only one.
When the terminals were first installed they paid a member of staff to wander up and down the queues for the real checkouts, attempting to harrass shoppers into using the new self-service terminals.
On one visit I noticed a shopper in the next queue getting visibly agitated until she was able to place her shopping on the conveyor belt, at which point she heaved a visible sigh of relief and said "Now they can't come and get me."
I miss the days when the business / consumer relationship was mutually beneficial, not outright adversarial.
> 3a. What sort of lousy assembler lets you accidentally begin assembling an instruction on an illegal address?
Actually neither the 68000 nor 68020 can execute instructions from an odd address - so I suspect what actually happened in the story was an instruction's word- or longword-sized *operand* was on an odd address - which would cause a bus error on 68000 but be OK on 68020. (Probably using move.l to copy the credit string as quickly as possible!)
While I feel an ideological revulsion towards this, I do have to concede that it's not really obscure as such: it's just symptomatic of having been designed by a member of the "phone first" generation - people to whom the idea of an internet-enabled phone not being available at all times is unthinkable.
Pointing a phone camera at the screen is arguably more convenient than typing some error message or code into google (especially if you only have a crappy on-screen keyboard available because your systemd infested computer won't start).
> No, MS wanted it -- I don't know why or what for
MS's behaviour and attitiude towards Linux in recent years has been interesting - on the one hand they've embraced it with WSL and VMs and Azure - and on the other hand they've continued their long-term efforts to lock it out of consumer hardware (Pluton, signing key shenanigans, etc.). It makes me wonder if they have designs on Windows becoming an underpinning BIOS-like layer which Linux runs on top of - in which case controlling the RTOS used for IME makes perfect sense. If that RTOS is no longer used by IME and they have no further use for it, then they might as well toss it into the copilot code grinder.
> boil down to exactly the same thing.
They kind of do, but carry very different connotations: The latter implies that those people's basic needs will still be met on some way, shape or form. You could replace "doing more interesting things" with "gently decomposing in preparation for a future of pushing up daisies" and still be consistent with the former.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
