Thy micturations are to me,
As plurdled gabbleblotchits, in midsummer morning
On a lurgid bee,
- VogonPoetry parentI have received feedback from Vox. The article has been updated with a new leading paragraph indicating the fictional nature of the article.
- I have received feedback from Vox. The article has been updated with a new leading paragraph indicating the fictional nature of the article.
- I've written to <voxmeditantis@gmail.com> about how deceptive it was to put the Editorial Note at the end instead of upfront. I stopped reading because sections felt fabricated - but it was presented as an oral history or actual interview. What a terrible way to present the work of a pioneer.
- An Editorial Note is at the bottom (as others have now noted), it should have been at the top. Had I not seen other comments I would likely have believed everything was made up. This is a terrible way to recount the memory of Frances Allen.
- There is something off about this piece. Particularly the section that starts "You passed away on your eighty-eighth birthday – 4th August 2020. Do you reflect on mortality?" I stopped reading after that.
- Now that I've been recalling more memories of this, I do remember there being encoding or "escaped" character issues - particularly with brackets and parentheses.
There was another device between the BBC Micro and the "Versa Braille" unit. The interposing unit was a matrix switch that could multiplex between different serial devices - I now suspect it might also have been doing some character escaping / translation.
For those not familiar with Braille, it uses a 2x3 array (6 bits) to encode everything. The "standard" (ahem, by country) Braille encodings are super-sub-optimal for pretty much any programming language or mathematics.
After a bit of (me)memory refresh, in "standard" Braille you only get ( and ) - and they both encode to the same 2x3 pattern! So in Braille ()() and (()) would "read" as the same thing.
I now understand why you were asking about the software used. I do not recall how we completely worked this out. We had to have added some sort of convention for scoping.
I now also remember that the Braille terminal aggressively compressed whitespace. My friend liked to use (physical) touch to build a picture, but it was not easy to send spatial / line-by-line information to the Braille terminal.
Being able to rely on spatial information has always stuck with me. It is for this reason I've always had a bias against Python, it is one of the few languages that depends on precise whitespace for statement syntax / scope.
- Yes, mostly raw TeX, just plain ascii - not specially coded for Braille. This was quite a long time ago, mid 1980's, so not long after TeX had started to spread in computer science and maths communities. My friend was using a "Versa Braille" terminal hooked via a serial port to a BBC Micro running a terminal program that I'd written. I cannot completely remember how we came to an understanding of the syntax to use. We did shorten some items because the Versa Braille only had 20 chars per "line".
He is still active and online and has a contact page see https://www.foneware.net. I have been a poor correspondent with him - he will not know my HN username. I will try to reach out to him.
- I did a maths undergrad degree and the way my blind, mostly deaf friend and I communicated was using a stylized version of TeX markup. I typed on a terminal and he read / wrote on his braille terminal. It worked really well.
- After writing this I decided to look at my shortcut. The action seems to have been a simple "get directions to <place>" and sent verbatim to Siri.
I was not able to edit / update it! However, there was now a new "maps" option for `Open <type> directions from <Start> to <Destination>`
Where type can now be {driving,walking,biking,transit} and <start> is Current Location by default.
After updating, this now seems to correctly set actual driving directions, even if I'd previously set up a walking route!
- I have experienced some similar issues. I think some of it related to the "locked" state of the device. Siri needs context data to answer, particularly the mom or some destination questions. Specifically for contacts or recent places data. This context isn't remotely stored, but provided by the device to Siri each time. I think when the phone is locked it doesn't have access to the data (reading or writing). When I mean "Siri", I mean both the on device and remote parts of it.
I think this also interacts with countries and states that have (possibly misguided) strict laws forbidding the "touching" of phones "while driving". My experiences suggest that using Siri when driving and the device is locked, it just gives up - I sort of see the start of it working then, bam, it stops. If I retry, I suspect that I've somehow "looked" at the phone in frustration, it saw my attention and unlocked. I now wonder if where I have placed the device is making a difference.
It does seem to work much better (when driving) if the device is already unlocked.
I also see odd things when using Shortcuts for navigation. If I've previously asked for walking directions and then speak the shortcut while driving it won't give directions until I switch to the "car" icon in maps. I think it might be trying to calculate the 15Km walking directions, but it doesn't complete before I tell it, frustrated, to stop.
When Siri doesn't work it is usually the times when I need it to. This is definitely a multiplier in disastisfaction.
- Perhaps using AI assistance is good OPSEC. It could help to shield the author from stylometry or author profiling.
- I see a different error now - a 404 with "There isn't a GitHub Pages site here".
- I agree that my comment about VM was imprecise and inaccurate.
I do dispute your assertion that virtual memory was "disabled". It isn't possible to use V86 mode (what the Intel Docs called it) without having a TSS, GDT, LDT and IDT set up. Being in protected mode is required. Mappings of virtual to real memory have to be present. Switching in and out of V86 mode happens from protected mode. Something has to manage the mappings or have set it up.
Intel's use of "virtual" for V86 mode was cursory - it could fail to work for actual 8086 code. This impacted Digital Research. And I admit my experiences are mostly from that side of the OS isle.
I did go back and re-read some of [0] to refresh some of my memory bitrot.
[0] https://www.ardent-tool.com/CPU/docs/Intel/386/manuals/23098...
- To get feedback / commentary you likely need to change the permissions on the repository, currently it seems to be private.
- VM in this usage means Virtual Memory - i.e. with page tables enabled. Two "processes" can use the same memory addresses and they will point to different physical memory. In Real Address mode every program has to use different memory addresses. The VM86 mode lets you to have several Real Mode programs running, but using Virtual Memory.
- I view it more as a ransom / hostage payment or a response to bullying. There was a threat of tariffs; I'm going to hold your business hostage. The ransom was paid and the tariffs weren't imposed.
I think a bribe is better defined as "you cannot have this thing you want, unless you give me this". A quid pro quo.
I guess it comes down to who the "active" party was.
I would definitely call it a bribe if Tim Cook was the one that asked to get special treatment or lower Tariffs than anyone else and the response was give me a "gift".
Even if you believe it was a bribe, the value of it was purely symbolic. What was given wasn't a change in policy, it was a material gift of zero value to anyone else except for scrap. Others that have been subjected to this behavior have given up things like changes in hiring practices and working with "non favored" organizations.
- Many of these are all excellent points. I did exclude the case.
The car recycling v.s. electronics recycling question is interesting. I once had a very interesting conversation with an electronics recycler on a plane trip - phones could not be recycled like other electronics because of some of the metals content - in particular beryllium copper content (used in spring contacts). He described it as a lot of electronics is ground up and a chemical processes used to extract the valuable elements. With phones the grinding up was the toxic / dangerous prohibited part.
I think the semiconductor numbers are more subtle though. It is sq. mm in the product and yield that are factors. A single power switching element in a Tesla will likely exceed the total silicon sq. mm usage in an AirPod. There is a lot of electronics in a Tesla. Some of the Tesla circuitry is more exotic, Silicon Carbide or GaN. I need to look into how much recovery / reprocessing silicon mfg is using for the reagents. The waste produced isn't as bad as it was in the Silicon Valley heyday where every original mfg site is now a superfund site with very large plumes of toxic waste in the subsoil.
- Everything humans do is carbon negative. Breathing, eating, driving, pooping (Westerners: toilet paper, All: waste management) and building. Getting every human to be carbon neutral would be an amazing thing!
From searched / online numbers, Apple has shipped 150 million AirPods since 2016. The AirPods 3 weigh 5.5g. The gross weight of a basic Tesla model 3 is 1760Kg. I picked a Tesla because it has plastic, metals, magnets, copper, lithium - similar materials.
In the ~10 years Apple has been making AirPods the materials used (by weight) is ~ 470 Tesla cars. So, per year (avg, not really good for this), resources consumed is about 47 Teslas (by weight).
Apple claims 40% of AirPods 3 are from recycled materials, so ~ 290 crashed / discarded Teslas could provide part of these materials - on average 29 per year.
I did the above because it perceptually relates to "real things". Teslas are NOT carbon neutral, very much carbon negative.
The reality / HORROR of waste is far, far worse. Any single plastic bag used to dispose of weekly waste likely weighs more than a pair of AirPods. Any can, made of steel or aluminum, could likely could make a lot of AirPods. The toy or product you bought that had a flap that you could lift up - there was likely a magnet under there. Any disposed single use battery might have zinc, if it was a CR2032 or "watch" battery, lithium (or silver).
Yes, AirPods might be disposable. Do they improve the qualify of life of the humans that purchase them? What is the real cost in perspective - with everything else taken into consideration? If the AirPods are used to listen to music or entertainment, then the positive mental health aspects are likely significant in a positive value direction.
- This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!) have an IPC channel might be affected by the timing.
There is a section in the technical reports that talks about garbage collection.
I don't think CHERI is currently being used with different privileged threads in the same address space.
- The term side loading pre-dates smartphones. The term was used to describe how you got media onto an electronic player. Literally by plugging into a port on the side and loading the media from a computer.
- There are three things in the report that make me believe that it would be possible to get the secrets from eSim profile B from a compromised eSIM profile A if they are both installed.
Under "Notes" it says... The hack proves no security / isolation for the eSIM profile and Java apps (no security for eUICC memory content).
- app isolation is broken
Under "The warning call for mobile phone vendors"... Target eUICC chips may run some sensitive applications (digital wallets / payment, digital car keys, transportation cards, access / identification cards, etc.). In case of a successful eSIM compromise, the security / credibility of such apps may be affected.
- perhaps code for we already know this is possible, not talking about it yet...
And towards the end, under "Some recommendations"... always assume your apps, their logic, associated secrets and/or some eSIM content could be revealed (one compromised eUICC identity can be used to download and peek into eSIM of any MNO)
- directly talks about other secret extraction
- Yes, totally agree. Also a paragraph on the relationship between energy, heat, cooling and that computers effectively turn all energy into heat might have been useful.
The April 1st date on the article is telling.
Shout out to "Technology Connections" YouTube channel for recently publishing "Power is not energy" - <https://www.youtube.com/watch?v=OOK5xkFijPc>.
- The Atmel AT90USB162 chip multiplexed the USB D+/- pins with an SDATA and SCK PS/2 port. It is possible to build a "serial" to PS/2 or USB bridge device with very few components. The part seems to still be available from Microchip.
- Not really, but that really wasn't what I was trying to say. I was trying to counter what I thought was a faulty equivalence argument; AppleScript allows unrestricted use of iMessage today, so giving watches an API won't make it worse.
I do think that the state of AppleScript automation is the result of trying to break the mechanisms that were being used to generate SPAM. Could you agree that automation capable interfaces do increase the chances of bad actors taking advantage? Right now, with a lack of information, I don't know how I could make an iMessage automation interface "safe by design".
I do see a direct path from the mandated AT&I breakup and interoperability rules to SIP / VOIP services and the resulting levels of Phone spam and caller-id fraud. This has cost a lot of people, life changing amounts of money and much wasted effort and time.
Un-nuanced tech laws or mandates have a terrible track record for having bad side effects. Those effects often never get addressed, which makes me wonder a bit about the original motivation of why the laws came to be in the first place.
I also see a narrative that company X will automatically refuse to work with company Y or community Z and are de-facto always acting in bad faith. Even if company X was never approached or asked - yeah, companies do tend to isolate themselves making direct communication very, very difficult. I cannot deny that there are some company X's that do seem to behave very poorly. A counter example, in my opinion, is the recent Bambu labs API issue. As a tinkerer, a few minutes of looking at how people had built interactions with their printers strongly suggested to me that Bambu introducing an actual API endpoint was a really, really sane thing for them to do. (I did comment this way). Only time will tell if Bambu was actually trying to improve things or was acting in bad faith.
- The default 4GiB setup is done to very quickly catch poorly written / ported 32-bit code that promotes a 32-bit integer to a pointer. In 64bit mode, such a promotion will create a pointer with the top bits set to zero. Any de-reference of this sort of promotion will cause a SEGFAULT. This might happen if some sort of mixed mode compilation happened for a 64bit process where some of the code was still compiled and linked assuming 32bit mode. (mixed mode Intel code mostly)
- It isn't easy to do with just AppleScript on a Mac. I run a sports team and I wanted to send out a message to people for special situations. Some of the challenges are that you cannot script sending a new message if there isn't already a thread -and- it seems like you must use the same contact info (email or phone number). There isn't much feedback when it goes wrong. Some of these do make sense for preventing spam. I suspect I could have used the accessibility APIs to drive the UI. I eventually gave up.
- Your criticism is valid. Adding context is very subjective. Getting objective metrics to some of these questions is an open issue for the software world.
I don't think it matters if the vulnerabilities are JIT related - a process that can JIT can create code, so any exploitable (controllable) overflow or memory vulnerability CAN be pivoted into arbitrary code execution.
The problem with CVEs is that it is not required to prove exploitability to get assigned. It can take a lot of effort (single or multiple people) to prove exploitability. Earlier this week someone quoted "weeks" to me for each bug. They were quoting numbers for some of the Chrome bugs. These researchers said it was not possible to keep up with the number of bugs being found.
I believe (but cannot back it up) that security bugs follow a bathtub curve for each change set. If you've got a lot of change in your code-base then you'll pretty much be on a high bug point of the curve for the whole project. It also probably matters quite a bit about what sort of changes are being made. Working to get high performance seems (again a feeling) to increase the chance of creating a security vulnerability.
The level of public research is a tough metric. The reward / motivation factors are not the same. There is also an issue with internal research teams. They will find bugs before they are released, so they never really "exist". Does measuring the number of CVEs issued indicate the quality or level of internal research? What is a "good" metric for any of this?
- For those complaining about not allowing 3rd Party JIT engines for 3rd Party Browsers. Please consider the vulnerability track records for Google Chrome, Mozilla Firefox and Safari:
I'm taking the best year for all of these (2024) - there are far worse years in the past 5 that could have been picked.
Chrome had 107 vulnerabilities that were Overflow or Memory Corruption. That is a vulnerability every 3.4 days. [0]
Mozilla had 52 vulnerabilities that were Overflow or memory Corruption. This is a vulnerability about every 7 days. [1]
Safari had 10 vulnerabilities that were Overflow or Memory Corruption. This is a vulnerability about every 36 days. [2]
Sources:
[0] <https://www.cvedetails.com/product/15031/Google-Chrome.html?...>
[1] <https://www.cvedetails.com/product/3264/Mozilla-Firefox.html...>
[2] <https://www.cvedetails.com/product/2935/Apple-Safari.html?ve...>
- Try:
First one stops Spotlight. After creating the stop file, the .Spotlight-V100 directory can be removed.touch "${vol}/.metadata_never_index" touch "${vol}/.fseventsd/no_log"