Avraham “Abe” Bernstein | CV

1. The company's core product relied upon refactoring the automotive client OEM's source code in order to make it much more efficient to generate software updates. Sometimes their product could reduce update times 10x compared to the default technique of using LZMA (i.e. successor to zip) compression.

2. I invented an extremely efficient technique to greatly improve the efficiency of their initial offline refactoring of embedded C software by combining the srcML compiler AST output in XML format with the Python Beautiful Soup library in order to generate the refactored source code. I improved their build speed time by 5x (i.e. from 6 hours to 1 hour) and reduced RAM consumption by 2x (from a 64 GB workstation to 32 GB). Admittedly their original refactoring engine was a hand coded C to AST compiler which they implemented in Python.

3. I invented an algorithm (US patent pending) for embedded systems to greatly reduce RAM usage when the software generates FLASH files by modifying the internals of the ubiquitous C memcpy function by incorporating Posix-like buffered I/O when memcpy is used to sequentially write to FLASH. The RAM savings enables usage of larger bsdiff patch "chunks" that enables higher compression ratios for legacy system boards with small amounts of RAM, i.e. 64-256 KB. Sometimes compression ratios could be improved by up to 25% - where the critical KPI in the software update business is improving compression ratios.

4. The company wanted to develop a commercial application that could estimate the CPU cycle time of embedded programs designed for the Infineon TriCore CPU. Since AI became "cool", they hired an AI expert to design an LLM that could be trained by using thousands of automatically generated random programs attached to a JTAG device in order to measure the instruction cycles. Initially it was my task to generate syntactically correct programs in assembly code that did not have nonsensical branches or loops. I designed the generator in Python. Afterwards I greatly improved the accuracy of the LLM estimations by simply using the instruction cycle times specified by the chip's assembler manual along with designing a relatively simple model of the CPU's pipeline. Even though there was already a FOSS QEMU description for the CPU (1) it did not take into account the pipeline, and (2) my instruction specification Domain Specific Language (DSL) included non-QEMU extensions in order to allow for simple generation of random instructions. With perfect hindsight, I should have redesigned the DSL in order to merge my extensions into the QEMU CPU description.

   • I sketched a design for a proprietary QEMU generic extension that would allow "smart" programmatic access to the I/O ports, but the company closed before the work could begin. Note that I invented this same feature c. 1993 for the debugger and simulator that I implemented for DSPG. It was critical for enabling them to design and debug application programs 6 months before their physical chips became physically available.

1. I reverse engineered the X64 object code of the Linux kernel module libc in order to modify the internals of the exec functions, where these functions are used in stack smashing attacks, but without changing the addresses of any of the libc exports.

2. Inserting the extra security functionality into these functions necessitated a slight increase in their sizes, therefore it was quite challenging not to change the addresses of any of the other libc functions.

3. I implemented the project in Python using the Zydis disassembler Python library.

4. Note that every X64 Linux release and distro will likely have a slightly different libc object code implementation.

1. I implemented C cryptography functions in Javascript web assembly (WASM). WASM object code is much faster and much more difficult to debug than Javascript. Because this project was intended for the banking industry, in the future we could write a WASM obfuscator that would greatly increase the difficulty of debugging.

2. I implemented the project by using Clang's wasm32 target.

1. I architected and implemented a software design for efficient software updates of the object code of embedded systems using the FOSS mini-bsdiff delta encoding combined with the embedded FOSS xz binary compressor. Note that delta encoding enables significantly smaller, e.g. 10x smaller, software updates compared to zip-like updates when the update contains minor differences.

   • The original bsdiff software is not designed for the size limitations of embedded systems especially for legacy automotive boards.
   • In particular the original bsdiff software incorporates the outdated bz binary compressor that has a 100 KB RAM footprint.
   • Mini-bsdiff is not bundled with any binary compressor at all.
   • The xz binary decompressor designed for embedded systems has only has a 26 KB RAM footprint.
   • During the offline preprocessing of the patch "chunks", we calculated the RAM consumption of the processing stages in order to design dynamic memory overlays per chunk. More efficient use of RAM enabled us to process bigger chunks which compressed better than smaller chunks. Compression efficiency is the core KPI of the software update industry.
   • Note it is usually not computationally feasible to generate an offline mini-bsdiff patch where at least one of the source files is larger than 8MB, in which case it is preferable to use the (less efficient) VCDiff/xdelta algorithm that is commonly used on web sites.

2. I invented EU Patent EP3680773A1, a mini-bsdiff patch implementation for small FLASH memory systems where the FLASH is not big enough to temporarily hold both the original version "A" and new version "B" of the object code. Normally the bsdiff (and mini-bsdiff) algorithm requires both versions be available when applying the patch. I had discussions with Colin Percival the original inventor of bsdiff.

3. I experimented with Google's Courgette improvement to bsdiff, but it required a relatively large amount of RAM on the target device in order to support a linker. Such large RAM is not typically available on legacy boards used in the automotive industry. I invented an algorithm that dispensed with the need for a linker.

4. I experimented with techniques for using source code patching instead of bsdiff object code patching. The Elektrobit management refused to believe that it was commercially feasible to have access to an OEM's source code. I switched jobs to Aurora Labs above because I believed that Aurora Labs' source code patching is a better solution.

5. I was the company's Misra C "enforcer". While I understood the safety rationale and the legal requirements for Misra C, I found many of their rules to be unnecessarily pedantic. I developed Jinja2 preprocessing utilities that worked around these pedantic rules, but that still generated valid Misra C code.

1. The company publicizes and collates social media posts of antisemites, anti-Zionists, and terrorist "wannabes". Their information was used by the Israeli government immigration authorities, and by potential employers who often did social media background checks. Because they were effective at blacklisting (aka "outing") these miscreants, left-wing organizations, including "progressive" Jewish ones, hated them. They were the subject of intensive hostile investigations by professional left-wing media organizations including Times of Israel and The Forward - who by the way eventually "outed" them. Therefore the company required cybersecurity "hygiene".

2. The vast majority of their employees did journalist-like tasks. They had garden variety computer skills, and therefore would not be capable of handling sophisticated tasks like using virtual machine clients (e.g. VirtualBox) or using PGP.

