Blog

  • I Think A Lot Of “Enterprise” Computing Is Just Money Laundering

    I don’t see a more sensible explanation anywhere.

    Basically a huge sum of cash like a few million dollars will be transferred from Australia or some other country to America, then a few thousand dollars worth of computer is received – nice hardware but not supercomputers worth millions. That sits on a shelf doing almost nothing while the government tells me all their services still aren’t working, then I buy it at auction for $100-$200.

    I think someone is paying for something like cocaine and I’m buying the empty canisters afterwards.

  • Some Reasons I’m Interested In 32-Bit Systems

    32-Bit Is Very Fast

    Firstly, and the most obvious reasons, 64-bit systems aren’t necessarily faster in “native” performance. It probably depends on the app and the hardware, different operations may be faster one way or the other.

    Whereas the common logic in PC hardware is more=better this doesn’t apply universally especially if the system has some other necessary restrictions.

    32-Bit Is Often Faster In Modern Use Cases

    I use a lot of RISC-V hardware for development, almost all of my machines are RISC-V, but obviously sometimes I need to develop for an old platform or just run some old app.

    In these cases, which are probably increasingly common use cases (and with other devices too), 32-bit is the clear winner for fully emulated guest operating systems. It’s just plain faster.

    I Dare Say 32-Bit Is More Efficient

    Especially if you’ve got a machine that needs to be responsive when needed but is idling most of the time, all of those high bits in your registers and your reserved memory are idling too… I don’t know the numbers but I can’t see any way that a 64-bit machine could be as or more efficient in many cases (except when actually making use of all that extra bus width and maths capabilities).

    Can We Compete With Reliability?

    A system that has it’s core rewritten every ten years for new architectures might get substantial improvements every time, but it doesn’t really give customers or distributors much guarantee that it will work for years. Rather it kind of feels like even new hardware is entering a planned obselecence cycle as soon as any modern software touches it. This even happens with new architectures, everyone buys the first decent model then the distros stop supporting that model.

    So it’s not so much about whether there’s any direct commercial utility in supporting very old hardware, we know it’s better to just sell upgrades, but why is anyone going to buy a new system knowing their new CPU that still works fine will start being phased out unnecessarily in the software as soon as there’s a better model to sell?

    New Hardware Often Isn’t 64-Bit First

    We already have open source CPUs that are compatible with a lot of 32-bit software, whereas 64-bit CPUs are typically less practical for bootstrapping open source projects (although we do have those too, it’s probably easier to demo or to sell ao486 than it is to demo or sell a newer experimental system, and I’m a retail guy).

    This is also a problem for people developing new CPUs: Do you try and make a 64-bit version that won’t fit in any cheap FPGA or do you try to make a 32-bit version that will probably work better for early testing but will be snobbed as outdated by much of today’s software?

    Also For Nostalgia & Old Apps

    I think this is the only thing other vendors are considering when they drop 32-bit support. Although I’m more interested in 32-bit systems because they’re very reliable & flexible, it’s also obvious that newer compatibility layers won’t be a complete solution and sometimes you’ll have to run a real OS for compatibility.

  • I Think My “New” Products Will Be De-Emphasised

    This is mostly because I just received way too much disrespect from people locally when trying to invite everyone to see my new OS kernel, but also because new hardware is just a slow game and I don’t still want to be doing my initial OS launch next year waiting for the right boards or the right price or still trying to figure out drivers etc. The trade war is tiring.

    So in the short term I’ll probably focus on value-added/integrated software distribution, especially using my expertise in BSD-based systems. SL/RD will stay in development but will probably be used as one of several options, in the meantime I can probably move much faster developing integrated solutions from legacy software stacks.

    SL/RD will remain on offer of course as there are still many reasons to migrate away from old technology, but I think I need to reduce my workload for now to get usable solutions working and then get back to cutting edge stuff. The same applies for hardware designs, although I do quite enjoy working on hardware and hope to do more of it!

  • A Lot Of Old Software Is Very Good

    I know I’ll have to use a combination of new/in-house and old/third-party components to build real products, I’m wondering whether I should build separate products though.

    It would be interesting to see what an OS from 20 or 30 years ago would look like if I just improved everything for usability instead of rushing to replace it with 900 layers of other shit to compete with Linux/Windows/Mac.

    (I guess it would look a bit like Haiku, which I recommend looking at if anyone likes nicely designed classic systems, although that’s mostly a newer rewrite based on old specs.)

  • Open Source Licensing Can Still Look Unreasonable

    One reason people don’t do more with existing codebases like the BSD family is because of the vagueness of the terms to anyone who isn’t overly familiar with the American legal system. Basically the gist often seems like “do what you want with the code, but make sure that you credit us AND make sure that you don’t use our name to endorse your product” but their name is all over the code and has to be printed at boot.

    So my response to that is basically that this isn’t America, I’ll try to adhere to the license terms but if they seem contradictory then the simple fact of the matter is that USA copyright law doesn’t apply worldwide and it is fairly unreasonable from a business perspective to expect people to give much of a shit about abiding by the fine print when you’re giving something away for free.

    Sorta like if you give someone a free banana and it has a note on it. From a retail sales perspective that note isn’t a legal contract that the consumer has signed it’s just a product label: you already gave away the banana you can’t be that picky now about how it’s eaten.

  • I Want My Birth Certificate Corrected

    It has the wrong name and country. I intend to start taking over the records of births, deaths & marriages if the “white” people in Australia are committed to keeping inaccurate logs.

    This is something I think of every time I tinker with databases or filesystems. I really want my records corrected so I can be a normal citizen somewhere in a country that actually claims me, it’s been one of the most frustrating things in my whole life.

  • How To Change FreeBSD Uname Information

    This might be useful to others creating customised respins or trying run old scripts with compatibility hacks.

    FreeBSD makes changing the uname information very easy, you can try it straight from the shell and then run uname -a to check:

    export UNAME_s=CleanForkHPC
    export UNAME_r=1.0.0a
  • Summary Of New Products

    CleanFork HPC & New SL/RD Subsystem

    A range of larger operating system builds.

    “Based on old code, for old computers.”

    Extensions based partly on my in-house SL/RD OS will also be rebranded for use as a portable layer with this OS range as a new main target. These will probably retain a branding similar to SL/RD but clearly distinguished, e.g. SL/CE, and some tools in this collection will just be ports from elsewhere.

    CleanFork Microkernel & Research Systems

    A range of microkernel-style solutions.

    This initially targets legacy hardware using MINIX or comparable kernels (there are others to test…) but will hopefully eventually extend to RISC-V and other platforms.

    CleanFork Burrito SDK

    This will be the open-source edition of the SecureLang® Flagship Compiler (which was internally codenamed Burrito and originally SecureLang, hence my current branding).

    This is not quite a finished robust toolkit but is about 1.0 level as far as typical compilers go. Two versions of the compiler exist, allowing SecureLang® Flagship to remain as an enterprise-style compiler running from legacy systems, which I will charge something ridiculous like $100/year for, while releasing the self-hosting edition for free (hoping that other people might help to improve that version and the VM for use in other products).

  • Early CleanFork Builds

    These are recompiled versions of third-party operating systems with some small patches.

    Note that these systems are early testing versions of ideally-stable versions of outdated or near-outdated open source operating system versions. Do not install them on your grandmother’s PC with the family photos, these are only intended as test builds for use in a VM.

    A Simple HPC Solution

    FreeBSD still rebuilds successfully, even on 32-bit i386 targets (which are being phased out starting with removal in 15.x):

    https://SecureLang.net/release/OriginsHPC-14.4p01.zip

    This build doesn’t include any notable patches, but is missing part of the FreeBSD upstream. Note that future “HPC” builds will probably be based on slightly updated upstream sources, but that 32-bit x86 support is ending in the main FreeBSD project (so 32-bit support will still “work” but any package hosting etc. will need to rely on smaller volunteer or business forks such as this).

    Microkernel Builds With Test Branding

    The patch p02 build successfully changes the CD label from MINIX to CeanFork branding (this needs to be modified in two parts of the source at the same time for a successful build, see /usr/src/DISTRO-CHANGES):

    https://SecureLang.net/release/OriginsMK-3.1.8p02.zip

    The patch p03 also adds a uname option allowing the system to report either the original or new/testing version information. This works by running uname -T to toggle between (this setting is currently global), with the default of using old uname information allowing scripts to run unmodified:

    https://SecureLang.net/release/OriginsMK-3.1.8p03.zip

  • SL/RD Updates, Portability To Other Kernels & The Flagship Product

    Instead of trying to get everything working at the same time with the new kernel and organising demos solely around that, the existing SL/RD system will be split approximately in half:

    The Portable Half

    • Package manager
    • Graphics stack
    • Some of the programming tools

    These will probably be rebranded into a second package with other portable tools and used across different operating system kernels.

    These may be packaged as a single unit or as a single unit with some extensions or some optional dependencies, but the individual tools will often work standalone on systems where other tools fail to build (i.e. you can ignore build failures except for the components you need).

    The combined packaging idea is to simplify cyclic dependencies while the package manager & other tools are being developed, I don’t want everything neatly packaged in some totally unusable way! It may have custom installers so that it can be integrated with OS builds or this may come later/piece by piece.

    The Kernel & Utilities

    • Filesystem
    • Kernel base
    • C runtime

    These will remain as the mostly-independent SL/RD kernel, but will probably gradually mix some code with other systems where sensible (e.g. possibly running SL/RD on top of an existing driver layer, or running an updated version of the filesystem across different kernels for further testing).

    Flagship Packaging

    The planned “flagship” SecureLang compiler range will probably initially be released under the CleanFork brand as an experimental OS extension.

    This is partly because it may be handy earlier on with larger operating systems and partly because the development codename of the system SecureLang/Burrito naturally fits the CleanFork brand. This won’t run across the entire OS range as yet.

    More to follow…