dhx · HackerLangs

3 giorni fadiscuss

If demographics are a problem for chipmaking in China, then it's good to compare against key chipmaking countries.

To compare, 2024 (UN) fertility rates (highest-lowest):[1]

  US:     1.62
  Japan:  1.23
  China:  1.02
  ROC:    0.86
  ROK:    0.75 (where an increase to 0.8 in 2025 was cause for celebration, as is a predicted increase to 0.85 by mid 2026)[2]

Alternatively (and perhaps accounting for migration etc), UN 2024 forecasts population differences in these countries between 2024-2050 as:[3]

  US:    +10%
  Japan: -16%
  China:  -8%
  ROC:    -6%
  ROK:   -12%

[1] https://en.wikipedia.org/wiki/List_of_countries_by_total_fer...

[2] https://www.chosun.com/english/national-en/2026/01/24/IVHGRT...

[3] https://en.wikipedia.org/wiki/List_of_countries_by_past_and_...

dhx

3 giorni fadiscuss

For some recent data, see the diagram "Semiconductor foundry capacity 8" & 12" - by foundry location (in %)" at [1] for a rough idea of kWpm (thousand 300mm equivalent wafer starts per month) for key countries/regions for 2024, 2025 and prediction for 2031. China and ROK are predicted in this report to have the largest overall market share increases to 2031.

For some more detailed data (hard to find it publicly available), also see the OECD report at [2], particularly pages 18 and 20 (as numbered). This report provides a breakdown of ~2024-2025 per-country/per-region capacity by chip type (power, analog, speciality memory, commodity memory, advanced logic, mature logic) and a prediction for pre-country/per-region upcoming capacity increases by chip type.

There are markets within markets of course. China dominates in power electronics which makes senses when you consider even just their domestic demand for electric vehicles and renewable generators. Taiwan dominates in advanced logic and exports pretty much all of it. ROK dominates in commodity memory and also exports pretty much all of it. When you compare populations of China vs. USA, the USA are/will be punching above their weight for analog and advanced logic chips, which is also where the focus of their investment is.

In categories such as power electronics and mature logic which China dominates, labour cost is much more important than categories such as advanced logic where equipment is the overwhelming cost. For this reason you'll find China (and maybe even India if they bother to get into the market) dominate these categories due to lower costs of labour. Traditional competitors in these categories such as Onsemi and STMicroelectronics have been hurting.[3]

It's hard to predict which announced/planned investments will go ahead and be impactful, for various reasons such as utilisation rates of fabs once built. But it'll be particularly and increasingly difficult to predict the future of semiconductor fabrication due to what is happening in China. China has expanded their domestic chip making equipment industry enough to mandate Chinese fabs use at least 50% Chinese equipment.[4] Over 2024 and 2025 the investment from China into chip making equipment was estimated to be 37-42% of global spend, so we're talking about 20% (or maybe higher up to 40%) of global chip making equipment spending not being readily observable.[5]

[1] https://www.yolegroup.com/product/report/status-of-the-semic...

[2] https://www.oecd.org/content/dam/oecd/en/publications/report...

[3] https://www.trendforce.com/news/2025/02/26/news-power-chipma...

[4] https://www.reuters.com/world/china/china-mandates-50-domest...

[5] https://www.semi.org/en/SEMI-Reports-Global-Semiconductor-Eq...

dhx

3 giorni fadiscuss

My key point you are avoiding with personal attacks is:

If I see another computer offer TLS named group 0x0200 (MLKEM512) as introduced by draft-ietf-tls-mlkem, do I have any assurance that the other end I'm communicating with uses constant-time Decaps(sk, ct)?

--

The answer as far as I have presented is NO. TLS named group 0x0200 (MLKEM512) is free to be used for leaky MLKEM implementations that have made no effort to be side channel resistant. The end state for MLKEM-only will be the IANA registry stating TLS named group 0x200 (MLKEM512) is specified in RFCxxxx (draft-ietf-tls-mlkem), and this RFC will refer to FIPS 203 for cryptographic primitives. At no time is side channel resistance in any way guaranteed by either draft-ietf-tls-mlkem or FIPS 203.