3. The following are relatively simple, but effective, cybersecurity defense recommendations:

   a. Use the then most recent Windows 10 Professional O/S on account of its regular security updates and its support of BitLocker full disk encryption. PCs are lost and stolen.

   b. Use a random PC login password from a USB security token such as Yubico. At that time the basic capability of the token was to store and emit a permanent manufacturer-configured "random" 16 character password. (More modern keys support additional services such as TOTP authenticator one-time keys with a timeout). By pressing the button on the token it would act as a second keyboard in order to allow the password to be emitted into the PC. In addition to the token password, it was extremely important to add a (memorized) suffix, otherwise if the token were lost or stolen then security could be compromised.

   c. When the PC is unattended close the cover, and use a screen saver with a relatively short timeout, e.g. 10 minutes, Configure so that resumption requires a password.

   d. Use the Firefox web browser (and especially not Google Chrome !) with multiple profiles in order to defend against cross-site scripting attacks. There is no information leakage between profiles. Also still today (2025) Firefox has the best builtin bookmarking tool. They should at least use the following profiles:

    * personal email and banking
    * personal browsing
    * company email and accessing company data
    * work related browsing

   e. Use email aliases when required to access potentially hostile social media.

   f. Use strong random passwords generated and stored in a local FOSS password database application such as KeePass, and not a commercial password server in the cloud (which have historically been periodically hacked). And as long as the user used his security token to protect his password database with his permanent password (appended with his memorized suffix), then he could safely store the database on a disk-on-key or a cloud file server such as Dropbox.

   g. Use 7-zip for password protection of disk-on-key storage or file transfers. For file transfers, It has the disadvantage of using shared passwords, and therefore not nearly as secure as PGP, but definitely far better than in-the-clear transfers.

   h. Make weekly encrypted backups of user data.

   i. Assign an employee along with a deputy to be security monitors. They should store backup security tokens and user PC backups off-site. All employees must pass a quick monthly security review from the monitor.

1. I focused on obfuscation, i.e. anti-reverse engineering, of their smartphone (i.e. Android and iPhone) client player, by selecting a C/C++ obfuscating compiler and by building home brew utilities. I selected the WhiteCryption compiler originally built by InterTrust (subsequently acquired by Zimperium in 2021 after I left). When I first selected WhiteCryption, it was still in the beta stage. I worked very closely with the WhiteCryption development team - mainly specifying new features and testing existing ones. Previously I worked on an in-house obfuscation compiler at NDS (called chameleon), which I considered to be far beyond the manpower resources we had available at Viaccess-Orca, therefore I decided to use WhiteCryption as our contractor. After I left Viaccess, they switched to the French Quarkslab obfuscating compiler partly because Viaccess' HQ is also in France.

2. One of my most important utilities I invented was an ELF Dynamic Share Object (DSO) (i.e. an so file) which had no export table which ostensibly eliminates the usefulness of a DSO (thus making the term into an oxymoron). I designed a low level asynchronous mechanism to load an encrypted export table relying upon ELF's special init section which executes code in the address space of the caller when the DSO is first loaded. It is an uncommonly used feature of the DSO. I designed this mechanism because the export table is one of the major attack surfaces in a DSO.

3. I worked with the 3rd party software supplier of the video codec in order to substantially bolster the security of their product which proved to be a major potential security hole in our system. The challenge was that most of their customers did not require the security that we did, and for practical commercial reasons they were not willing to make a separate build for us. I managed to architect an optional security plugin for them that caused negligible changes to their system, and caused zero interference to their other customers who chose not to use a plugin.

4. Initially the movie studios insisted that our player client software would not be allowed to play their content unless the client was rooted because it made the client considerably more difficult to debug and to prevent piracy. Therefore I developed an extremely accurate fuzzy logic algorithm to detect rootedness with almost no "false positives" (because the out of pocket and negative publicity costs of falsely accusing a subscriber of having a rooted phone were horrendous). The problem was that less expensive Android phones from the Far East were flooding the market, were rooted by default because it saved the manufacturer a few hours of licensing work from Google who controlled the Android Open Source Project (AOSP). Therefore the studios agreed that security had to be moved from the client to the content servers. For example a subscriber who played 100 hours of content a week was suspect, or a subscriber who played content simultaneously from different geographic locations was suspect.

1. The company developed cassava (aka tapioca flour) processing facilities in rural Nigeria. Before Nigeria joined OPEC, cassava was their primary sustenance source of food. Now that their oil reserves are dwindling, and world demand for oil is decreasing, the Nigerian government is preparing for the day when they can no longer afford to import subsidized wheat.

2. My job was to search for technology, primarily from Israel, that would be useful for establishing factories in rural jungle regions where the cassava is grown. For example:

• food storage techniques for hot humid regions that do not require refrigeration
• small gas turbines for electricity generation
• local area cellular telephone network
• portable hospitals, the size of a shipping container
• portable modular housing units that are foldable and can be loaded from a flatbed truck
• protecting the undercarriage of off-road vehicles

1. The company was a failed competitor to Waze.

2. I developed algorithms to improve traffic throughput in traffic jams taking advantage of expected traffic trends according to history of the day of the week and expected events. I developed probabilistic algorithms to prevent generating secondary traffic jams.

3. I designed live experiments using AWS simulations to optimize results. Coordinated work with a mathematical consultant specializing in optimization algorithms for a huge number of variables.

4. Theoretical algorithm experiments were conducted on a simulator of Tokyo traffic.

The company's product was a novel dry test kit for MRSA using PCR (a DNA amplification device). MRSA is a lethal strain of staphylococcus bacteria. It thrives in hospitals where it is the major iatrogenic killer of immunologically compromised patients. Therefore it is critically important that hospitals identify carriers among both patients and hospital staff as soon as they are infected. Most people who are infected with MRSA carry it in their nasal passages. Most interesting such a person, even an immunologically compromised one, can still live until 120. However if an immunogically comprised person touches his nose, and afterwards touches an open wound then he is in danger of death. Prior to PCR technology, it took a laboratory about 48 hours to identify the disease by growing a culture in a "gold standard" Petri dish, but PCR technology can make the identification within 2 hours.

Before joining the company I had zero university background in biology, microbiology, genetics, or biochemistry. When I arrived the company was in imminent danger of closing down their PCR business unit because their initial FDA trials completely failed that they had spent about $500K to prepare by collecting 800 patient samples from a few Israeli hospitals. The owner was "pulling his hair out" because he felt that his science was 100% correct. First he hired Tzachi Bar to consult, the inventor of PCR mathematical algorithms used in all PCR devices at that time world wide, but Bar could not help him. I happened to be the owner's neighbor. He knew that I was a computer scientist, so he took his final chance with me. Within 3 months I made a number of discoveries that validated the owner's science and enabled them to pass the FDA trials. In spite of my technical success, for commercial reasons beyond the scope of my short article, they were forced to close down their PCR business unit; therefore my threshold algorithm was never patented.

1. Initially Bar and the company's chief microbiologist gave me a 2 week crash course in the fields of microbiology and genetics that they felt I would need for my work.

