Do they claim me as a citizen?
Yes or no?
I haven’t been able to get a straight answer out of anyone at the government. My guess is they initially considered me a citizen then cancelled it when they realised I was Egyptian and never told me or my mother. So I’m still on their files for Centrelink purposes and when registering business stuff but am not really considered eligible when I try to go to something like a doctor’s appointment or any kind of recruitment centre here.
I’m Egyptian and also Irish and British, but I’m not Egyptian Australian or any of that shit. I don’t acknowledge any kind of dual citizenship agreement between myself and Australia regardless of what their bogus laws say. The Australian army were very clear to me that I was an enemy race and not a citizen of their country when I tried to join, although I was born in the Australian continent on Aboriginal land.
Australia just keeps a lot of people here following Britain’s wars across the planet and I don’t want to be here. I’m not Australian and I never will be.
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.
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.
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.
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).
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?
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?
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.
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!
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.)
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.
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.
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.0aA 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.
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.
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).