The situation for TLS named group 0x0029 (x25519) is different. The IANA registry nominates RFC 8446 as the relevant specification.[1] And RFC 8446 nominates a specification (RFC 7748) which does require implementation of cswap as a measure of side channel resistance.[2][3] So when you trace through the specifications starting from the IANA registry, it is unambiguous that TLS named group 0x0029 should provide at least some degree of side channel resistance. Even for this case, I'd argue the SHOULD would be better as a MUST (with possibility to add another TLS named group specifically for x25519-unsafe without constant-time cswap if anyone cares for it). And I'd also argue that RFC 8446/TLSv1.3 should require (not just suggest or hope) that implementations MUST only use constant time functions when processing ECDHE parameters per s4.2.8.2.[2] TSLv1.3 already requires AEAD use elsewhere to force constant-time processing. It's worth noting TLSv1.3 currently doesn't provide any guarantee about side channel resistance of secp256r1, secp384r1, and secp521r1. TLSv1.3 currently just provides this guarantee for X25519 and X448.

[1] https://www.iana.org/assignments/tls-parameters/tls-paramete...

[2] https://www.rfc-editor.org/info/rfc8446/#section-4.2.8.2

[3] https://www.rfc-editor.org/info/rfc7748/#section-5

dhx

3 giorni fadiscuss

It looks like recent Tenda hardware/firmware is encrypted per below examples, making it harder to audit.

binwalk US_AC10V6.0si_V16.03.62.09_multi_TDE01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x436999A39FECA649

binwalk US_BE12ProV1.0mt_V16.03.66.23_TD01.bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  516           0x204           OpenSSL encryption, salted, salt: 0x81235B7D4130B6AB

The third attempt I tried was unencrypted, and possibly reveals the problem exists on another model this CVE doesn't list as affected:

binwalk US_W18EV2_kf_V16.01.0.20\(4766\)_HighPower\ \(1\).bin

  DECIMAL       HEXADECIMAL     DESCRIPTION
  --------------------------------------------------------------------------------
  64            0x40            uImage header, header size: 64 bytes, header CRC: 0x95335734, created: 2026-06-16 09:09:35, image size: 2159135 bytes, Data Address: 0x80100000, Entry Point: 0x805F41C0, data CRC: 0x5ABEDB00, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Tenda Linux-4.14.90"
  128           0x80            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6947248 bytes
  2159263       0x20F29F        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 8971644 bytes, 847 inodes, blocksize: 1048576 bytes, created: 2026-06-16 08:53:20

Inside is /squashfs-root/webroot_ro/default_ac.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)
  sys.guest.username=guest
  sys.guest.password=Z3Vlc3Q=  (ed: base64 decoded: guest)

And /squashfs-root/webroot_ro/default_router.cfg which offers:

  sys.rzadmin.username=rzadmin
  sys.rzadmin.password=cnphZG1pbg==  (ed: base64 decoded: rzadmin)

From what I can see quickly (I haven't looked hard), "sys.rzadmin.password" is only referenced from the login() function of /bin/httpd in the context of retrieving a value. This value is retrieved and compared before the error message "login err: password is wrong." is emitted. I can't find any other reference to code in any part of the firmware that may allow a user to change the default value of "sys.rzadmin.password".

Also for fun there is a function imsd_upload_log_v1 in /bin/imsd that collects SSIDs, MACs, IP addresses, sys.admin.username, sys.rzadmin.username, timezone, and another function imsd_remote_pwd_get in /bin/imsd that retrieves sys.admin.password. Related library /lib/lubucapi.so also looks like a fun binary to inspect more closely as it contains a command set that seemingly allows either cloud management of Tenda routers and/or remote debugging, and possibly is why imsd_remote_pwd_get exists in /bin/imsd

dhx

3 giorni fadiscuss

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1]

But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance.

The draft MLKEM IKEv2 RFC[2] has the same problem.

Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive:

Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret."

To include side channel resistance, for example:

Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values."

Some further examples of RFCs which do care about specifying side channel resistance:

RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3]

RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4]

(this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance)