2. My first task was to generate amplified graphs of all 800 samples, and to study them. Note that every sample had a PCR result, and an associated "gold standard" Petri dish result.

3. My second task was to carefully read the manual of the PCR device. I noted that the company's junior microbiologist who was responsible for administering the hospital tests had used an incorrect protocol for configuring the PCR devices. The 3 control samples that every batch contains were placed in incorrect test tube slots. Therefore all test results were nonsensical!

4. Even though the samples had been thrown away weeks before I arrived, fortunately they had saved the raw data from the PCR devices, that allowed me to reconstruct the Bar-Tichopad algorithm. The new results were better, but still hardly good enough for the FDA that required 80% accuracy.

5. I noted that tests from the pure laboratory colonies of MRSA, with extremely high concentrations never to be encountered in a patient sample, all failed. This indicated to me that there was a flaw in the industry standard Bar-Tichopad algorithm.

6. Secondly I noted that many tests with negative PCR results, in spite of the positive Petri results, had random graphs instead of the smooth bioassay sigmoidal shaped curve of the logistic function that Bar-Tichopad expected. After discussing the matter with Bar and the senior microbiologist, this indicated that the graphs were statistically noisy due to PCR inhibition. Therefore the company's preliminary chemistry did not yet filter out nasal impurities that mature chemistry was supposed to do. Maybe we had to "throw in the towel", i.e. to give up?

7. So I put on my "thinking cap", and discovered a completely new algorithm that was much better than the Bar-Tsichopad algorithm.

8. I discovered a much more accurate and simple way to normalize the bioassay curve and to remove systematic noise, by noting that the "systematic" noise and the linear rise in the signal of the negative control sample precisely matched the patient samples (from the same batch). Therefore my simple normalization solution was to subtract the negative control sample from the patient samples.

9. Both Bar and the senior microbiologist agreed with me that inhibition never increases the PCR signal. Therefore I used an alternative AI threshold test, instead of the Bar-Tichopad test that was based upon advanced mathematical functional analysis to calculate the Ct of the assay.

10. I split the patient samples in half. For the control half, I used the single maximum signal from each sample. I recorded minimum PCR signal that indicated a positive Petri result. And similarly I recorded the maximum PCR signal indicated a negative Petri result.

11. I used the other half of the patient samples to test my new threshold algorithm. My predictions were 95% accurate in spite of the high degree of inhibition found in the preliminary chemistry!

    • The explanation for the minor inaccuracy was some results were in the "gray" region where there was an overlap between the minimum PCR signal to indicate a positive result, and the maximum PCR signal to indicate a negative result.

12. My threshold algorithm won a MRSA "shoot out" at the world famous UK St Georges medical school hospital against competing PCR kits from the huge international pharmaceutical companies!

1. Most of my work at NDS was doing software security research including occasional code security audits.

2. I was one of the first security researchers in the world to prove that the ubiquitous virtual machine packages, e.g. VMWare and VirtualBox, could break simple DRM protection schemes like date restrictions or replay count.

3. I showed how X64 virtualization hardware could be used together with QEMU to break the software random number generator (RNG). This was a very critical attack because the fundamental security assumption was that each client PC had a worldwide unique cryptographic "nonce". But if confederate clients could share their nonces on their own trivial web server then a single license could be shared by all members of the confederacy. At that time, c. 2007, the cycle counter instruction RDTSC was easily subverted by the virtualization technology. After I left the company, since 2012 the CPU has a hardware RNG instruction RDRAND which is a much safer instruction from the perspective of security.

4. I invited outside security researchers to give lectures and seminars to in-house developers on state-of-the-art security techniques. Based upon these lectures I developed an obfuscated FORTH-like compiler that was extremely difficult to reverse engineer.

5. In 2007 NDS was invited by the Chinese government CCTV system to protect the 2008 Beijing Olympics TV feed. I "almost" won the contract. The Chinese government did not want Microsoft to be involved in the bidding because nearly 100% of servers and client PCs had stolen operating system licenses which could easily be revealed when Microsoft installed the protection software. At time the Olympic TV feed was owned by a Microsoft company MSNBC. Eventually Microsoft agreed not to sue China for the stolen operating system licenses, and they offered the protection package for free so they won the contract.

6. The Israeli satellite TV operators had their feed stolen by Israeli expats in the US, and more massively in the Palestinian areas. I showed how to it was possible to easily technically stop these thefts. For reasons that are still not clear to me, the operators showed no interest in stopping these thefts.

7. My first job at NDS was as a quality assurance (QA) contractor. I built a tester and simulator for the NDS satellite software. I designed a domain specific language (DSL) in TCL to do this task. After my analysis of their software, I concluded that there were critical flaws in its design. I was quite knowledgeable in VAX/VMS O/S internals. The junior VP in charge of the project refused to believe that a "mere QA guy" could have such knowledge, so I built a graduated test program that blew his (virtual) satellite out of the sky. Afterwards my software was installed on every developer's desktop. Before checking in software into their version control system, it became standard operating procedure to run a 10 minute test prior to check-in.

8. I worked with NDS' QA department to analyze their bug reports, and concluded that nearly 50% of their software effort was bug fixes. And they had more than 1000 software developers! I worked with the QA department in order to implement a program to greatly reduce bugs. I recall that their biggest problem was lazy software builds that often contained tens of thousands of warnings. My most important improvement was insisting on zero warnings, or adding explicit compiler approval of any warning to be explicitly allowed.

1. I designed an extremely efficient network testing laboratory.

2. By selecting 24-port programmable layer-2 switches for each of the PC's 4x100 MB Ethernet ports, each PC was able to control 96 cable modems during low speed ping tests, whereas previously each PC could only control 4 modems (i.e. one per Ethernet port), which resulted in massive (24x) cost savings through the reduction of PCs and their associated electrical infrastructure, floor space, and air conditioning.

3. For high speed testing at 8 MB per modem, each PC's Ethernet port could only support 12 modems; but the programmable switches could be dynamically configured to quickly open and close ports.

4. I Implemented automated control of the lab in TCL.

5. Instead of implementing speed tests with Cisco's network utilities which relied upon a binary search algorithm, initially I wrote a program to implement a Fibonacci search which was a significant improvement. Subsequently I wrote a steepest descent search which was 10x more efficient!

1. I invented a software system that allowed the blind to "see" and to understand computer images, especially maps and mathematical functions, using a

   a. standard PC or smartphone web browser

   b. the device's builtin speaker

   c. ideally a consumer grade graphics tablet and stylus (e.g. Wacom Bamboo ~$50)

   d. and optionally, but less preferably, with the device's builtin mouse

2. The software heavily relied upon the builtin standard vector graphics (SVG) capability of all modern web browsers (since 1999).

   a. SVG is an XML variant.

   b. SVG returns the position and color at the cursor.

   c. Unlike JPG or PNG pixelated images, SVG has the ability to smoothly zoom in or zoom out of vector images.

3. The basic concept can be understood by using an example image of a circle.

   a. Let the display be black, except for the perimeter of the circle which is a few pixels wide and which is colored white.

   b. In the simple case where the user's stylus hovers over a white pixel, a sound is played, but hovering over a black pixel yields no sound.

   c. Blind users prefer a graphics tablet to a mouse because blind users still have hand-eye (or actually mind-eye) coordination, so they can easy navigate around the tablet. Mice have the problem that the cursor gets stuck at the edge of the display when you scroll beyond the edge. It is possible to provide sonic cues to ameliorate this problem, but using a tablet and stylus is much easier.

   d. Divide the screen into a grid of 96x96 rectangles, or equivalently 8x8 12-tone chromatic octaves. Let the horizontal (x) axis be represented by a piano, and the vertical (y) axis be represented by a flute. Instead of playing the same sound for all white pixel positions, play the xy note combination in the grid position where the cursor is located.

   e. If we would use two intersecting circles, say one white and blue, we could use different instrument combinations to represent the colors, and/or we could use the keyboard or click on the stylus to query which circle we are touching, where the application will provide a text-to-speech response.

4. Images need to be prepared offline. But in the case of maps, most of which are already designed using XML variants, it is possible to programmatically automate their preparation.

5. I applied for and was awarded a large matching grant from the EU in the field of accessibility for the blind in order to productize my work, where the funds would be administered by the office of Israel's Chief Scientist. Unfortunately my employer was having a history of financial problems, so they decided to liquidate.

1. The company's FPGA hardware was streamlined to handle calibrating/aiming the optical equipment. It had no CPU, and minimal configuration I/O ports.

2. I selected an external interface card, with builtin Java support, in order to implement a basic SNMP agent.

3. I built a basic HTTP SNMP NMS server.

1. I invented a hybrid IP system for the modems where a modem had separate IP addresses for upstream (telephone dial-up) and downstream (RF). The invention took advantage of the fact that cable operator also operated the upstream dial-up network, so all the action took place by dynamically manipulating the edge router's arp table at modem login.

2. I designed the company's SNMP NMS offline client using a GUI NMS client tool kit with TCL macros, and the embedded system agent for the modem and router in C.

3. I invented the router's embedded arp table using an extremely efficient FIFO hash table in C that used no dynamic memory allocation.

4. I designed an embedded remotely accessible and secure debugger for the router in FORTH wrapped in C.

1. The novelty of this port was that the GCC model assumes a small finite number of special purpose registers, while this FORTH-like stack hardware could be considered to contain an infinite number of registers, or alternatively no registers at all.

1. I designed a domain specific language (DSL) for controlling an interferometer-like device that moved along an XY jig. I implemented the DSL in TCL running under Windows NT.

2. The most challenging part of the project was making visual sense of the raw "cloud" output of millions of XYZ points. I used the OpenGL C API about a year before they had published their own TCL interface. I developed a tool kit in order to allow the end user to specify what graphics primitives he should use to analyze the different regions of the object being scanned. In my development environment, I used to scan a tooth that I called "Timmy". The end result looked like an alpine environment, where the higher parts were colored white, the middle levels were green, and the lower levels were blue, etc.

1. Elop was a primary subcontractor for the BlackHawk helicopter missile fire control system for the US company LORAL who was the main contractor for the helicopter (which was acquired by Lockheed Martin). They had an acceptance testing manual that specified over 1000 tests that the fire control system must pass. There were about 10 GPIB interface hardware devices attached to the software. Unsupervised automated tests would have to run for up to 4 days at a time. Test results would be sent to a log file, and the app had GUI dashboard to show its current status. The underlying system would be implemented in C. The laboratory computers would be running MS-DOS.

2. The key to the success of this project was my design of a domain specific language (DSL) to formally specify each of the tests. Also the language would have to be easy enough to use by the Elop system engineer, who was not a professional programmer, and would have to program many ad hoc tests on his own. I designed the DSL to be a lightweight version of BASIC along with plugin drivers for the specialized test hardware, along with the main device under test. I used lex and yacc to design the language.

3. The system worked as planned, unattended for up to 4 days at time with no memory leaks.

1. DSPG designed CPU micro-controllers that supported DSP functionality. When I joined them they were working on their original PINE chip. They were a VLSI "fabless" design center. After finishing their designs, they had them manufactured by a real physical "fab". At that time it could take up to 6 months for the fab to manufacture the physical chip. Design flaws would be horrendously expensive. And DSPG designed the application software that ran on their chips. At that time they designed the hardware and software internals for consumer telephone answering machines.

2. VLSI software simulations ran extremely slowly because they simulated the low level transistor details of their circuitry.

3. My job was (1) to design a clock accurate simulator that would run about 100x faster than the VLSI simulator, and (2) to supply an assembler and C compiler that could be used to test software applications months before the fab manufactured the physical chip.

4. At that time the first release of QEMU would be about 15 years away, and the GCC tool chain was not yet mature, i.e. pre 2.95, so I had to design my own assembler, simulator, linker, compiler, and debugger, for an early version of Microsoft Windows.

5. The key to the success of this project was my design of a domain specific language (DSL) to formally describe each one of the CPU's opcodes, and most important to recognize when an instruction sequence would cause the pipeline to "stall". We built the DSL using lex and yacc. At that time it was not yet common industry practice that CPU designers could automatically dynamically insert delays into the instruction pipeline. It was the job of the application programmer (or the compiler) to automatically insert these delays. My DSL included an easy to specify language that detected stall conditions. Without this stall detection feature it was impossible for us to develop the assembler in a timely fashion, because in the early stages of the design, the VLSI architects made major changes to the stall conditions almost daily. Therefore our manually coded stall condition analyzer had to constantly be rewritten. But once we implemented this feature, we could generate an updated assembler almost immediately, i.e. within a hour or two.

6. Another very important feature was that when debugging an application we could programmatically simulate access to the I/O ports. Still more than 15 years after the first release of QEMU, i.e. 2025, this is not yet a builtin feature of state-of-the art QEMU simulators.

7. The system worked as planned. Especially important is that application developers were able to supply working debugged applications months before the physical chip became available.