[1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4

[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...

[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3

[4] https://www.rfc-editor.org/info/rfc9941/#section-4

dhx

4 giorni fadiscuss

The draft considers FIPS 203 to be normative. Therefore FIPS 203 forms part of this draft. You can't implement this draft without first implementing FIPS 203.

FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.

[1] https://news.ycombinator.com/item?id=48811887

dhx

4 giorni fadiscuss

To point out some positive examples of what RFCs should include:

RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1]

RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)."[2]

By contrast, this proposed RFC for MLKEM provides a single encouragement:

"[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."[3]

It's not even a SHOULD, it's just an encouragement in a non-normative section of the RFC.

When you go to the referred NIST SP 800-227 it then tells you it's all too hard anyway and good luck and have fun figuring it out yourself:

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."[4]

The normative standard FIPS 203[5] which the draft MLKEM RFC relies upon NEVER mentions "side channel", "constant", "timing" or provides any other assistance to implementers on how to securely multiply and/or divide numbers on computers or how to deal with conditional branching. Fair enough it includes a lower case "should" for considering side-channel resistance, but this throwaway comment is inadequate for standardisation.

The main reason it is inadequate is, imagine you're on your Hardened Gentoo or some other uber-geek laptop with the most advanced and thoroughly tested side channel resistant MLKEM client imaginable. You want to access your bank's website that offers MLKEM-only TLS. You don't have any assurance the bank's implementation of MLKEM has implemented any side channel resistance because the RFC they claim to have implemented never required it. If you then extrapolate from historical woes of implementing side channel resistant crypto (ECDSA scalar multiplication for example), it's probably correct to assume someone has, or reasonably could at some point in the future, extract private keys from the bank's side, and thus your expectations of having a secure connection are unmet. This is a standardisation problem because two implementations cannot agree on whether the protocol offers any resistance to side channel leakage to remote adversaries, therefore, what is the security guarantee the two implementations can actually agree upon?

The key missing section of this RFC is perhaps a restriction on its application similar to:

"This standard does not require implementations to consider side-channel attacks. This standard SHOULD NOT be used for protecting data and communications where an adversary may have one or more of: a) physical access to equipment performing cryptographic operations and time and resources necessary to observe physical properties of the equipment (power and signal characteristics, electromagnetic radiation, thermal dissipation), b) ability to execute code on equipment performing cryptographic operations, c) remote access to high-resolution monitoring data of physical properties of equipment performing cryptographic operations, d) ability to observe and/or establish a session to a party using this cryptographic protocol."

Thus it'd only be applicable to low risk environments such as two servers in a government building in separate rooms where an adversary is prevented from conducting a side channel attack by a plethora of other security controls.

[1] https://datatracker.ietf.org/doc/html/rfc5288#section-3

[2] https://datatracker.ietf.org/doc/html/rfc7748#section-5

[3] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[5] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

dhx

4 giorni fadiscuss

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

dhx

4 giorni fadiscuss

Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.

For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.

For example:

FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]

NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]

RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]

A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].

A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...

dhx

4 giorni fadiscuss

To extend on this good point--

DJB is not just a mathematician looking over theoretical equations. He's also an expert in the real world _implementation_ of cryptography where most security failures can be expected to occur.

For some mathematician's brilliant cryptography scheme, how easy would it be for implementers to develop constant time / constant power computer algorithms to avoid side channel leakage? Have these computer algorithms been developed, are they easy to implement securely or are implementers going to continually mess it up?

See [1] and [2] for answers. Summary: Technology is not ready.

[1] https://dl.acm.org/doi/10.1145/3569420

[2] https://dl.acm.org/doi/10.1145/3779208.3785290

dhx

5 giorni fadiscuss

At least in my experience for large retail chains or restaurant chains, hours on their websites are very accurate. I think where Google might benefit from calling to verify hours is, for example, where they've scraped https://schema.org/openingHours from the web page for an independent store, but the website has used an invalid/incorrect format, and some manual human check or clean-up is necessary, but this work would be too time consuming for each of 100,000's of independent stores which exist.

There are cases where a brand might have broken opening hours information such as "Mo- Tu - We 09 00 -4 p m". For alltheplaces.xyz scrapers, a human is often able to make sense of the situation and fix the problem through a few lines of extra code. Contacting the business to get the hours confirmed would only be necessary in very rare cases.

Where it would perhaps make the _most_ sense to contact a business to confirm opening hours is:

1. Ahead of public holidays to confirm planned temporary changes to opening hours. Many brands don't bother to update hours on their websites for such temporary changes, or at least don't list those hours until the week prior, which is usually too late for OSM, ATP, offline maps, etc which would ideally want to know these changes to hours up to a year in advance.