1. Iscar's Matkash plant in Tefen in northern Israel was an uber hi-tech factory that manufactured hundreds of different small cutting blades according to different chemical compositions and sizes via a sintering process. Typically the blades were bonded to steel materials, e.g. a circular saw.

2. The plant was totally automated. Human intervention was required in the event of maintenance or an accident.

3. The plant included:

   • various types of workstations that had multiple stands where parts and raw materials were placed, and the end product was removed
   • robotic arms automatically inserted parts and raw materials into the station, and removed the end product
   • robotic automatically guided vehicles delivered and removed pallets from the workstations to the correct stand, and moved them to the conveyor system or to the storage area
   • some pallets were transported by conveyor
   • some pallets were placed on stacks
   • pallets were temporarily stored in a storage area made up of hundreds of stands
   • work-in-progress parts that were stored for too long had to oiled in order to prevent rust
   • tools that required maintenance, e.g. cutting tools, recorded their consumption before being sent for repair (e.g. sharpening)

4. My job and that of my partner was to automatically orchestrate the plant via S/W. We had a powerful VAX/VMS computer at our disposal with a relational database. Our liaison from DEC insisted that the main programming language be Pascal.

5. We came to the project with no knowledge of factory automation. So we started with month long mentoring from an industrial engineer who did.

6. Our solution was to design a domain specific language (DSL) that described every single object (i.e. a few hundred 100) in the factory's "object kingdom", and how they interacted with one another. The DSL had to configurable by the factory engineer who was not a software engineer, while the clerical staff required a GUI window into the DSL for making on-the-fly configurations and viewing the status of the factory.

7. It became immediately obvious that the S/W required object oriented techniques to implement. At that time object oriented programming (OOP) was just being developed in research/university settings. The first version of C++ was just released, and SNOBOL was an OOP research prototype. There was no Internet yet at that time, but literature was available in the Hebrew Univ computer science library. Recall that we had a hard requirement to use the procedural Pascal language,

8. VAX/VMS had a command line utility for designing command "ensembles" which could be executed via callbacks to a compilable language, e.g. Pascal. We used these ensembles to define every type of object, along with their attributes, supported by the our DSL. Today (2025), 30 years later, I would use XML instead (which had not yet been invented).

9. There were tens of thousands object instances stored in a database on disk - including their configuration and current status. The database regularly stored status updates. The database was constantly scanned in order to implement the next task that our scheduler required. In the event that the main computer shut down, either expectedly or unexpectedly, the database allowed for a smooth restart/recovery.

10. After about a year, we implemented a working factory!

1. The company was a pioneer in the 3D printing industry, originally known as "stereo lithography" or "solid ground curing". Their "Solider" device weighed 4.5 ton and was the size of a half-size shipping container. The parts were made from a polymer that was heated into a liquid, and the holes were filled with liquid wax. When a part cooled it became solid, while the wax melts in hot water and drains away.

2. I developed a VAX/VMS printer driver by considering each layer of the printer output as if it were a separate page.

3. Invented a lightweight source control system by taking advantage of the VAX/VMS DCL file generation and logical file name (i.e. alias) features.

4. I designed a DSL for designing printer subassemblies by taking advantage of a VAX/VMS command line utility for defining command "ensembles".

5. I architected a Motif user interface (UX) that manipulated the ensembles.

6. I was the company's VAX/VMS system admin.

1. At that time, 1989, speech-to-text systems were not yet technically feasible or else exorbitantly expensive.

2. Our hardware solution was based upon attaching a telescopically enhanced light pen to a then ubiquitous CRT display, where the light pen's select button was replaced with a sip-and-puff accessibility switch. Normally a light pen needed to be ~1 cm. from the display, but with our military grade optical enhancement it could be ~80 cm. away.

3. My initial software invention overlaid half of the display with a virtual keyboard, where the light pen was used to select a key. The final solution used an "expert mode" where a virtual hidden keyboard covered 100% of the display, but a key popped up only when the light pen hovered over an individual key.

4. The first user of the device was Shulamit Gabai who was stricken with polio in all of her limbs by the Or Akiva municipal disaster where sewage leaked into the clean water system. She was able to use the device to type 30 characters per minute, and thus was able to become an editor for a book publisher.

5. For a new learning experience, I wrote the software in Prolog.

1. I designed a domain specific language (DSL) to annotate an Auto-CAD leather sewing pattern with "road signs". These signs were associated with sewing commands that must be followed in real-time.

2. Since leather is a natural fabric, no pieces are identical with respect to size, thickness, and color. An expert human sewing machine operator will take these differences into account. Therefore the robot required a live video feed which had to be analyzed in real time.

3. A high speed sewing robot can execute a few thousand stitches per minute. On account of torque, it takes a few seconds to change speed. Making mistakes may cause the machine to make hundreds of unnecessary stitches which could seriously damage the expensive fabric.

4. Among other things, the "road" signs specify minimum and maximum speeds, the sizes of the minimum and maximum overlapping regions, the pattern matching algorithm to be used depending upon the texture and color of the leather, etc.

5. For example speed is a function of the angular changes, and the complexity of the of the matching algorithm.

1. I was the first public interest intervenor in the history of the OEB to be awarded costs - at the suggestion of the OEB!

2. In a nutshell marginal cost pricing is also referred to as "congestion pricing". The majority of consumers understand that the price for road tolls or parking lots or tourism facilities, etc., should be much higher during peak usage periods. The same principle holds true for electric power generation. Therefore it was always recommended to activate electric water boilers in the middle of the night (and similarly today when charging electric vehicles), but the flat rate system provided no price incentive to do so. Generation "base" stations that run 24x7, e.g. nuclear, produce less expensive electricity than "intermediate" coal station designed to run 8 hours a day, and there are huge differences in the price of electricity from gas turbines designed to run during peak loads that occur a few hundred hours per year (e.g. during extreme weather conditions). But for the previous 50 years consumers were used to flat rates.

3. Due to intense political pressure from the mineral smelting industry, who relied upon subsidized electricity prices and who directly employed tens of thousands of people and who threatened to leave the province if the subsidies were removed, the Ontario government caved in to the pressure, and forced the public electric utility, then called Ontario Hydro, to withdraw their case after the hearings had already begun. I became the primary intervenor at the hearings to present the case for marginal cost pricing.

4. I published a full page op-ed about the hearings in Canada's then newspaper of record The Globe and Mail. In that article I proposed to immediately economically rationalize electricity prices, while simultaneously granting the smelting industry with gradually decreasing annual subsidies to help them make the transition to the new pricing scheme. My proposal was a political "non-starter" because the politicians could never sell to the general public granting explicit subsidies to some of the wealthiest corporations in the province, even though it was clear that subsidized electric prices fostered general growth of electric power consumption with the concomitant outrageous financial consequences associated with expanding generation capacity (i.e. at the time building new nuclear power stations). Instead the politicians preferred to treat the general public as fools by arguing that maintaining the status quo of flat pricing (and even worse by granting discounts to industrial consumers) did not constitute a subsidy.

5. I initially learned about the hearings from a course in my MBA program (1976) when I complained to the Ontario Hydro economic team (beside the Univ campus) about the mediocre B grade my professor gave me on my term paper. At the same time I had my discussions with the economic team, the government ordered them to withdraw their proposal. They suggested to me that I join the hearings as a public interest intervenor to advocate marginal cost pricing in their stead, and that they would give me behind the scenes technical support. I agreed to their proposal. I would have the exact same legal standing as the smelting industry because I paid a shared electric bill of about $25 a month!

6. This job was a formative learning experience for me that subsequently effected my whole life because I learned that a single individual can effectively stand up to the corruption of large business and government. With perfect hindsight, it was clearly a case of Divine intervention (Hebrew: Hashgacha Pratit). Years later in my life in Israel, I became involved in a number of community service projects where I showed that a single individual can make a difference and successfully push back against government corruption. (See future articles in my web site on my community service).

Note the FOSS license at the beginning of this document.

1. Crypto: Adler-32 Checksum Redux ¶

Two commonly used non-cryptographic checksum algorithms are Adler-32 and CRC-32. Adler-32 is trivial and much faster to calculate on account of the simplicity of its main loop.

#include <assert.h>
#include <stdint.h>

__attribute__((__pure__))
uint32_t original_adler32(const int32_t n, const uint8_t *restrict arr)
{
    static const int32_t MAX_N = 5803L; 

    if (n == 0) return 0;
    assert(n > 0 && n <= MAX_N);
    assert(arr != 0);

    uint32_t sum = 0;
    // efficient main loop
    for(int32_t i = 0; i < n; ++i) { sum += arr[i] * (i+1); }
    return sum;
}

Unlike CRC-32, the major flaw with Adler-32 is its lack of "spread" in the domain of sum. Clearly short messages will have too small a spread, which results in many collisions. However it is very easy to correct this problem by using a constant multiplier k which is a function of n. We still retain the speed and simplicity of the original algorithm. This algorithm is quite useful as an extremely fast non-cryptographic hash function.

#include <assert.h>
#include <stdint.h>

uint32_t ayb_adler32(const int32_t n, int32_t * k_ptr, const uint8_t *restrict arr)
{
    // constants calculated off-line
    static const int32_t MAX_K = 16843009L;
    static const int32_t MAX_N = 5803L;
    
    if (n == 0) return 0;
    assert(n > 0 && n <= MAX_N);
    assert(arr != 0);

    int32_t k = 0;
    
    if (k_ptr != 0) {
        k = *k_ptr;
        assert(k >= 0 && k <= MAX_K);
    }
    
    if (k == 0) {
        // If the caller does not pass a non-zero value for `k` then dynamically calculate the
        // optimal value for him, and provide him the opportunity that the next time he makes a
        // call with the same message length then he can recall this value, and thus avoid
        // repeating the calculation.
        
        // Calculate the optimal multiplier that gives the maximum spread.
        // Recall that the sum of an arithmetic sequence is: n*(n+1)/2.
        // In the extreme case every element of the array is 255,
        // therefore the largest possible sum is: (n*(n+1)/2)*255*k <= 0xffffffff
        
        k = 0xffffffffUL / ((((uint32_t)n*((uint32_t)n+1UL))/2UL)*255UL);
        if ((k & 1UL) == 0) { --k; } // force k to be odd
        
        if (k_ptr != 0) { *k_ptr = k; } // return optimal `k`
    }
    
    uint32_t sum = 0;
    // main loop is exactly the same as the original
    for(int32_t i = 0; i < n; ++i) { sum += arr[i] * (i+1); }
    return sum * k;
}

2. Crypto: Lightweight Key Wrapper ¶

This algorithm wraps a 32-bit number with a 64-bit key and a pseudo-random 32-bit number; and where the ALU can process 128-bit numbers then we can wrap a 64-bit number with a 128-bit key and a pseudo-random 64-bit number. The random number can be generated on-the-fly in a local random number generator. The algorithm is extremely fast. It is implemented in a few assembly instructions. It can be executed inline. Therefore it is quite useful for obfuscation.

#include <stdint.h>

inline static
uint64_t ayb_wrap32(uint64_t key, uint32_t x, uint32_t r)
{
    typedef struct {uint32_t rc; uint32_t xr;} package_t;
    union {uint64_t wrapper; package_t package;} un;
  
    un.package.rc = ~r;
    un.package.xr = x ^ r;
    un.wrapper ^= key;
    return un.wrapper; 
}

inline static
uint32_t ayb_unwrap32(uint64_t key, uint64_t wrapper)
{
    typedef struct {uint32_t rc; uint32_t xr;} package_t;
    union {uint64_t wrapper; package_t package;} un;

    un.wrapper = wrapper ^ key;
    uint32_t x = un.package.xr ^ ~un.package.rc;
    return x;
}

3. Crypto: Invertible "Cross Hamming Weight" Transformation ¶

Rotating a number by its Hamming weight is a cryptographically weak transformation because (1) the transformation does not change the original Hamming weight, and (2) Hamming weights have a binomial distribution where the weight has an extremely high probability of being in the center of the distribution.

This invention improves these flaws. The transformation flattens the distribution by (1) making the upper and lower half of the number into 2 adjacent N/2-bit binomial distributions, and (2) 75% of the time it changes the original Hamming weight. And it is possible to apply the transformation twice, where the result is 4 adjacent N/4-bit binomial distributions.

#include <assert.h>
#include <stdint.h>

uint32_t rotl32(uint32_t x, int32_t shift) // aka circular shift left
{
    const int32_t INT_BITS = sizeof(typeof(x))*8;
    assert(shift >= 0 && shift <= INT_BITS);
    if (shift && shift < INT_BITS) {
        x = (x << shift) | (x >> (INT_BITS - shift));
    }
    return x;
}

uint32_t rotr32(uint32_t x, int32_t shift) // aka circular shift right
{
    const int32_t INT_BITS = sizeof(typeof(x))*8;
    assert(shift && shift <= INT_BITS);
    if (shift && shift < INT_BITS) {
        x = (x >> shift) | (x << (INT_BITS - shift));
    }
    return x;
}