2. To confirm actual dates of permanent store/restaurant closures. Many brands in liquidation tend to fire the website developers (or can't pay them to work) and leave an outdated website online until the final shop or restaurant is closed. Commonly it's only some "CLOSING DOWN SALE LAST DAYS EXTENDED TO FRIDAY" post on social media that informs visitors accurately.

dhx

6 giorni fadiscuss

See alltheplaces.xyz for continuously updated straight-from-the-primary-source opening hours of chains of shops and restaurants, public facilities such as libraries, etc. This is probably as accurate as it gets AND you have the confidence of knowing exactly where the data came from (down to the URL) and when it was last checked.

Some OSM contributors go brand-by-brand/operator-by-operator in making sure OSM features have the most up-to-date opening hours added to them from matched ATP features. As such, OSM may be fairly accurate for chains too.

For a standalone shop or restaurant the opening hours situation is usually still better with Google Maps rather than OSM. There aren't enough OSM contributors who care enough to check and maintain opening hours for every shop, restaurant, fuel station, etc.

dhx

6 giorni fadiscuss

1. This is largely country-dependent with some governments being quite adamant that address data should be in the public domain, and some governments doing the opposite and selling address databases to private companies for some quick cash, where private companies then sell address lookups for some absurd per-lookup price for the next few decades. Most of the world though is probably just not rich enough to compile, publish and accurately maintain a national address database.

OpenAddresses is perhaps the gold standard for open source address data compilation from government datasets. Note for the future that alltheplaces.xyz (project I contribute to) is looking like it may eventually perform the automatic address data download/extraction/compilation that OpenAddresses currently performs. This has the benefit that in backwards countries, alltheplaces.xyz also obtains some addresses through other means--such as advertised location of international restaurant chains. And quite often, being within +/- 100 address numbers on a road is good enough for navigation. Google Maps obviously crawls addresses from all over the Internet AND has quite a high tolerance for errors, hence will perhaps always seem more complete than OSM.

2. Some further ideas for open source mapping applications trying to determine real time traffic situations:

2a. Use GTFS/GTFS-RT feeds for bus networks to detect real time delays but also to compare planned bus route schedules for different times of the day (different traffic conditions) where buses share the road with the public. There's already a few maps out there that overlay nearby GTFS-RT feeds for the city of interest and usefully provide a visual indication of how well public transport vehicles are currently moving.

2b. alltheplaces.xyz extracts public traffic camera feeds which could be presented to users when they plan/commence a journey as an indication of what lies ahead on the route.

dhx

7 giorni fadiscuss

I change that slightly to "Good luck getting an explosive payload."

The difficulty for an attacker is the explosive payload, not the delivery mechanism. If it were easy for an attacker to get an explosive payload there would be car bombs going off every day as an easier delivery mechanism than use of quadcopters.

Thankfully it seems to be relatively easy to prevent people from making explosives, at least outside of warzones in countries with strict border control, because random people don't have a valid reason to buy industrial chemicals or equipment, and especially not chemicals identified as precursors for making explosive compounds. And for plants where such industrial chemicals are legitimately necessary to use, inputs and outputs can be measured, and detection taggants[1] used, and many other security measures, to prevent accidental or deliberate loss of control over such chemicals.

[1] https://en.wikipedia.org/wiki/Taggant#Explosive_taggants

dhx

25 giorni fadiscuss

"Fix this code" should ideally solve entire vulnerability classes, not just spot fix buffer overflows one by one. Thus it may be possible to design an LLM which can solve entire vulnerability classes and remain useful to users, but refuses to reason about specific buffer overflow vulnerabilities or specific race conditions, etc.

For example, "fix this code" on an ageing monolithic C codebase that accepts media files as input and outputs them visually to a display server could:

1. Recreate the software using a modular and loosely coupled architecture rather than monolithic and tightly coupled software architecture. For example, command line argument parser is a separate process, file format parser is a separate process and display server output is a separate process. If new features are added in the future (such as filters for manipulating output) then the architecture supports such additions with ease.

2. Use operating system sandboxing features to restrict what each modular component of the software architecture is permitted to do. Now that the parsers are separate processes, it's easy to pass an open file handle to the file format parser and only permit the process to read the file handle (not write to the file, not open any other file, not read the system clock, not open a new network socket, etc). The worst case impact of a parser bug is now significantly reduced.

3. Convert at least critical components to "safe" programming languages (Rust, Ada, SPARK, etc) which can be used to remove entire classes of bugs--read/write out of bounds, division by zero, numeric overflows, etc. For cryptography code--use a formal mathematical proof language. With a modular and loosely coupled architecture, different programming languages can be used depending on the use case--for example, assembly for video decoding where performance matters most and sandboxing can provide the security guarantee, Rust for implementing multi-threaded servers where race conditions must be avoided and Python for low-criticality user-adjustable code/plugins where ease of use and maintainability is most important.

4. Ensure software components are reproducible during their build.

5. ...etc

However, a prompt of "Are there any buffer overflow bugs in this codebase?" or "Fix the integer overflow vulnerability in add_numbers(x, y)" would be rejected. In the later case, telling the LLM to fix some specific bug in each of function1 through function9999 would force an LLM to reveal whether it thinks a bug exists or not. Responses of "Silly human, that bug doesn't exist in function596" or "Good find human, I've fixed that bug in function596 for you" allows a human to quickly narrow down where the LLM thinks a bug worthy of manual human detection can be found.

dhx

26 giorni fadiscuss

I like that it's non-serious and contains jokes throughout the user interfaces. Reminds me a little of Airline Tycoon's non-serious/joking nature, and Theme Hospital if going further back in time. It makes the game fun rather than a boring simulator some city planner would use for work.

dhx

26 giorni fadiscuss

Contributor for an open source scraper -- https://alltheplaces.xyz/ -- which currently has about 4700 scrapers extracting 40-someting million points of interest.

The project aims to scrape location data and other general information about shops (main use case), postal addresses, restaurants, schools, weather stations, marine buoys, traffic cameras, street trees, whatever someone may decide is worthwhile to add to OpenStreetMap, or use as location data in other projects.

There's a decent community of contributors keeping the scrapers maintained and further expanding the number of points of interest which are extracted.

The opportunity I'd like to work more on (time permitting) is the data scraped by this project I feel is heavily underutilised in other open source/community projects. For example, there's a great opportunity to generate a location map once a week of current locations of international restaurant chains, and upload to Wikimedia Commons where every language Wikipedia would gain a high quality infographic of current locations of a chain's restaurants, etc. As an additional example, time-series data from ATP could be used to update a graph hosted on Wikimedia Commons each week where the graph plots the rise and fall of retail or restaurant chains.

dhx

mese scorsodiscuss

There's an example at [1] of a prompt for a HTML mockup operating system where 3 applications are requested to be "white hat tools" that show diagnostic system information. Claude Fable 5 is shown and said in the video to switch back to Opus 4.8 as a "safety" feature.

What an utterly useless model if it refuses to work on something as benign as basic system diagnostic utilities (nmap or whatever).

[1] https://youtu.be/9GLYsrMpprs?t=305

dhx

mese scorsodiscuss

Also have a look at Inform 7[1] (domain specific language for interactive fiction), specifically the "Stone" example section[2] which explains edible food and the effects different foods may have on the adventurer.

It's similar concept to OPM with some modelling basics already built on top for player movement throughout a world, player interaction with objects (looking at, lifting, moving), and many other primitives needed to write interactive fiction. And relevant to this thread, Inform 7 of course has modelling basics for a player eating food, drinking potions, etc.

[1] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la...

[2] https://ganelson.github.io/inform-website/book/RB_9_1.html

dhx

mese scorsodiscuss

Agreed. My comment was to highlight that if a recipe for a soup just says "1kg squash", that could mean anything from "Cucurbita maxima subsp. maxima var. Jarrahdale"[1] through to "Cucurbita pepo subsp. pepo var. recticollis"[2], with vastly different outcomes for the soup.

The model under the hood should probably have ingredients as parts of a taxon, then have common names mapped (many:many) to these parts of taxons. Then it's necessary to have abstract classifications such as "pumpkin seed" which could be defined as the seed of multiple different taxons, which for some recipes, may not matter which one of 5 Cucurbita subspecies is used. That way if someone types "squash" or "pumpkin seed" they get asked to clarify what they mean, which will change quite a bit depending on locality of the person being asked.

[1] https://en.wikipedia.org/wiki/Jarrahdale_pumpkin

[2] https://en.wikipedia.org/wiki/Straightneck_squash

comments