uint64_t ayb_xhw64(uint64_t x)
{
    const int32_t HALF_INT_BITS = sizeof(typeof(x))*4;

    const uint32_t lo1 = x;
    const uint32_t lo1_hw = __builtin_popcount(lo1);
    
    const uint32_t hi1 = x >> HALF_INT_BITS;
    const uint32_t hi1_hw = __builtin_popcount(hi1);
    
    const uint32_t lo2 = hi1_hw & 1 ? lo1 : ~lo1;
    const uint32_t lo3 = rotr32(lo2, hi1_hw);
    
    const uint32_t hi2 = lo1_hw & 1 ? ~hi1: hi1;
    const uint32_t hi3 = rotl32(hi2, lo1_hw);
    
    return (uint64_t)lo3 | ((uint64_t)hi3 << HALF_INT_BITS);
}

uint64_t ayb_invert_xhw64(uint64_t x)
{
    return 0; // TBD
}

4. Crypto: Non-invertible Uniformly Distributed FFT Hamming Weight ¶

This algorithm calculates a value in the same range as classic Hamming weights, but the distribution is "nearly" uniformly distributed except for minor perturbations. For example a 32-bit number returns a weight in the range [0,32]. The algorithm is highly non-linear, i.e. cryptographically "bent".

#include <stdint.h>

int32_t ayb_squeeze_hw32(uint32_t x, const int32_t width) 
{
    const typeof(x) MASK = (1UL << width) - 1UL;
    const typeof(x) HALF = 1UL << (width-1L);
    int32_t sum = 0;    
    
    for(; x; x >>= width) {
        const int32_t squeezed_bit = ((x & MASK) >= HALF) ? 1 : 0;
        sum += squeezed_bit; 
    }
    
    return sum;
}

int32_t ayb_fft_hw32(const uint32_t x)
{
    const int32_t WIDTH = sizeof(typeof(x)) * 8;
    const int32_t MAX_WIDTH = WIDTH/4;

    int32_t sum = (WIDTH <= 32) ? __builtin_popcount(x) : \
        __builtin_popcountll(x);
    
    for (int32_t width = 2; width <= MAX_WIDTH; width *= 2) {
        sum += width * ayb_squeeze_hw32(x, width);
    }

    return sum % (WIDTH+1);
}

5. Container: Binary Expandable Hash Table ¶

1. Typically the maximum number of entries in a hash table is a prime number, while my algorithm uses 2**N entries.

2. Typically when expanding the size of a hash table, all entries must be rehashed, while my algorithm does not require any rehashing.

3. The search time to find a free storage entry will be exactly O(1)!

4. For a table that is up to 75% full, the search time to find a unique key will on average be less than O(2).

5. Typically hash tables are "sparse", i.e. they contain many empty entries, because the same data structure is used to store both the data associated with the keys, and to search/update keys. Part of my "secret sauce" is that my algorithm uses 2 separate data structures which greatly minimizes sparseness. One structure defines the maximum number of keys, while the second structure defines the maximum number of data entries.

6. Where the operating system supports the Linux vmalloc or the Win32 VirtualAlloc allocators, then it is possible to allocate large memory regions with virtually linear address spaces but are composed of physically non-contiguous pages. My algorithm can take advantage of these allocators to further reduce sparseness, and not to move the data associated with existing keys when the table is expanded.

C source code: TBD.

6. Embedded Systems: Dynamically Loadable FLASH Configuration Files Larger Than RAM ¶

On embedded systems with limited RAM, it is not possible to load large configuration files into RAM, and it is normally a security risk to parse the configuration file when dynamically loading it regardless of its size. My invention allows the use of an off-line pre-parsed configuration file into object data format without any executable code. It can be dynamically loaded into FLASH memory at an address defined at load time where (1) the system architect must have mapped the FLASH memory accordingly, (2) the C structure of object file must be recognized by the control program, and (3) it is extremely difficult (although not impossible) to modify the configuration for the duration of the load.

The format can be designed to support variable sized memory regions in a way that can be legally supported by the Misra C mandated rules for safe programming design in industries such as automotive, aircraft, and medical equipment, etc. Normally Misra C forbids the use of variable sized data structures. For example, Misra C rules normally force developers to allocate space for sparse arrays, so that an array of file names would require enough space in each array element to support the longest possible file name. However my invention enables the array elements to be stored in a packed heap in FLASH, so that each array element is a pointer into the heap.

I show how the off-line pre-parser can be implemented without any executable C code by taking advantage of the GCC's designated initializer feature along with Jinja2 preprocessing.

C source code: TBD.

7. C: Named Function Arguments via Designated Initializers ¶

Designated initializers is an old GCC extension since C99. We can take advantage of this feature in order to implement named function arguments.

#include <stdio.h>

#define CALL(F,...)  F((F##_args_t){__VA_ARGS__})
#define P(...)  __VA_ARGS__  // partials, somewhat like python partial functions
#define CALLP(F,WRAPPED_PARTIALS,...) F((F##_args_t) \
        {P WRAPPED_PARTIALS,##__VA_ARGS__})

typedef struct { int a, b, c; } myfunc_args_t;
int myfunc(myfunc_args_t args) { return args.a + args.b + args.c; }

int main()
{
    // Designated initializer defaults are 0.
    // Where there are duplicate initializers, last one wins.
    // Compiler defines structure of `myfunc_args_t` in RAM,
    // so there is no dynamic allocation of memory.
    
    int retc1 = CALL(myfunc, .c=1, .b=2);
    int retc2 = CALLP(myfunc, (.c=1, .b=2), .a=3);
    
    printf("%d,%d\n",retc1, retc2);
    return 0;
}

8. Accessibility: Generic Dyslexic Font ¶

I invented a scheme to modify existing fonts so that a dyslexic can easily read them by mimicking the concept how computer vision programs can decipher QR codes regardless of how they are rotated. You should note that in QR codes there are 3 solid black squares in the top-left, top-right, and bottom-left corners, but not in the bottom-right corner. My invention pads the left and right margins of each character in the font, allowing space for two vertical strips in each margin. Each character will have the same size padding. In the middle of the inner left strip, I add a diacritical dot. Now the dyslexic reader needs to follow a single rule, namely to note that a validly oriented character has a dot in its inner left margin. The margins have to be wide enough, so that the reader can recognize the spacing between a sequence of characters.

2022: Introduction To Cybersecurity, at Jerusalem College Of Technology (JCT/Machon Lev).

• The students and faculty loved my lectures because I regularly emphasized what course materials would be critical for their future professional work. However they extremely disliked my tutorials because I insisted that it was pedagogically critical to work out the difficult problems on their own. The majority of the students wanted me to "spoon feed" them. Often I stayed for more than one hour after class to help them.

~2018: At a family function, I taught a smart (but not genius) girl in 2nd grade, exponents, logarithms, and hexadecimal arithmetic with the help of her smartphone calculator, over a period of ~60 minutes.

~2016: I volunteered to teach 3 Units of Mathematics for Israeli Secondary School Matriculation (= Bagrut) to smart girls who had no background in math, at an Ulpana in Ra'anana. They all passed!

~2014: "Kinesiologically" I taught my grandson, then 10 years old who has a learning disability, how to multiply using floor tiles and masking tape. I knew he was successful when he announced that "4x2" is the same as "2x4".

~2014-2022: I taught most of my young grandchildren Python Turtle Graphics when they were 10-12 years old.

~1996: Windows NT Internals, at the Sivan Training Center in Jerusalem.

~1987: Database Theory, at the Michlelet Beit Vegan Teacher's College in Jerusalem. I was a substitute teacher for 3 months.

I highly recommend that high school students who learn trigonometry should also learn the much simpler base-60 rational trigonometry used by the ancient Akkadians and Babylonians.

1. Born: 1957 Canada.
2. Aliyah (English: immigration to Israel): 1983.
   • My triple great grandfather, Rav Aharon Visanska 1809-1893, was born in a rural region of Augustow Poland. He was a disciple of the Vilna Gaon (Hebrew: Gra). As a young adult he resided in Yerushalayim (English: Jerusalem). He emigrated to Michigan where he raised his family and became a community rabbi. He returned to Yerushalayim where he died and was buried on the Mount of Olives (Hebrew: Har HaZeitim). His granddaughter Rachel 1874-1919, my great grandmother, was born in Michigan. She married a Canadian immigrant from Poland, Yechiel Michael 1872-1926, my great grandfather, who was born in the same Polish community as Rav Aharon's. Their eldest son Hershel Tzvi 1896-1977, my grandfather, was born in Ontario. He fought in WW I in the Jewish Legion in Turkey and later in Palestine under General Allenby. Hershel Tzvi returned to Ontario where I was eventually born.
3. Married: 1978, 2 boys + 2 girls, all married with many grandchildren, all of whom live in Eretz Yisrael (English: the Land of Israel).
   • Since the Islamofascist Hamas barbarian massacre on Simchat Torah 5784 (aka Oct. 7, 2023), both of my sons spent about 6 months in the IDF, and at the beginning of March 2025 they were both called up again for about 75 days of reserve duty (Hebrew: Milu'im).
4. Religious Beliefs: I am a God-fearing Torah observant Jew and Zionist.
   • My belief in God, Torah, and Israel has always been the core belief of the Jews since Avraham Avinu (English: our forefather Abraham) established Judaism c. 3800 years ago.
5. IDF Reserves 1988-2001: I was a combat infantry sergeant, where I served in the Central Command (Hebrew: Pikud HaMerkaz) in the Jordan Valley.
   • Exceptionally I often acted in the role of deputy company commander (Hebrew: Samap) even though I was a Shlav Betnik (English: those first drafted over age 26) with only 4 months of basic training. Considering that the IDF intended to send me to a combat infantry unit for the whole period of my 13 years of reserve duty, about 2/3 of my basic training was a complete waste of time, e.g. kitchen duty, gardening duty, and guard duty, instead of primarily focusing on combat skills.
6. Sport: I still engage in regular vigorous exercise at a gym for 90 min. 3x per week - cardio and heavy weights. When I was younger I engaged in Judo, freestyle wrestling, and Tai Chi.
7. Meditation (aka Mindfulness): I developed my own meditation technique based upon the principle of sympathetic harmonics. Within minutes I can lower my pulse to 48-54 bpm.
   • I can quickly teach this technique to others with just a clock that has a sweep second hand, and ideally by using a high speed metronome app, with combined audio and visual feedback, that supports 300 beats per min., i.e. 5 Hz the brain's theta wave frequency. I can feel when I do intensive concentrative work, I naturally enter this state. I would like to purchase the moderately priced (~$130) NeuroSky device in order to engage in further experiments. (Warning the product has mixed customer reviews. It is absolutely critical when purchasing this device that you select the one appropriate to your local AC electricity source, i.e. 110V or 220V).
8. Hobbies: I play classical guitar (currently rusty). I teach the use of music composition software to my musically inclined children (one of whom is a concert cellist) and grandchildren. For example see this beautiful lilypond score, its automatically generated mp3 output, and the abc music notation which generated the above score and mp3 file. Some children may prefer the musescore app that has a GUI.
9. Android Phone & PC Windows and Linux Repairs: For family and close friends.
10. My computer equipment:
    • PC: Lenovo Thinkpad E14 Gen 6 (Intel, 14 inch): i5 CPU, 32GB RAM, 1TB SSD, Xubuntu 24.04; industrial grade, chose an i5 to prevent CPU overheating while it still has more than enough H/W threads, native Linux support, price is reasonable
    • 31.5 Inch 1920x1080 Display: Lenovo "D32-40"; huge ultra-readable "business class" display for an outstanding low price precisely because it does not have the latest "home theater" or "gamer" specs which I really don't need
    • Mechanical Backlight Gamer's Keyboard: Redragon Andromedia K558R-1; I can "touch type" so a mechanical keyboard is a necessity, bought locally so dual-language keyboard has builtin backlighting support, price is good
    • Erogonomic Trackball Mouse: Logitech "Ergo M575"; avoids shoulder and carpal tunnel injuries, excellent price
    • Smartphone: Samsung Galaxy A34: 6GB RAM, 128GB FLASH, Android 14; excellent budget phone with Knox security

I designed this novel document format in (FOSS) pandoc markdown under Ubuntu. I used (FOSS) Pyexpander for macro preprocessing. The following two formats were automatically generated from the same markdown source file: (1) HTML, and (2) PDF (using the wkhtmltopdf plugin). As is standard in the hi-tech industry, the mandatory PDF format incorporates a single line for the employer name, and a short headline about the details of the task. Superficially the HTML version mimics the identical format. The PDF headline links to the HTML version, where the HTML version uses the HTML <details> tag (typically preceded by the right pointing triangle symbol "▸") to optionally enable viewing the full description of the task. This design is similar to a web news site with a listing of headlines that enables clicking to access details. The advantage of this scheme is that most HR departments forbid their readers from contacting a candidate for more details without first conducting an official interview which is typically a major formal process. My scheme short circuits this dilemma to the advantage of both the reader and the candidate. See my source code at: https://github.com/avraham-bernstein/avraham-bernstein.github.io/tree/master/cv.