Soverign Computing at the Bottom Floor

For 60 years the entire modern world has been building a tower of babel of an incomprehensible magnitude. https://yewtu.be/watch?v=ZSRHeXYDLko At some point this ferverous death march will end. As of now I see no clear path as to how technology will be rebuilt. There is no way to bootstrap semiconductor technology yet. I want to escape this downward spiral. There are two parts to achieving this: >I want to create a device that has 80% of the functionality of a smartphone with the absolute lowest end hardware possible. -Text messaging -Calendar -Clock & Alarms -View plaintext -Wget plain text from the internet -Calculator -Planning apps (financial tracker, diet tracker, todo list) -GPS Navigation (look up the betrusted project if you like security and this idea interests you) These features are able to be implemented on tiny microprocessors, many on 8 bit machines from the 70s. I have been looking around on opencores.org to see what FOSS processors might meet my requirements. Right now I am interested in the ZPU who's claim to fame is being the smallest 32bit processor ever implemented. On that I would run a simple OS similar to a PDA. >Hardware low spec enough to be theoretically possible to manufacture it yourself if you had a small amount of capital and a large amount of time. The distributed manufacturing is far fetched, but an admirable goal, and one that I think is possible. Using mercury lamps as a UV light source ASML is able to get 220nm features out of a dry process. https://www.asml.com/en/products/duv-lithography-systems/twinscan-xt-400l This is called i-line lithography and uses the 365nm wavelength generated by mercury vapor lamps. Of course if you are making everything yourself you also need to make your photo-resists, masks, silicon crystals, circuit boards, IO devices, etc. If you limit the scope of what you make you could get these down to a minimal component set. That simple hardware set could still reap the many benefits of computing without being dependent on the global supply chain. The ASML foundries are highly complicated machines in part because they focus on efficiency and speed. Thats great but if I can do it 10x slower and 100x simpler then thats what I want to do. https://yewtu.be/watch?v=a5CxGbs4ROw Do you agree that smaller, simpler computers are the best solution to ensure our digital sovereignty? Do you agree that smaller, simpler computers are easier to verify and secure due to their reduced attack surface and complexity? Have you seen Sam Zeloof's garage semiconductor fab? On his website he says he can get 5um feature details. Do you think there is a reasonable chance that a FOSS i-line lithography process emerges sometime in the future to print simple computers for free people?

>Do you agree that smaller, simpler computers are the best solution to ensure our digital sovereignty? to a degree. There will always be the problem of availability of specialized equipment and pure enough silicon (wafers are not cheap). But that really can't be helped. There's also the problem that simplicity can be counter to usability. It's not hard to produce a turing tarpit architecture, but it needs to be possible to write a reasonably efficient program with a reasonable amount of effort. The best bet for something like this would be a transport-triggered architecture, I think. They are conceptually simple and extremely easy to implement. Upon that it is important to choose a good abstraction -- forth would be a good blend of simplicity and empowering the user. >-Wget plain text from the internet >-GPS Navigation these two are by far the most ambitious of your ideas. >Text messaging also pretty ambitious, but not for technical reasons, just because you will have to use qualcomm chips to do it.

That Jonathan Blow talk isn't much impressive. Allow me to link to a better thought-starter: http://www.loper-os.org/?p=55 In a similar vein, read Can Programming Be Liberated from the von Neumann Style? by John Backus. This obsession with the low-level is perverse, and I'm someone who has done some interesting work on making the low-level high-level, regardless. It should be clear that a truly comprehensible machine should implement a high-level mechanism directly in hardware, with no option to delve beneath it. This has been done before and can be done again. The modern hardware is wasted on inefficient designs running inefficient software, anyway. >-View plaintext What people call plaintext is baggage from the days of typewriters, and other work of mine is working to do away with it. >-Wget plain text from the internet Already, this seemingly simple requirement brings in ASCII, Unicode, UTF-8, IP, TCP, HTTP, and likely also the ever-moving target named TLS. Does that seem simple? >Do you agree that smaller, simpler computers are the best solution to ensure our digital sovereignty? That simpler is doing a lot of work there. A simpler machine wouldn't just be inspectable, but easy to fully understand in all ways, including its entire body of software. >Do you agree that smaller, simpler computers are easier to verify and secure due to their reduced attack surface and complexity? No. Throw megabytes of garbage onto an older machine and have fun inspecting that. >Have you seen Sam Zeloof's garage semiconductor fab? On his website he says he can get 5um feature details. Consider linking to this. >Do you think there is a reasonable chance that a FOSS i-line lithography process emerges sometime in the future to print simple computers for free people? No. Free Software is a band of volunteers. Most all of software is dumbassery. Notice the silicon foundries are real businesses, unlike nearly all software businesses.

>>32711 > It should be clear that a truly comprehensible machine should implement a high-level mechanism directly in hardware, with no option to delve beneath it. How "high-level"? There is no ability to modify hardware on-the-fly with an integrated chip, which is the only reasonably way to implement a computer that is both small and capable. Another problem is that in this thread we are discussing the difficulty of hardware manufacture, not just hardware understandability. A machine with a complicated instruction set (such as a modern x86 CPU) is impossible to manufacture without millions/billions of dollars in capital and the right contacts. Therefore, if free hardware is to be "high level" it must be completely rock solid, adaptable to many uses and environments, extremely efficient (since extreme efficiency is demanded of any computer which will mostly run off of battery), and ultimately simple enough that a small team of proficient people with modest funding could make one from scratch. The only thing I am aware of which is "high level" and satisfies these constraints is certain flavors of lisp -- and you're not going to be getting any of the CLOS standard library implemented in hardware, either, that would take millions of transistors. Unless of course by "implemented in hardware" you mean running an interpreter off of PROM, in which case yeah that would be pretty cool.

>>32711 >This had been done before and can be done again. Consider linking to this. True wgetting and GPS navigation are the most complicated features I want, but theyre basically required of a device that replaces a phone. Using the Gemini protocol or gopher is a lot simpler than having a whole webbrowser. And GPS navigators existed since the 2000s that you plug into your car. Im thinking about simple enough to be done by a few people over a few years. A final product thats acutally useful for replacing the most important roles a smartphone fills.

>>32712 Your suggestion of running an interpreter from ROM is very cool. A modern high level language with an absolutely tiny interpreter is Lua. The Lua interpreter is about 150 kilobytes. Lua is very close to C in performance. I especially like this idea becuase all the programs on the system could be read by anyone who opens them since they are interpreted instead of compiled. A system like that with even 1Mb of memory and maybe 8Gb of storage would satisfy the 80% of use cases a smartphone fills without all the garbage.

>>32714 Lua is nowhere near the performance of C? Given I am not sure what type of benchmarks you did but in general Lua is much slower than C.

>>32709 John Blow is a John Blowhard. His knowledge of software is limited to things where most Real World considerations don't exist, and even within those bounds its a lot more limited than he'd lead you to believe. But more to the point, my question is, why do you even want a computer that simple? At that point, it's better to just make single-purpose devices that do everything in hardware. They're easier to build and do the job better.

>>32712 >>32713 >How "high-level"? >Consider linking to this. http://www.loper-os.org/?p=46 http://www.loper-os.org/?p=13 >There is no ability to modify hardware on-the-fly with an integrated chip, which is the only reasonably way to implement a computer that is both small and capable. I'm aware of this. >Therefore, if free hardware is to be "high level" it must be completely rock solid, adaptable to many uses and environments, extremely efficient (since extreme efficiency is demanded of any computer which will mostly run off of battery), and ultimately simple enough that a small team of proficient people with modest funding could make one from scratch. Well then, a non-von Neumann design is necessary, because a good such design can be made from many, repeated, identical computational units locally connected, and this would also be easy to inspect. >Unless of course by "implemented in hardware" you mean running an interpreter off of PROM, in which case yeah that would be pretty cool. No. Understand that high-level machines are possible and superior. >>32714 Soverign computing isn't going to come from taking any of the past like this.

>>32717 >Well then, a non-von Neumann design is necessary, because a good such design can be made from many, repeated, identical computational units locally connected, and this would also be easy to inspect. So you propose a sort of connection machine architecture? That could work, although I am still dubious just how "high-level" you could get without requiring an impractically large connectome. >No. Understand that high-level machines are possible and superior. I'm well aware that they are possible, but I am unconvinced they are superior by certain important metrics.

>>32717 Your enthusiasm for the lisp machine revival is admirable, however my goal is to get a working product. As far as I know the lisp machine has stayed very dead for the past 40 years. As interesting as it is, the tools for developing a C machine are ubiquitous and free. On opencores.org there are dozens of processors that run on FPGAs successfuly and can execute C code, run several embedded operating systems like uClinux and FreeRTOS. Code that has been reviewed by a thousand eyes and is actively developed. >Is there any recent progress on the Lisp machine front? >Is there a Lisp core you can flash to an FPGA and develop software on?

>>32719 >As interesting as it is, the tools for developing a C machine are ubiquitous and free. Oh, I thought we were discussing sovereign computing, not more of the same old same old. Those tools are opaque and likely backdoored. >On opencores.org there are dozens of processors that run on FPGAs successfuly and can execute C code, run several embedded operating systems like uClinux and FreeRTOS. I can't comment on FreeRTOS, but nothing related to the Linux kernel is practically auditable. >Code that has been reviewed by a thousand eyes and is actively developed. Yes and, because it's disgustingly large and written by volunteers mostly sponsored by businesses, that code will never actually work. It will always require updates and fixes and so on, forever.

>>32720 Being sovereign over your technology is different from perfecting it. I am sovereign over my clothes because I can make them, fix them, examine & inspect them in any way I want. They dont need to be perfect. It is impossible to achieve perfection in anything, especially in something as complex as a computer. Im sure you have heard the saying "there is no such thing as a completely secure system." You can make things better, but never perfect. >it's disgustingly large and written by volunteers mostly sponsored by businesses, that code will never actually work. It will always require updates and fixes and so on, forever. Those projects you dismissed like uClinux and FreeRTOS are designed to run on tiny microcontrollers, and have codebases sized for that task. They have physical restrictions that prevent them from becoming "disgustingly large." And clearly they DO work. They are deployed to millions of devices doing millions of tasks. If you set aside the spectre of perfection and just think about how we can make things that work, that are free, and that are auditable by a small group of people with a lot of time, then I think we can get somewhere.

The problem with "soverign computing" is that, on a day-to-day basis, the work computers are doing is inherently complex. You can probably get some sort of computer working on your own, but if you want anything capable of performing modern (post-80s) computing tasks, you're going to hit a wall.

>>32721 >a lot of time Those four words are key. You can do basically anything given enough time. Most people don't have that time.

>>32723 Most people also don't have time to manufacture chips.

>>32722 Thats a good point, but what exactly do you need a computer to do that couldn't be done on mid 80s hardware? Play javashit games in a browser larger than an ubuntu iso? I know some things like running VMs and "big data" type operations benefit from powerful computers, but 99% of people dont do that. Smartphones, the device I am targeting to replace, dont do that. A sovereign computer only has to meet the daily needs of the everyman. Storing and displaying simple informaion, giving alerts and reminders, and simple text based communication via [insert protocol here] >>32723 People seem to have found the free time to develop the entire free software ecosystem, which meets all my needs and more. There are open hardware projects that exist. I want to know if there is a will to push that further into homebrew manufacturing.

>>32721 Yes, that may sound nice and plain, but it's wrong. >It is impossible to achieve perfection in anything, especially in something as complex as a computer. Someone tell mathematicians there are cases in which the Pythagorean theorem doesn't work, apparently. No, this is what an incompetent man writes. I can write perfect software, and have, but I certainly believe others to be incapable. What I won't tolerate is this nonsense with which the incompetent and incapable attempt to drag everyone else down with them. An automatic computer is a machine for applied mathematics, and mathematics can be perfect. >Im sure you have heard the saying "there is no such thing as a completely secure system." Yes, idiots love to repeat it. >You can make things better, but never perfect. An idiot can't. In fact, idiots are obsessed with toiling forever, getting closer but never reaching perfection. >And clearly they DO work. Read this: http://www.niquette.com/paul/issue/softwr02.htm >>32725 This is what I meant by The modern hardware is wasted on inefficient designs running inefficient software, anyway.

>>32726 >Someone tell mathematicians there are cases in which the Pythagorean theorem doesn't work, apparently. The Pythagorean theorem you're probably thinking of only applies to euclidean spaces, which you will never find a physical example of. >An automatic computer is a machine for applied mathematics, and mathematics can be perfect. Unfortunately the mechanisms by which we bend physical objects to do mathematics for us are imperfect, because they are actual machines. Actual machines are made of valuable resources and are often difficult to manufacture. They have things like electrical noise, line delay, and voltage drop. Their internal state and the environment they exist within cannot be known to mathematical precision, only approximated. In this thread we are talking about actual machines, not the perfect mathematical abstractions which we would like these machines to emulate. Therefore your demand for mathematical perfection is impossible.

>>32727 Here's a hint: Software can assume the hardware just works, which it usually does, and it can even be written to double-check the hardware. This is how the earliest computers worked. None of this precludes perfection, especially in software, so stop lying. This thread seems to be asking for another useless trinket, which isn't for what I thought it was originally asking.

>>32728 >Software can assume the hardware just works, which it usually does, and it can even be written to double-check the hardware. My point about "actual machines" applies to software too. Any sufficiently complicated piece of software will have too much uncertainty in its internal state, and will have too many design considerations forced by the hardware, to keep the whole thing in your head. There are techniques to deal with it obviously (just like there are techniques to deal with it in hardware design), and it is possible to produce proofs of correctness for code, but it will always be orders of magnitude easier to write software that works versus software which has a proof of correctness (the only reasonable and verifiable definition of "perfect"). You say you have written perfect software; I believe you. It's not that hard to write a provably correct GCD function. However I don't believe you have written a provably perfect operating system that you can use to browse lainchan, and I don't believe you (or anyone) could do so alone. >so stop lying This would imply that I don't believe the truth of what I am saying.

>>32729 >Any sufficiently complicated piece of software will have too much uncertainty in its internal state, and will have too many design considerations forced by the hardware, to keep the whole thing in your head. That's no fact. Regardless, that's precisely one reason to make the hardware higher-level, to simplify its software. >it will always be orders of magnitude easier to write software that works versus software which has a proof of correctness (the only reasonable and verifiable definition of "perfect"). That may be true right now, perhaps, but it's also easier for me to drink my urine rather than to get more water; the ease of doing something is no excuse. I thought this thread was about fighting precisely this illness, not justifying it. >You say you have written perfect software; I believe you. It's not that hard to write a provably correct GCD function. It's more complex than that, but we agree perfect software can exist, which means perfect software can be composed to build further perfect software. >However I don't believe you have written a provably perfect operating system that you can use to browse lainchan, and I don't believe you (or anyone) could do so alone. I don't even want to write one, but it's ill-defined anyway. The current state is a mess that will collapse underneath its weight. Why produce a useless trinket that can do this, when better useless trinkets already exist for the purpose? There's no competing here; give that up and aim to do something else, perfectly, instead. >This would imply that I don't believe the truth of what I am saying. It doesn't, but whatever. We've elaborated our positions past that by now.

>>32730 >the ease of doing something is no excuse. incorrect. If something is too difficult to be done given the resources (time, energy, money) you have, it is perfectly reasonable not to do it. >give that up and aim to do something else, perfectly, instead. do something less useful, you mean.

>>32731 >If something is too difficult to be done given the resources (time, energy, money) you have, it is perfectly reasonable not to do it. That now appears to describe the goal of this thread either way. >do something less useful, you mean. There's no point in building something like a smart phone; at best, it will be a pale imitation. Have the final word.

>>32709 > As of now I see no clear path as to how technology will be rebuilt If some soykaf really happens, I don't think we will have resources enough to even reach an industrial revolution level.

This thread is something that we need. It presents some of the biggest ethical and practical issues of contemporary technology and dares to tackle them head on. Why not take the chance to dream? No doubt, idealism and perfectionism by themselves rarely yield any practical results - but why shoot ideas down without first, at the very least, checking out what the current state of the art is? Consider as case in point the idea of software correctness and its rebuttal: >it will always be orders of magnitude easier to write software that works versus software which has a proof of correctness This is already not the case today! To my knowledge, no current language offers complete proof-of-correctness for free, but plenty do prove many important program properties at compile time and pave the way for a complete proof. People have already leveraged these to write the first formally-verified microkernel. Is this avenue not worth exploring? As the issues exposed are real and pressing, any discussion of them must keep in sight the goal of building a practical solution, lest it end in fruitless yak shaving. However, a practical solution need not always follow the most well-trod path, especially if that path lead us to the present problem to begin with.

>>32735 >People have already leveraged these to write the first formally-verified microkernel. 1) seL4 was written in C 2) the proof of correctness took much longer than writing the code, afaik

>>32735 >>32736 Yes the proof verifying the sel4 micro-kernel did take a long time. Its a very cool project and I've watched a few presentations about it. >>32728 >This thread seems to be asking for another useless trinket, which isn't for what I thought it was originally asking. The OP has two lines of green text that outline the subject of the thread: >1) I want to create a device that has 80% of the functionality of a smartphone with the absolute lowest end hardware possible. >2) Hardware low spec enough to be theoretically possible to manufacture it yourself if you had a small amount of capital and a large amount of time. Mathematically perfect machines or creating an elegant design isnt mentioned anywhere. The point is to get closer to a world where fully free hardware and software exists as an independent entity that can support itself without any closed source software or manufacturing methods. I'm not opposed to elegance or beauty in good design, but I am thinking in terms of practicality. Using existing FOSS designs and software cuts YEARS off of any project as ambitious as this. Ultimately my goal is freedom. Once freedom in computing is guaranteed then I will gladly spend my time working to make it as elegant as possible. However at the moment we are not free, and that is the goal I want to see achieved ASAP. If you want to talk about elegant design then make a thread about it. That would be fun, but here the discussion should stay focused on freedom in personal computing.

>>32737 cont. let me expand on what I think would be a good design for the purpose of making something simple and functional. Hardware of something between 8 and 32 bit processor. 1Mb of memory. A display resolution of at least 320x200 monochrome. 640x400 would be nice. The form factor should be similar to a smartphone which can be carried in a pocket. The VHDL design should also have a small footprint so that it can be printed on a 350nm i-line lithography process. As stated in the OP I believe that i-line lithography is the best possible process for a small group to implement. The i-line process is dry, which means there is no need for a thin layer of ultra pure water to exist on the surface of the wafer to increase resolution during printing. It also does not use an excimer laser which is a complicated component in itself, but also requires different optics and mirrors for managing its light output. These specifications allow for the use of high level languages, specifically I am thinking of Lua. It has a tiny footprint, is dead easy to learn and read, and its a lot faster than python. Its not C fast, but its not C complicated either. It works well with C too. I dont expect drivers to be written in Lua, but a Lua userspace would mean users would truly have the ability to examine and modify their environment. Of course physical manufacturing is much more difficult that software development. Therefore we should start by designing a software system that works with minimal hardware requirements. When hardware manufacturing eventually becomes more open we will have a system ready to deploy and take full advantage of new manufacturing processes as soon as they become available.

>>32738 I feel like 320x200 monochrome would be a deal breaker for most people. The goal should be to provide something that gives the appearence of a fully functional modern system for everyday use, even if it's not actually anywhere near that. But that's just my opinion. I also don't quite get having a Lua userland. I think it's a neat overall idea; I might even try it in my own osdev project if I ever get around to it. But unless I'm mistaken and Lua is faster than I thought it was, it'd be way too slow for such wimpy hardware. Like, J2ME absolutely chugged on early mobile phones, and that was pre-compiled bytecode running on significantly more powerful hardware than you seem to be suggesting.

>>32738 Again I would like to recommend a transport triggered architecture. Its dead simple to design one compared to even the most basic RISC-V processor, and it's not hard to write code for either. >>32739 Lua is pretty fast for a scripted language, and LuaJIT is comparable to C in speed. Both have very small footprints. You could do better (I would recommend a flavor of scheme or python) but you could do much worse too.

For context the Palm III PDA had a 32bit processor with 2Mb of RAM, a grayscale 160x160 display, and was manufactured on a process of 600nm or 350nm in the early to mid 90s. I think most of us can agree that device can do a lot of tasks adequately well. Image and video processing as part of a mobile device are a large part of cell phone addiction, so for a mobile device I see them as more of a negative than a positive. Thats a controversial opinion but if we are talking purely about practical functionality, a text and icon based interface is totally usable. For more context the Nintendo DS had a 32bit processor with 4Mb of RAM and was made with probably a 250nm process in 2000. It drove two 256x192 color LCDs. >Good enough technology doesn't need to be the recently developed

Dawn - operating system for SUBLEQ architecture Dawn operating system is a high-level, multitasking, SMP capable general purpose GUI operating system, designed for the SUBLEQ architecture. It is designed for everyone who wants to experience some simpler architecture than the currently popular ISA-s. Dawn brings back the architectural complexity to the level of the individual people: the big-endian 64 bit SUBLEQ instruction set which Dawn relies on, does not have various cpu modes, have no multiple instructions, it does not have DMA, interrupts, MMU or paging, and aims for the transistor count and power consumption of a Tamagotchi. Dawn is magic: you can play and learn with Dawn. You can write your own simple Dawn-compatible emulator, or you can try executing it on some FPGA. This platform is magnitudes easyer than anything else and its fun to deal with it, meanwhile at the same time its real heavyweight content-creational operating system with a compiler and all the basic tools. http://users.atw.hu/gerigeri/DawnOS/index.html

http://collapseos.org/ It is a Forth (why Forth?) operating system and a collection of tools and documentation with a single purpose: preserve the ability to program microcontrollers through civilizational collapse. It is designed to: Run on minimal and improvised machines. Interface through improvised means (serial, keyboard, display). Edit text and binary contents. Compile assembler source for a wide range of MCUs and CPUs. Read and write from a wide range of storage devices. Assemble itself and deploy to another machine. Additionally, the goal of this project is to be as self-contained as possible. With a copy of this project, a capable and creative person should be able to manage to build and install Collapse OS without external resources (i.e. internet) on a machine of her design, built from scavenged parts with low-tech tools.

>>32748 Why not use Brainfuck? Oh, that would obviously be stupid, whereas using SUBLEQ is not obviously stupid, for some reason.

>>32749 I'm honestly turned off by the name and branding. It makes me feel like a paranoid doomsday prepper using it (which I already kind of am, but that's besides the point). I don't want to have to think about the end of the world every time I use an operating system.

>>32748 Cool project but due to its design its unoptimized design its too slow for anything practical at the size and scale of a chip using a 350nm process efficient enough to be mobile. From the site you linked: >Below 20 Mhz, the OS load time is too high, and responsibility is decreases below the absolute minimum. Its not impossible that there are tricks available to decrease this limit by optimizing the operating system even more, but as the SUBLEQ opcode is not so efficient as other architectures, this limit seems to be a hard wall even if small optimizations can be carried out. The ultimate planned minimalmachine-goal for Dawn was to run as low as 7 mhz, but currently it requires at least a few ten MHz. >it is impossible to use the system without having at least 320 mbyte of RAM. If you were building an OS to run on an FPGA this would be a very interesting proposal, since at smaller gate sizes an FPGA could eat the performance hit of the architecture and you could have a user understandable verilog. >>32749 >on a machine of her design lol If anyone has experience using open hardware designs like the ones from opencores.org on FPGAs it would be interesting to hear what they have to say/what they might recommend for an SoC with a small efficient footprint that has 1-8Mb of RAM and could handle a simple text based interface fast enough to be usable on a mobile device.

>>32740 >I would recommend a flavor of scheme or python Using scheme would be great. What implementation would you recommend for embedded microprocessors with limited resources? Using a higher level language is central part of making libre computers in my opinion. You can get a usable system with Forth or assembly, but its source is basically unreadable. Theres a project called Uxn which is an attempt to simplify computing using a 32bit virtual machine and writing all software in their custom assembly. https://wiki.xxiivv.com/site/roms.html It works, but I looked at the source code for their applications and its very hard to follow. It does not read well, and for larger programs with more complicated behavior like a calendar or messaging app, it may as well be a blob. Its not feasable to go with the assembly or Forth option. AFAIK Lua is the smallest high level language with decent performance. If someone can show me a scheme implementation that comes close then I would choose the scheme every time. R7RS compliance would be nice.

civboot: https://github.com/civboot/civboot

>>32770 >What implementation would you recommend for embedded microprocessors with limited resources? Hard to say, you could augment https://github.com/ecraven/r7rs-benchmarks with peak memory measurements; Chicken and Bigloo can compile to C (read https://okmij.org/ftp/continuations/against-callcc.html, though). To be honest, I'd just use ECL, which is much more practical because it's CL (big standard and stdlib, quicklisp, macros for human beings, etc...). >AFAIK Lua is the smallest high level language with decent performance Counting on LuaJIT is probably not a good idea when we're not talking about mainstream µarchs. Let's be real, Lua is a bad meme with a weak type system, no integers before 5.3 and no notion of stability (breaks at each 5.x release). The technical criticism rms gave to old Tcl when compared to Scheme fully applies to Lua.

>>32773 Gambit, too, can produce C, from what I understand. Chez can only target x86/amd64, PPC, SPARC and 32 bit ARM; Racket may support aarch64 too. Between Bigloo, Gambit and Chicken, only Bigloo has real threads, from what I understand. Honestly, with R7RS-large still not finished, the fastest Scheme implementations targeting R6RS and Racket being its own world, I'd stick to CL.

>>32773 Thats true about RMS's criticism of TCL applying to Lua too. Its too under done for writing a whole system in. I haven't come across embedded common lisp or any lisp really while researching embedded development. Do you know where I can find statistics of its size, SLOC, etc. It needs to fit in less than 1Mb of memory. Why choose ECL over MIT scheme or chez which seems to be the most performant?

>>32770 >What implementation would you recommend for embedded microprocessors with limited resources? ArmPIT scheme would be a good reference I think. Seems to implement R5RS http://armpit.sourceforge.net/ >You can get a usable system with Forth or assembly, but its source is basically unreadable. Forth can be very readable. It allows for abstractions that assembler does not, once bootstrapped. You could even upgrade from forth to a more powerful stack-based language like Factor. I think its important to use the same language for "low-level" and "high-level". Forth and lisp are very good at that, especially since the basic machines can be implemented in hardware for not a huge performance hit.

>>32776 >Do you know where I can find statistics of its size, SLOC, etc. It needs to fit in less than 1Mb of memory. ECL compiles to C and I think uses boehm-gc. Should be generally ok, but try it. >Why choose ECL over MIT scheme or chez which seems to be the most performant? Because Chez won't be able to target your niche µarch and CL > R7RS-small when you're doing more than academic masturbation. Look at the implementations I mentioned (Bigloo, Chicken, Gambit), if you really want Scheme.

>>32777 >Forth can be very readable. It allows for abstractions that assembler does not, once bootstrapped. You could even upgrade from forth to a more powerful stack-based language like Factor. It is true that Forth can be readable, but its not readable by default in my opinion. It takes effort to make software that others can read and some languages make it easier than others. To me, Forth seems like it takes a lot of effort to make it readable. I am open to the idea of using Forth and Factor but I'm not convinced its the best option. Factor doesn't look like a mature language. Then again I just learned about Factor 15 minutes ago so I may be wrong. I am interested in what your opinion is. Do you think a Forth/Factor design would be a better choice for a system that runs on limited hardware and aims to substitute the use of a mobile computer (smartphone) for most mundane tasks like messaging, calendars, reminders, text consumption and so on.

>>32770 >uxn Read this: https://applied-langua.ge/posts/i-dont-want-to-go-to-chel-c.html Also, I joined their IRC and they kicked me after someone read more of my website, which I had shown to them, and learned I dislike glitterboys.

>>32779 factor was just an example of a stack-based language which one could imagine being written as an extension of a forth machine via metaprogramming

I just read Chuck Moore's interview about Forth in the book "Masterminds of Programming." Here are a few excerpts: >What is your opinion of compilers? Chuck: Compilers are probably the worst code ever written. They are written by someone how has never written a compiler before and will never do so again. The more elaborate the language, the more complex, bug-ridden, and unusable is the compiler. But a simple compiler for a simple language is an essential tool -- if only for documentation. >How should software be documented? Chuck: I value comments much less than others do. Several reasons: * If comments are terse, they are often cryptic. Then you have to guess what they mean. * If comments are verbose. they overwhelm the code they're embedded in and trying to explain. * Comments are often badly written. Programmers arent known for their literary skills, especially if English isnt their native language. Jargon and grammatical errors often make them unreadable. * Most importantly, comments are often inaccurate. Code may change without comments being updated. Although code may be critically reviewed, comments rarely are. An inaccurate comment causes more trouble than no comment. The reader must judge whether the comment or the code is correct. Comments are often misguided. They should explain the purpose of the code, not the code itself. To paraphrase the code is unhelpful. And if it is inaccurate, downright misleading. Comments should explain why the code is present, what it is intended to accomplish, and any tricks employed in accomplishing it. >How does teamwork affect programming? Chuck: Teamwork -- much overrated. The first job of a team is to partition the problem into relatively independent parts. Assign each part to an individual. The team leader is responsible for seeing that the parts come together. Sometimes two people can work together. Talking about a problem can clarify it. But too much communication becomes an end in itself. Group thinking does not facilitate creativity. And when several people work together, inevitably one does the work. >Proponents of many recent languages (notably Python and Ruby) cite readability as a key benefit. Is Forth easy to study and maintain in relation to those? What can Forth teach other programming languages in terms of readability? Chuck: Computer languages all claim to be readable. They arent. Perhaps it seems so to one who knows the language, but a novice is always bewildered. The problem is the arcane, arbitrary, and cryptic syntax. All the parens, ampersands, etc. You try to learn why its there and eventually conclude theres no good reason. But you still have to follow the rules. And you cant speak the language. You'd have to pronounce the punctuation like Victor Borgia. Forth alleviates this problem by minimizing the syntax. Its cryptic symbols @ and ! are pronounced "fetch" and "store." They are symbols because they occur so frequently. >You mentioned that a lot of Forth programs look like C programs. How do you design a better Forth program? Chuck: Bottom-up First you presumably have some I/O signals you have to generate, so you generate them. Then you write some code that controls the generation of those signals. Then you work your way up until finally you have the highest-level word, and you call it go and you type the go and everything happens. I have very little faith in systems analysts who work top-down. They decide what the problem is and then try to factor it in such a way that it can be very difficult to implement.

>>32780 Good article, the author's criticism of uxn and their VM as an alternative to mainstream computers is valid. Its a toy project and nothing more.

>>32789 >Chuck: Computer languages all claim to be readable. They arent. Perhaps it seems so to one who knows the language, but a novice is always bewildered. The problem is the arcane, arbitrary, and cryptic syntax. All the parens, ampersands, etc. You try to learn why its there and eventually conclude theres no good reason. But you still have to follow the rules. And you cant speak the language. You'd have to pronounce the punctuation like Victor Borgia. Forth alleviates this problem by minimizing the syntax. Its cryptic symbols @ and ! are pronounced "fetch" and "store." They are symbols because they occur so frequently. That level of damage control is laughable. First, nobody is a "profane" since mathematical notations (like fun(arg)) are mostly standardized around the world. Second, Forth has 100x the amount of syntax that Scheme has (and still more than CL, I'd say). Third, a decently sized and named stdlib is an important factor for readability, which ANSI Forth doesn't have.

>>32791 >Second, Forth has 100x the amount of syntax that Scheme has (and still more than CL, I'd say). Explain this statement. It's not syntax to shorten a commonly used symbol to a character, which is all forth does. CL and Forth have the following 'syntax' (if we are to consider such shortenings of functions syntax as we must to declare Forth has any syntax beyond symbols and spaces): CL has: - Quote (-) - Backtick (`) - Selective Eval (,) - Comment (;) - Named Argument (:) - Function Namespace Specifier (#') - Namespace Specifier (#:) Forth has: - Function Definition (:) - End Function Definition (;) - Print (.) - Start Comment ( ( ) - End Comment ( ) ) - Fetch (@) - Store (!) If you're confident in the simplicity of Lisps syntax outweighing the simplicity of Forths then I'd be glad for you to submit a parser for Scheme syntax (or CL if you're brave/insane) and I'll happily do the same for Forth (hint: Forths is literally just read->skip, lisps is much bigger since syntax is attached to symbols (e.g. 'foo -> (quote foo))) Note: I have a lot of Common Lisp experience but relatively little in either Forth or Scheme

>>32793 I'm not that guy, but your argument for Forth here seems weak. I'm not an expert, so I might be wrong about this, but I could make something that turns Scheme code into a list of tokens (atoms and macro chars) pretty easily, and it's not to hard to imagine that being executed as a valid, if backwards, Forth program. If I did that and then claimed all the Scheme reader needs to do is the tokenising you'd call it disingenuous. I'd say the same holds for Forth. It expands its reader macros at run time, but that doesn't mean they don't exist. Just because it (theoretically) expands its reader macros at runtime doesn't make it simpler, it just shifts the complexity around into an altogether less useful format. I would guess it's a lot more complicated to compile some Forth code than it would be for Scheme, and when I look at Scheme data I almost cry because of how beautiful it is. If I saw a data file in a Forth format I would cry for very different reasons.

>>32794 >If I did that and then claimed all the Scheme reader needs to do is the tokenising you'd call it disingenuous The issue with your example is that you can't split the macro characters and the atoms so easily, there is some amount of operation that has to be done to convert the expression `'foo` into `qoute foo` in the case of our imaginary program, the same can't be said for forth. Let's do some theoretical parsing: We have the code `'foo` and we want to parse it to a collection of function calls that the compiler can process. So we: -Read the token -See that it's a quoted expression -Expand it into a function call and an argument 'foo -> (quote foo) Now the equivalent in forth is: [ foo ] Now [ and ] are just 'start quote' and 'end quote' functions, so we have nothing to parse, we just read it the same as any other expression and carry on without transforming it. Perhaps clearest to you is let's compare a theoretical Forth eval vs SICPs eval: lisp (define (eval exp env) (debug-log "EVAL-ENTER" exp) (cond ((self-evaluating? exp) exp) ((variable? exp) (lookup-variable-value exp env)) ((quoted? exp) (text-of-quotation exp)) ((assignment? exp) (eval-assignment exp env)) ((definition? exp) (eval-definition exp env)) ((if? exp) (eval-if exp env)) ((lambda? exp) (make-procedure (lambda-parameters exp) (lambda-body exp) env)) ((begin? exp) (eval-sequence (begin-actions exp) env)) ((cond? exp) (eval (cond->if exp) env)) ((application? exp) (begin (debug-log "APPLICATION" exp) (apply (eval (operator exp) env) (list-of-values (operands exp) env)))) (else (error "Unknown expression type -- EVAL" exp)))) vs lisp (define (eval tok env) (debug-log "EVAL-ENTER" tok) (cond ((in-dictionary? tok) (if (or (interpreting?) (immediate? tok)) (apply tok) (compile-word tok))) ((number? tok) (if (interpreting?) (push tok) (compile-lit tok)) (else (error "Unknown tokression type -- EVAL" tok)))) Basically when the lisp reader sees a quoute (') it has to specially process it by splitting the token and expanding it based on the macro rules. Meanwhile forth macros (immediate words) are just functions tagged specially in the dictionary so that when they're seen they're run. Sorry if the explanatio

It looks like Forth seems to be the way to go for OP's tiny system for a micro controller size environment. While I am sure you can write an interpreter for another language in Forth, that seems to defeat the point. By defining new Forth words you basically create your own DSL. The words you define have no inherent performance penalty compared to the included ones. From what I learned about Forth today, that seems to be the intended use of Forth. The result is extremely fast applications on small systems. The Forth community is run by old heads who kind of established a separate computing dimension which they live in. They even have their own chips which they designed in a Forth program they made called OKAD. And that program is only 500loc, so they claim. I cant find the source code for it. I can see the potential for beauty in Forth programs. The application of Forth for this kind of project is worth exploring further. I think its time to start a Forth thread. That aside, I hope discussion of a free computing stack continues in this thread. Its highly interesting to me.

>>32796 >Basically when the lisp reader sees a quote (') it has to specially process it by splitting the token and expanding it based on the macro rules. Meanwhile forth macros (immediate words) are just functions tagged specially in the dictionary so that when they're seen they're run. Wouldn't Forth have to do the same thing for if? Say you have the code below, doesn't if basically have to do the equivalent of quote, but compiling each expression until the end is reached instead of reading it. 10 10 = if should-put-three if 3 else 4 then else 5 then I don't see the difference between calling read until a close delimiter is reached in [ foo ], and just calling it once in 'foo. (Unless the [] don't nest properly and [ foo [ bar ] ] is treated as the quoted expression [ foo [ bar ] followed by an extraneous ].) If anything, a closing delimiter makes the code more complicated. (define (read-quote stream) (list (intern "quote") (read stream))) (define (read-quote-delimited stream) (list (intern "quote") (for ((x (repeat (read stream)))) (if (end-deiliter? x) (break) (collect x))))) Indeed a language consisting of only an unlimited cons primitive would be very easy to read, but would look awful. ;; . a b = '(a . b) . define . . read . stream () . . define . token . . read-token . stream () () . . if . . cons? . token () . . cons . . read . stream () . . read . stream () () . token () () Macros in Forth also seem more complicated. If I wanted to define a cond for instance, not only would I need to define my own reading procedure to parse the structure of the cond, I would need to create different functions to handle compilation and interpreting. That's really stupid. Why should I care if my code is compiled or interpreted? I've just downloaded gforth to evaluate that Forth expression I wrote earlier, and if doesn't even work in the repl. It's "compile-only". Forth is a really nice concept, but every time I've seen anything remotely practical done with it it's just been ugly like that. As soon as you get away from applying functions to a stack, it seems to completely break down. Conversely, this is what's so great about Scheme. It's a simple concept that stays simple when you put it into practice. You could show someone lambda, define, quote, set!, defmacro, and cond then they'd basically have a whole lisp without a mention of interpretation semantics or anything like that.

>>32793 Yeah, I was wrong in including CL. Scheme still stands, though.

>>32796 I suspect you overcomplicates Lisp by specializing quote handling (and most of the syntax elements) when in reality, the reader just iterates over its reader macro table.

>>32709 Sorry for the delay in posting, got busy with life stuff. >Wouldn't Forth have to do the same thing for if? No, in fact almost every forth you use will define IF and other keywords in forth itself, see the link below for an implementation of the keywords (I would've shown the gforth one but I couldn't find it so this is the simpler jonesforth, if you'd like to understand forth more see jonesforth.s for a well commented implementation). https://github.com/nornagon/jonesforth/blob/master/jonesforth.f#L135 > Indeed a language consisting of only an unlimited cons primitive would be very easy to read, but would look awful. Hmmm, I'm not quite sure what you mean but forth almost does the same functionality in a way? Data being pushed onto the stack and popped by functions etc. I might need you to explain this idea more but I feel like if by a language of pure cons you mean a language where everything is just functions consuming arguments then that's basically all forth is, the stack is just a way to store information between those function calls (obviously the standard is a bit more complex than that, I mean traditional forths). > Macros in Forth also seem more complicated. If I wanted to define a cond for instance, not only would I need to define my own reading procedure to parse the structure of the cond, I would need to create different functions to handle compilation and interpreting. That's really stupid. Why should I care if my code is compiled or interpreted? What do you mean by this? To evaluate a macro you write code to explain the form to lisp (just masked in the backticks, quotes, commas etc.) and in forth that's largely the same, though you use the special functions instead. The difference is these functions are the same as any builtin function like adding, they hold no unique syntax or properties. > As soon as you get away from applying functions to a stack, it seems to completely break down. Well you should never get that far from it, forth is all about writing small functions that do clear manipulations explicitly so you don't end up in a horrific mess with all the tools available. That's why it holds all that philosophy about small functions and things, you can critique that but the intention is the programmer uses such techniques to prevent things breaking down, it's a bit like C in that way. > I've just downloaded gforth to evaluate that Forth expression I wrote earlier, and if doesn't even work in the repl. It's "compile-only". That's what the standard dictates it should be. Forth philosophy dictates you probably shouldn't want an interpreted IF anyway. >>32800 > I suspect you overcomplicates Lisp by specializing quote handling (and most of the syntax elements) when in reality, the reader just iterates over its reader macro table. The snippet for the scheme evaluator I used was from SICP, it's literally meant to be as simple as possible. If you can provide me the more compelling reader macro solution I'd be happy to see it, but I imagine that is far greater still than the simplicity of parsing forth, which I showed above (and far larger too if we want to use that metric rather than understanding). Furthermore that couldn't be the implementation for Scheme really, since it lacks reader macros (largely, there is something in the standard I think but it's seldom used and not real read macros), not in a pleasant way anyway.

>>32717 >>32813 >>32789 excerpts from Forth creator Chuck Moore's interview cont. >... you have a very small kernel that's very much tied to that hardware. Its interesting how Forth can bridge that gap between the two. On some of these machines is it true that you have no operating system besides your Forth kernel? Chuck: No, Forth is really standalone. Everything that needs to exist is in the kernel. >But it abstracts away that hardware for people who write programs in Forth. Chuck: Right. >The Lisp Machine did something similar but never really was popular. Forth quietly has done that job. Chuck: Well, Lisp did not address I/O. In fact, C did not address I/O and because it didn't it needed an operating system. Forth addressed I/O from the very beginning. I don't believe in the most common denominator. I think that if you go to a new machine, the only reason its a new machine is because its different in some way and you want to take advantage of those differences. So, you want to be there at the input-output level so you can do that. >Kernighan and Ritchie might argue that for C that they wanted a least common factor to make porting easier. Yet you found it easier to port if you didn't take that approach. Chuck: I would have standard ways of doing that. I would have a word -- I think it was fetchp maybe -- that would fetch 8 bits from a port. That would be defined differently on different computers, but it would be the same function at the stack. >In one sense then, Forth is equivalent to C plus the standard I/O library. Chuck: Yeah, but I worked with the standard FORTRAN Library in the early days, and it was awful. It just had the wrong words. It was extremely expensive and bulky. It was so easy to define half a dozen instructions to perform in I/O operation that you didn't need the overhead of a pre-defined protocol. >Chuck discussing operating systems Chuck: An operating system does absolutely nothing for you. As long as you had something--a subroutine called disk driver, a subroutine called some kind of communication support, in the modern world, it doesn't do anything else. IN fact, Windows spends a lot of time with overlays and disk management all stuff like that which are irrelevant. You've got gigabyte disks; you've got megabyte RAMs. The world has changed in a way that renders the operating system unnecessary. >What about device support? Chuck: You have a subroutine for each device. Thats a library, not an operating system. Call the ones you need or load the ones you need. >after answering an unrelated question Chuck makes this remark about operating systems: Chuck: The operating system is another concept that is curious. Operating systems are dauntingly complex and totally unnecessary. Its a brilliant thing that Bill Gates has done in selling the world on the notion of the operating systems. Its probably the greatest con game the world has ever seen. This short article from Brian Will remind me of what Chuck said about operating systems. His take on how he might redesign the operating system is very interesting. In particular his idea of replacing the file system with a file server/database is exactly what the betrusted project is doing in their OS. Betrusted is doing it for security reasons, but as pointed out in this article, there are other practical uses for redefining the way things work. >inb4 plan 9 Im talking about computers with offline use being a first class citizen. Networked resources between machines is not something I am interested in exploring for personal computer applications. https://medium.com/@brianwill/unix-userland-should-be-replaced-5605fe47cac0?source=user_profile---------4---------------------------- It continues to frustrate me that I can not ever understand how things work. When things break its a roll of the dice googling, and if no one else solved your problem with X, then you are out of luck. I NEED things to be simpler, more regular, and more minimal in their design. For example I need to use VSCode for work. A plugin stopped working. That is not something you can fix yourself, and the documentation for doing what that plugin does manually are sparse. There are so many tremendously large moving parts that made it work, it is simply impossible for me to fix it myself. If there is even a slim chance I can escape this by making a digital home with Forth, then thats where I want to go.

>>32814 >For example I need to use VSCode for work Why do you? Could use Emacs, which is much more "internal rummaging" friendly.

Rolling your own system with Forth is possible, but its unlikely to find success. Even if its not as close to the metal, using something like a RTOS thats already developed and mature is the obvious choice. (Also might want to check out Contiki) The Pinetime smartwatch from Pine64 has similar specs to what you are aiming for. 512Kb memory, a small ARM core, a 240x240 display, 8Mb of storage. Look at what they run on that. >ZephyrRTOS >FreeRTOS >RIOT Its just a watch so it doesn't have the most fully featured applications, but it demonstrates that its possible. The issue I see with this is that its not designed as a stand alone OS. You compile the image and flash the device. It doesn't have the tools to build itself. You need another machine with gcc and other dependencies. What you need is to put PCC and a text editor on it. If that exists, I haven't seen it.

>>32841 The issue that you see already shows one way in which that approach fails to meet OP's requirements: - it does not survive collapse: the hardware is too complex to be manufactured, and the software, as you say, requires a different machine and several GBs worth of dependencies to be built - it does not foster sovereignty: same as above for the hardware, and as for the software, the OS is not readable and modifiable from within itself

>distributed manufacturing Bump. This is a really good thread.

>>32709 Really interesting thread, but your point is honestly retarded (which is completely expected for an American living in most overabundant society ever existed) Chip manufacturing is a process of mind-blowing complexity (yes, even for thick techprocesses) and it is not achievable in a post-collapse environment. Once it it gone, it is gone. Sam Zeloof's argument is invalid: have you seen his videos? He uses modern and expensive equipment to achieve modest results.

There has been some pretty good discussion over the lifetime of this thread that still deserve resolution, so I'm going to try to distill it down as a baseline. In broad strokes: >We all agree that it would be nice to have a public domain effective alternative to today's rube goldberg commercial silicon so that a minimal number of committed anons could manufacture for themselves instead of needing to follow the whims of the big players. >Modern devices are so complicated they're strictly impossible to manufacture at anything beneath a massive scale. Fortunately, it seems O(n) product complexity requires O(x^n) manufacturing complexity, so if we stripped away the hardest 20% feature requirements we'd save 80% process difficulty. A pre smartphone era PDA would probably make a good target as both a sovereign tech demonstrator and a useful product. >That said, it's currently impractical to imagine starting "from scratch". Materials and tooling for ICs are just too wide of a scope for a project focused on minimal complexity. The best compromise is to look for comparatively cheap ready-made products from niche industrial suppliers to bootstrap, which fortunately there are several to choose from, and evolve the working process away from them over time. The same applies to non-silicon hardware, in the nuts-and-bolts sense; there should be a focus on simplification, but manufacturing displays, capacitors, and tiny screws each require their own equipment and process, so we have to assume they're just available for now. Who could have guessed SHTF-level computer manufacturing would be so complicated? >As if that weren't bad enough, Rev1 of the chip will also probably have to compromise between innovative elegance, implementation effectiveness, and creation effort. Because even commercial products often fail to hit all three, an open design worth the effort will be a bit of a trailblazer. No one wants a system that lets any of the trifecta of good, fast, and done to fall by the wayside, so balance between them to keep the whole thing in scope is the order of the day. Just plan to carry an external battery for a while if power-efficiency isn't at intel level. >There is some disagreement about whether a truly spartan system or a minimal sister design of today's interface will provide the best overall experience. The latter might be to big and difficult to create and run efficiently, while the former might not give the user the power they want without more effort to pile their own code on top. What's worse, it's not clear how to tell who's right, except that splitting the difference here will probably give the worst of both worlds. (Perhaps the solution is to build up prototypes of both in parallel, so each version can focus on what it does best? Probably simulate them? Then we try both and pick the one that's most promising.) There's also disagreement on what technology architecture to use, but here it'd probably be best if we just chose the one with the most support to avoid fracturing resources that could be shared in the same system. >There's also discussion of what existing tech should and should not be valid candidates for this project, but this seems as much an artifact of poorly-demarcated goals as of the strengths/weaknesses what's been proposed itself: What, concretely, is the right level of "simplicity" and "sovereignty" to make the project both realistic and worthwhile? A glorified Raspberry Pi you solder yourself with ten million lines of Linux source is way too much, and a remake of the old eight-bit BASIC interpreter without a text editor is way too little, but there's also way too much in the possibility space in-between. Can we reach a decent consensus on a tight enough range make it possible to list out the remaining options, debate and pick one, and get moving? How's it looking so far? Anything worth adding?

What exactly is preventing us from building a portable desktop version of something like that: https://www.asml.com/en/products/duv-lithography-systems/twinscan-xt-400l ?

C is the lingua franca of tech like it or not. If you want to do anything that isn't a toy you'll use C89. Simple, not-optimizing C89 compiler is not hard to make. And not that hard to bootstrap. You can of course make user application with anything you like, but your core has to be C89-C99. Is it fun to make your own stuff? Absolutely. Is it fun to experiment in your favorite obscure/archaic language? Hell yes. But I was under the impression that you guys were talking about practical software for the theoretical system you want to build. Given the "low" tech hardware you are aiming for, anything but C with optimized assembly for bits that need to be responsive is just waste of cycles of said underpowered (compared to $current_tech) hardware. You can throw away C, and just use the assembly, that is a valid choice too. But having a high level language of any kind is obvious win for development speed. I anticipate a lot of Lisp and FORTH fans to go ahead and trash on C after I post this. Yes, C is very flawed language, but if you want to reuse as much as u can from the open-source scene, it is a clear choice. Again, it depends on the goal, if the goal is self bootstrapped toy system, use whatever you want. If the goal is to the most practical "low" tech system u can muster, C.

>>38238 I think you have it backwards. C is necessary to re-use components, so you need to support C at some point, but the base can be anything.

>>38240 I think that's also where he is going at when he mentions this line. >You can of course make user application with anything you like, but your core has to be C89-C99. It's not really difficult to start a project without even knowing you are using tools built with a C89-C99 compiler (and, by extension, will require you to use a compiler using code that originates from it at its core as a base)

>>38238 Frankly, I have to agree with this guy. When it comes to low level development, I don't see why you wouldn't use C. It's an old/stable language, and it gives you direct access to hardware unlike anything you find in high level languages. There's a compiler for almost anything, and if there isn't, it's not too hard to make one on your own. The only real alternative I see is writing everything in assembly. Although it sounds daunting, it really isn't quite as impossible as everyone makes it out to be. Until the mid 90's, almost all video game development for consoles was done in the specific assembly for the processor, and the people back then still managed to make it work. They used to call C portable assembly, so if you don't care about writing cross platform compatible code, and you don't want others to be able to easily understand it, I don't see why you couldn't just do everything in assembly and see how far you can get. If I was going to embark on this whole endeavor (and who knows, I might), I would start out implementing everything on an ESP32 or something. None of the things you have suggested seem particularly processor intensive, so I doubt you would be using even a fraction of the resources of even something like that. You could just keep scaling down as appropriate until you have reached a point you think is minimal enough. In some kind of "collapse" situation, I would focus more on trying to reuse all the microchips we find in modern electronics, like toasters and who knows what, but I would be interested to see what an individual could make on his own.

>>38238 Hence I'm learning zig. I know, sure, shiny new toy problem. But so far it checks my current boxes except the current async regression in 0.11.x. But it interacts well with existing C code and elixir (thanks to the chad who made ziggler) so I don't have to learn much erlang either. So I rather put my eggs in that basket rather than to refresh my C and go neck deep into all the intricacies that it needs to still handle things meant to run on the tape based computer it was invented on. And I wrote my fair share in it a good while back. An entire game rendering engine at some point. >were talking about practical software for the theoretical system you want to build Of course there's still Holy-C and TempleOS/ZealOS. That's as far as anyone seems to have gotten in terms of that objective. >>38248 >The only real alternative I see is writing everything in assembly Based Roller Coaster Tycoon enjoyer. No other game of that scale ran fluently on my Win98 machine back then.

>>38238 >>38248 The issue with low-level languages like C and especially assembly is that mediocre-to-bad programmers have trouble reading them, and if your goal is for the user to have complete, or at least as close as practically possible to complete, knowledge of and control over their computing environment, that's a problem. I'm not saying you can't or even shouldn't write the low-level, core components in a low-level language like C or even assembly; you pretty much have to (literally, in the case of Assembly). But in this specific scenario, you want to get away from them as quickly as possible. Otherwise, you just end up with what we have now but better optimized. >>38259 Stop actively looking for people to get mad at on the internet. It's awful for your mental health.

Sadly, I doubt backyard fabbing will take off in the near future unless someone makes it as easy as using a 3D printer. It's not just the lithography: you also need wirebonding, packaging, and verification. It's a lot of investment (materials and R&D) for lackluster results. Sam's 5um garage fab is roughly equivalent to what we had in the 70s. Maybe I'll be able to make my own z80 at home in my lifetime, but for now I'll just buy COTS hardware and not worry. >>38248 >When it comes to low level development, I don't see why you wouldn't use C >it gives you direct access to hardware unlike anything you find in high level languages You wouldn't use C if you don't like it, and it doesn't give you direct access to the hardware it has a mental model of a 1970s machine. Even with chips following a "runs C good" trajectory there are a lot of developments it didn't capture like increasing parallelism. There are plenty of "high level" (not a useful taxonomy IMO) languages with code generation quality equal to C these days. The main thing C has going for it is a a stable and simple ABI. Assembly is still useful to know to verify your generated code, but you're not going to be writing it directly unless you work in Operating Systems or Compilers.

>>38259 Hi. I'm been lurking this thread but as someone who has also been interested in learning Zig could you please expand on your reasons ? From what I've read and seen async has been postponed indefinitely.

>>38274 Not him, but it's the only C successor with any momentum that understands what makes C good, which is that it's a) low-overhead, and b) gives you a reasonably good idea of how your code will translate into machine code.

>>38248 >In some kind of "collapse" situation, I would focus more on trying to reuse all the microchips we find in modern electronics, like toasters and who knows what, but I would be interested to see what an individual could make on his own. Unfortunately almost all of those are going to be running off of a mask ROM or PROM burned permanently at the factory. It would be interesting to try and see how many of them are actually reprogrammable, but probably the answer is "few".

>>38265 But see, that's the problem. I just get out of the door and I already step in it. If anything I'm trying to avoid it, but to no avail. Anyway, did you feel called out? My advice is to not take things to personally or too seriously. Having a laugh is good for mental health. To your other point, nobody will care about your thing if it's slow. Put effort into the architecture design and filter out all the web scripters from the contributors. Like I've said, TempleOS pretty much had it, whether you agree with the author's views or not. There's a natural barrier of entrance for each language but how the code is structured is just as if not even more important thus in theory low level should be fine. But the project then also requires someone who's driving it and keeping it "pure". Maybe there can be an other way to achieve that like a cultish guideline which will be adhered to long enough to get the project done before the community inevitably implodes. >>38271 >expand on your reasons Me simply needing something that's covering the same niche as C but with the least of its flaws which will never be addressed within C. Due to it, as one poster already pointed out, being hopelessly stuck in the 1970's. Don't get me wrong, C is still very important, so much so it will likely outlive the zig project on sheer momentum alone. But imo it's really for legacy, tooling and maintenance reasons more than its "ergonomics". For instance no new language, except maybe web assembly, requires you to declare all your variables at the beginning of your methods. Or having the need for headers or include guards. Arrays and pointer arithmetic is nice in C and less cumbersome but that can open up your application to buffer exploits. Same with zero terminated strings which hardly anyone considers good practice today. Zig solves those issues by using length values instead while adding a "sentinel value" that allows it to interop painlessly with existing C code. So I'm also not missing out on all the existing C libraries. Then likewise the malloc equivalent is more boilerplate in zig which is not as nice on it's own but allows it to really be a system agnostic programming language and for once play well with erlang's BEAM vm, thus elixir integration which also interests me greatly for other projects. It's true you can use C for this too but you need to have a very good reason for that since if you die in C, you die in the BEAM too and pulling the whole system with it, making its entire point moot. Do I even need to talk about the C "macros" and how comptime makes meta programming so much less of a mess? There's a bunch of other small details here and there with an active and fairly competent dev community behind it, which is a plus. And it clearly is a nicer low level system's language without having to wrangle some borrow checker. I can throw together code for my concepts and projects quickly and well performing and nicer due to features like defer to ensure handling of deinitializations. The project got a "zen" but it sounds like some marketing babble, though from some interviews where Kelly's being a cheeky cunt, his statements are reassuring that the point of zig is to be a tool to handle tasks like data processing fast and on any platform they've got a compiler for. Things like them removing veriadics and never putting them back in, in favor of tuples, is something that's in line with that vision. But that also means each update takes as long as it takes and there's often breaking changes so I wouldn't suggest you to "learn" zig, as in studying it. Rather just try and use if for a project that requires something like that and otherwise await the 0.12 version which releases god knows when. And breaking async also was a bummer but while it's a nice way of doing some things it's still a bit of a mess in regards to program flow so it makes sense they took it out. But if there's not a good way to handle concurrency in any meaningful way and without needing to do the boilerplate like in C++, it's gonna be a deal breaker for me long term. Other than that I genuinely considered holy C since that did have some improvement to the syntax, however tooling was lackluster and the passing of the primary maintainer also pretty much was the end of that. Ofc there's now other contenders like odyn, which seems similar but doesn't really fit what I'm looking for and having undefined behavior in some places despite having a simpler feature set. There's carbon, which I don't know is even available yet but if it was and also was the best designed language on the planet I'm still hesitant as I don't want to get trapped into google's eco system and their go-routines. There's nim and jay or what's the name. Do these projects even exist in any meaningful way? "Mojo" is apparently a thing now which is a much faster python but still python. There's Assembly Script, which seems alright but geared towards web devs to write wasm code and also is only limited to said runtime. I'm also too smooth brained for going raw assembler so yeah, that's what reduced my choices that are basically just me hoping they don't ruin zig with any nonsense or drama like at the language where people needed a crab mascot because the thought of oxidized metal was too much to bear for some. Man, modern programming language design is weird. >>38278 Funnily enough while those rentable e-scooters were still new and companies didn't have dedicated hardware yet, some people would keep cracking open the electronics to steal the arduinos. There were entire guides on that circulating online. Now I don't feel much pity for those businesses but it is like kicking dead whales down the beach it's either that or mountains of e-waste because we can't just have anything repurposable and moddable.

>>38244 >It's not really difficult to start a project without even knowing you are using tools built with a C89-C99 compiler Yes, it's very easy to pollute your bootstrap environment on accident. That was one of the things I forgot to mention in my rant. Thanks. >>38248 >I would start out implementing everything on an ESP32 or something. Since we don't have the theoretical platform using cheap, commodity microcontrollers are a good idea as an initial target, at very least for practice. >>38265 >The issue with low-level languages like C and especially assembly is that mediocre-to-bad programmers have trouble reading them Two things. First, get good (no but really, otherwise you'll reinvent the web with its JS ridden hell hole of a tech stack, eventually). Second, FORTH and LISP will be even harder to read for many people. I will, of course, concede that it depends on your "upbringing". If your first programming language was C-like it's going to be easier, but if your first language was Lisp, then it's going to be harder. I think it's safe to assume most people are more used to C-like syntax these days. To circle back to my first point, if you're good (enough) the language syntax and conventions will be easily learned. Just spend the time and care, so really it's a non-issue for any thinking human bean. >>38271 >Sadly, I doubt backyard fabbing will take off in the near future unless someone makes it as easy as using a 3D printer. I have to agree, I do not see this either. Hence I like the idea of reusing mass produced microcontrollers and SoCs. If u can pull a µC from your old washing machine and build a device with it, that's good enough for me. Speaking of, I really need to get a reflow oven or at least a hot air gun. >>38271 >it doesn't give you direct access to the hardware it has a mental model of a 1970s machine. That's true and not so true. Yes the pure C standard (any) does assume contiguous memory, more or less 1 thread of execution (yes C11 bolted on threads and atomics), and has weird assumptions about integers. (C's undefined behavior is it's greatest weakness IMO). That said, no real program written in C is portable ISO C. Why? Because every platform will require you to use its implementation defined behavior. Be it high level stuff like OS API/ABI or CPU intrinsics that let you use SIMD or your special signal processing accelerator special sauce instructions. The (relative) simplicity and power of C coupled with ease of extending the compiler to provide platform specific things is what makes it such a good choice for embedded, and backbone software. You can #ifdef (or better yet #include separate files) the implementation depending on your build target and have best of both worlds. Is it slightly archaic? Perhaps. Does it work? Yes. So to summarize my point, because I know I am very rambly (sorry), While base C does not provide you the view into modern processor, in practice every implementation does (to a degree). With C you can just define some memory mapped register addresses and then read/write into them, you can have intrinsics in the compiler (that in our theoretical scenario we develop and own) that provide you ways to basically code in assembler with C semantics. No other language combines all these properties, as well as, have these properties proved by decades of use. >>38259 >>38274 >Zig I was excited for it, but it started deviating from what makes C good in favor of the "shiny". That is my personal opinion, so do with it what you will. More practically, it is as of yet (as far as I am aware) not bootstrapable. But I do know that they are working on zig zigging zig. >>38278 >Unfortunately almost all of those are going to be running off of a mask ROM or PROM burned permanently at the factory. As someone who worked in embedded/IoT, I can assure you there is plenty of soykaf one offs that are built with some ST micro and a SPI EEPROM or flash. The actual problem is that anyone even slightly competent will blow efuses in said ST micro upon burning the release version of their firmware. But IoT is(was?) full of incompetent vendors. Even so, you can still make them run your code if they ever execute from RAM, provided you hacked them. So not really a viable method for scale perhaps. With more powerful SoC like the ones u may find in commodity routers this is easier, as the flash that holds the code is external and even if locked, can be at least replaced. Or they are running uboot and you can just flash your own code on it. The problem with many a SoC is actually in getting the documentation for it, which is easier for microcontrollers. Case in point though, DooM on variety of hacked IoT and other embedded devices. Finally I would like to reiterate that even though I am obviously pro-C, that doesn't mean that experimenting with alternative languages is bad. I don't want to discourage anyone (unless you plan to use soykaf like JS or Java, or Python, please reconsider). In fact, if I were to magically have a fab the size of a 3D printer in my room, I would very likely make my own C-like language that keeps the good sides of C while removing bad parts, and perhaps adding an itty-bitty of "shiny" in the form of defer() and more consistent syntax. (In fact I might do this without a magical fab device, but instead with some retro chips)

>>38282 You're correct, that while school book C may be surprisingly abstract, it's with intrinsics of "in the field" C and C++ that one can get down to bare metal just one thin layer above assembler. Anyone having even just basic experience in the demo scene can surely attest. I've not seen any of that in zig yet since my current use case it some data crunching library rather than anything operating systems related and for that it's pretty good and indeed more nice to work in than C. I've seen a couple projects aiming at micro controllers as a target. Whether they're just piggybacking on some arduino framework I don't know however. >it started deviating from what makes C good Could you elaborate on that? My intent is not to have a programming language war. Rather I'm always in an evaluation process of what tools are out there. And thus far zig has displayed aspects that make it safer and more pleasant to work with that good old C. And for the question at hand it seems like a very decent contender, especially if it's not replacing C but rather is paired with it. I believe it could make such a code base relatively "clean and nice" despite being very low level in part thanks to some modern concepts and compttime features. But then you also mentioned Lisp and many who have used CL somewhat regularly would likely promote that as the goto but I haven't worked with any of that so I can't make a quality or suitability judgement. Imo when it comes to C++ however, anything that needs it probably can be substituted by something else. And I'm not talking about Rust as its main benefit in practice is to set a given piece of code "into stone". If you want a system that's easy and quick to modify then it's the wrong tool. But what's your thoughts on runtime based systems like with elixir or kotlin when used for anything "higher level"? Are you in the camp of compiled or bust or that technologies should be leveraged to make up for each other's shortcomings? >they are working on zig zigging zig I hope to see this within my life time.

>>38280 The whole point of sovereign computing is to have something where you can do everything yourself and what "the community" does is completely irrelevant. Ideally, a user should be able to create everything they need all on their own with just the things built into the system.

>>38288 If the expectation is that you should be able to do everything yourself and get the same productivity as people who exploit division of labor then that is just a fantasy. You have to remember you are not immortal. Your must limited resource is your time so most people will obviously optimize for that.

>>38289 Okay, but what's the point of "sovereign computing" when you don't have sovereignty over the whole system? At that point we're back to where we started!

>>38288 Ok, sure. Anyway how's your calculator made of rocks going? But since there's no single person who can build a modern computer from start to finish, it really then comes down to making what we have more reusable, efficient, elegant and more accessible. In hopes to push the boundaries of practicality, though I believe there's surprisingly a lot of wiggle room in that. With brilliant individuals doing things on their own and what teams of people managed to pull off. I believe this whole concept, if we stray away from a pure interpretation, is of collaborative nature if you wish to get any utility from it.

>>38291 >Okay, but what's the point of "sovereign computing" when you don't have sovereignty over the whole system? At that point we're back to where we started! What's this got to do with me? You're the one who has to figure out what you want. Yes you can build your own transistors and then nand2tetris your way to an 8 bit CPU that can run a calculator app or something. You need to be realistic about what you can actually achieve and how much of your life you want to waste on it.

>>38291 is it only "sovereign" if you, personally, have complete sovereignty over the system? I have always thought that the point was to build tech without relying on huge centralized corps. What does that even mean, if you're going to such extremes? Do you have to mine your own silicon?

I wouldn't want to build my own computer to play skyrim on it, but it would be good for encryption. I don't care if my message goes over sms on an iphone as long as the plaintext and its encryption process was handled by a secure device. This would be my use case for such a thing. I think it should be a lot easier to make a device dedicated to encrypting and decrypting rather than something for general computing. Especially if you aren't overly concerned with speed.

rambling ahead I've been wondering how to deal with this "Tower of Babel" and I believe it's best to first identify the fundamental things we need, then figure out some general principles how to best achieve those. Computers nowadays really serve two purposes, the first obviously being computing, the second being communication. Achieving computation isn't very difficult, see the plethora of homemade CPUs. Most of the complexity nowadays is to achieve very low latency and high efficiency but increasing throughput can often be done by simply having more processing units. Realistically you probably won't be making your own CPU from discrete components but instead use a microcontroller which are much easier to produce than high-performance processors. I doubt that at this point we'll ever run out of MCUs barring a mass-extinction event. Communication is a lot harder problem IMO. Achieving it between a small number of computers isn't very difficult, but scaling it up becomes very complex very quickly, especially if you need to deal with malicious actors trying to disrupt communications. Yet this is probably the most important role of computers nowadays. Access to information is very valuable. For the latter, we already have the internet, but we rely on large, central "benevolent" entities ("Internet backbone") to keep it working and just a single entity to hand out addresses to literally everyone (or hand out a prefix and delegate responsibility for it, but still). The entire thing works globally pretty much entirely on goodwill. Many claim the internet is robust but while it may be so on a technical level I don't believe it can deal with actors who deliberately seek to disrupt it (see "Pakistan YouTube block exposes fundamental Internet security weakness" for example). There are some projects that try to address it, especially meshnets like Yggdrasil. From what I can tell none of these projects have figured out a solution to sybil attacks however, at best only having some mitigations in place. There is nothing preventing a bad actor from flooding routing tables (or equivalent) with useless information, grinding the network to a halt. I've been thinking about the problem for a while and I think the solution(s) boils down to making a distinction between entities you trust and those you don't trust. We can start by creating a network with people in your own clique (L0), where you trust none will attempt to disrupt the communications in the network. To create a larger network tunnels/bridges can be established between each subnetwork (L1) with appropriate restrictions. Even larger networks can be established by joining those L1 networks (L2), and so on (L{3,4,5 ...}). For addressing someone/-thing in L0 we can use a single label like "Bob". To address someone in another network we can append another label like "Bob@LainNet" or "Bob@LainNet@Wired". Very similar to physical mail. These identifiers don't need to be globally unique, another subnetwork might know "LainNet" as "AliceNet" instead and it wouldn't matter as long as it is reachable. The final challenge then is discovery/exploration so we can actually do anything useful on foreign networks. I believe the best solution is an "address book" mapping human-friendly identifiers to computer-friendly routes. If two networks agree to establish a tunnel they can update their local address books to have a route to each others address book. Much like DNS today. These address books can also include cryptographic identifiers and signatures to help ensure communications are secure even if eavesdroppers are present. ----- With all that said, to achieve "sovereign computing" I think the best thing to start with is with an ESP32, which is a very cheap, very common and very capable MCU with WiFi. I intend to build my own WAN network with it though I've been struggling to figure out how to power it cheaply (without relying on the main power grid). Solar + battery is easily more expensive than the MCU itself.

>>38292 >But since there's no single person who can build a modern computer from start to finish The only reason why nobody can do that is because nobody can manufacture modern microchips from start to finish. If only you could do that, you would be basically done. The rest could be done with a basic 3D printer with 1 normal filament and 1 conductive one. So chip manufacturing is what we need to focus on. I was wondering: is there any process of micro/nanofabrication that does not rely on giant apparatus? >this whole concept, if we stray away from a pure interpretation, is of collaborative nature if you wish to get any utility from it. You're correct, but the ultimate goal of that collaborative effort should be to come up with something that could be replicated individually.

>>38383 this is what we should strive for

>>38383 >the ultimate goal of that collaborative effort should be to come up with something that could be replicated individually I don't think that's an achievable or worthwhile goal. I don't care if I personally can fabricate a microship for the low price of $100k, I care if my buddy George can set up a microchip foundry and provide me with all my silicon needs.

>>38405 Is your buddy George a billionaire? Because with the state of things right now that's the only way he's ever setting up a microchip foundry

>>38411 ...yes, that's my entire point, George should be able to do it with only a relatively small investment (thousands instead of billions) and a few workers. That, as I view it, is the entire point of 'sovereign computing'. The idea that an individual person would be able to 3d-print a computer without any super-expensive and specialized equipment in the near future is a pipe dream. The idea that a small company could run a silicon fab is not.

>>38413 honestly maybe thousands is still a bit optimistic, maybe George would need to scrounge up $10m if we include stuff like renting some industrial space, electricity, buying pure enough silicon, etc. That's still way less than it takes to build a new fab right now, and there's also the intangible barriers such as secret technology that companies like TSMC and intel hoard which we could do away with if we did enough open source R&D.

>>38405 >I don't care if I personally can fabricate a microship for the low price of $100k 3D printers once costed thousands of dollars too, now they can be found at around 1 hundred $

this thread inspired me, I found this PDF maybe somebody could try this.

>>38414 >>38413 >>38384 >>38383 Organic thin film transistors used in flexible electronics show lots of promise for small scale and on-demand IC production. They're made entirely out of liquid polymer inks and can be inkjet printed(not a conventional printer, but a damn sight simpler and cheaper than a silicon wafer fab) or even reel to reel mass produced with stamps. Several research papers exist showing the successful creation of microprocessors with up to 32 bit capabilities in only square centimeters. Naturally thin film is actually most known for it's use in oled displays and touch sensors, so it's possible to imagine creating an entire device out of them, even integrating printed solar panels for maximum post apocalypse vibes. Because of the nature of such a process, it's naturally best to settle on a design, as manufacturing is either extremely slow(imagine hand drawing each individual gate with a needle) or inflexible(engraving metal transfer plates for reel to reel production) To that end I think the ideal area to spend time on is FPGA simulation. Basically, develop the software and hardware at the same time. As a bonus the common downside of FPGAs, limited space/performance compared to ASICs, just lend an air of realism to the process as it's doubtful any printed organic processor could ever match a silicon FPGA and would probably have to rely on external memory anyway(DVDRAM anyone?)

I've mastered the computer, but at the cost of myself.

>>38443 3d printers are not chip fabs. It's a bit silly to expect the cost of one thing to go down just because the cost of a different thing has gone down. I really don't think it's much of a downgrade to go from "making my own 1 MHz CPU in my garage" to "making a 10 MHz CPU with only a small company". Compared to the only ways you can make CPU's today, with globe-spanning supply chains and multimillion-dollar machines, and all of the very real and very big engineering obstacles that need to be overcome, I really don't think it's much of a difference at all. As a bonus, companies like intel were once small too, so we know for a fact it can be done. >>38473 based AF lain. I'll read this when I get home. >>38640 hmm, since they're organic wouldn't they have pretty bad operating temp limitations? They might have to be clocked so low that they're almost useless. FPGA's in particular tend to have not-great thermal properties.

>>38790 >operating temperature issues A silver lining of the much increased feature size is much less of a thermal problem. More surface area for the same amount of heat. I haven't heard of any major thermal issues but then again this isn't exactly the field for high performance computing, if you're trying to overclock an OFET why not just buy a REAL computer? Looking into it I've seen a few papers on implementations of entire 8 bit CPUs already. Even aside from that, just the ability to make high resolution touch screens out of them is useful, no matter how you try an FPGA can't actually interface with a human directly and you're going to have to buy the screens. With this it's entirely possible you could 3d print a case, make your own home made batteries, and manufacture your own CPUs, meaning a true 100% in house computer made from scratch out of chemicals. Unless you want to open up an oil refinery you're not going to get closer than that to self sufficiency.

>>38640 This sounds fuarrrking great, do you have some links about?

>>38862 Here's a good one: an 8bit all plastic ALU made in 2012 with comparable performance to the first silicon ALU. https://sci-hub.st/http://dx.doi.org/10.1109/JSSC.2011.2170635 I just googled around for papers on "Organic Thin FiIm Transistors" and ran them through scihub. And it is awesome, the only issue is it's "every component has been done at least once in a lab" stage. So, given that you're not exactly making these things by hand, it's definitely POSSIBLE to manufacture an entire cellphone in your garage(or more realistically a small factory) It almost certainly would require a very large amount of technical knowledge, a high failure rate, and a lot of expensive materials. Un/Luckily there's almost no commercial market for such a device so it'd have to be an entirely passion/libre nerd project anyway which fits at least half the bill. I'd say it's probably currently on or slightly above the level of those guys who home made their own silicon transistors in time/money investment but with the ability to produce a lot more useful products.

>>38868 >https://sci-hub.st/http://dx.doi.org/10.1109/JSSC.2011.2170635 Ok I get that manufacturing an Intel core i5 in your room is probably a little much to ask for, but Jesus Christ, if the best these things can do now is orders of magnitude less than a '70s microchip, this is clearly not the way

>>38880 https://sci-hub.st/https://doi.org/10.1002/advs.202001098 Here's a later paper from 2020 about a new design of OTFT that can operate at 160MHz, only an order of magnitude or so away from a real computer. Also don't discount the utility of "slow" transistors either. Remember these tings are also good at sensing and can be made into LEDs. Even 40 operations a second is actually more than enough for a display/interface. Not to mention the applications for transistors that doesn't even require that much speed like solar panels. I mean think about how useful being able to make your own solar panels is! It's already easily at the level of manufacturing a solar powered electronic calculator from raw materials, can easily push it's way into a word processor role, and can entirely replicate a flat panel touch screen television, that's nothing to sneeze at!

>>32711 >Already, this seemingly simple requirement brings in ASCII, Unicode, UTF-8, IP, TCP, HTTP, and likely also the ever-moving target named TLS. Does that seem simple? Forget this, all involved are reasonably simple. What's not simple is the problem in the first place: the physical layer of computer networking, which is far less open.

>>32773 >smallest Lisp has been implemented as pure lambda calculus in under 500 bytes. Not kilobytes mind you, BYTES. Naturally this is somewhat of a toy implementation and is just an interpreter, but even an interpreter can run arbitrary code, including direct generation of assembly which rapidly allows it to become a compiler. As for low/high level, I don't think any language is as high OR low level as lisp, as it runs the complete gamut of being almost literally the definition of computing itself in abstract mathematical terms and also the originator of almost all high level functional programming abstractions. As for operating systems, while I'm not totally sold on a lisp machine, something REALLY INTERESTING is a Lisp os, which can use it's ability to abstract away pointers to remove memory paging and kernel privilege. By this I mean it's possible to execute an entire system from the root all the way into userland in a single monolithic memory block while proving the impossibility of any executed function from infringing on the memory of any other function. It's even possible to trivially restrict namespaces, processor time, and memory allocation to perform sandboxed execution without having to make a separate process. A step beyond the microkernel: the no-kernel.

Relevant to this thread; how to prototype and test a radically new computer architecture before commiting to the silicon fab, by the guy who built the Alto from scratch ROM chips in a few months to prove it could be done: https://www.microsoft.com/en-us/research/project/bee3/

>>38881 >Here's a later paper from 2020 about a new design of OTFT that can operate at 160MHz, only an order of magnitude or so away from a real computer. >Also don't discount the utility of "slow" transistors either. Remember these tings are also good at sensing and can be made into LEDs. Even 40 operations a second is actually more than enough for a display/interface. This makes me wonder, how are these things manufactured? Is it theoretically possible to hack a commercial inkjet printer to print the TFT layer of a computer display?

>>38265 >mediocre-to-bad programmers have trouble reading them Good, they cause more trouble than they contribute. IT has too many idiots these days.

>>38265 American criminal scum detected >muh mental health >everyone is qualified >even if they aren't qualified, they just are ok? make it dumber >now make it appeal to my arbitrary preferences of extreme entitlement in the name of progress Why are they like this? Why can't the American ever admit something might be out of their wheelhouse, instead of trying to atomise society to a state worse than their self-proclaimed boogiemen counterparts ever could. Get good or fuarrrk off. Jesus. It was never this complcated throughout every industry, throughout every society, throughout every time period.

>>40934 I was also reading the thread and immediately thought of "how TF do you make a diy digital display without manufacturing?"... From what I gather, tft displays are LCD which is basically a crapshoot for easy diy manufacturing. A homemade led in itself is hard to do, but not impossible. Ive been researching how to make a diy display and so far it's pretty much a moot point. Every "hack" or "diy" I've come across uses parts from already manufactured displays. I was thinking more along the lines of how an etch a sketch works. If one could make a matrix of tiny etch a sketch style panels that operates in electrical impulses, than possibly a doable diy display could be made for such a project. Though, then you have a diy battery small enough to carry around for the rig to worry about. I think making the hardware that runs is the easiest part in this equation. Graphene batteries are coming a long way though, and diy graphene batteries are very possible, but can they be made small enough for the needs of this project? Probably through trail and error r&d. Next would be the display. I was reading about a graphene display but it also uses LCD for the actual display part. Then my mind went to crystals, even lighters use quartz to make a spark. Piezoelectric micro crystals could be an option for a simple matrix display panel.

>>32709 I recently learned that Copper(I) Oxide is a semiconductor. Copper oxide can be made by simply heating a piece of copper, so this is very interesting. In fact, apparently early attempts to create a FET were first done with this material, though apparently some interaction between the insulator and the semiconductor prevented it from working until one was made with silicon. Still, it seems it is possible to create FET transistor with Cu2O according to some. Some useful links: - general info: https://en.wikipedia.org/wiki/Copper(I)_oxide#Semiconductor_and_related_uses - Making a copper oxide diode for a radio amplifier: https://hpfriedrichs.com/radioroom/cu-diode/rr-cu-diode.htm - https://physics.stackexchange.com/questions/376958/why-did-shockleys-copper-oxide-field-effect-transistor-fail-and-has-anybody-suc - "Copper oxide transistor on copper wire for e-textile": https://www.sci-hub.ru/10.1063/1.3589374 I haven't grokked yet how exactly this copper oxide works as a semiconductor (and my poor chemistry knowledge certainly doesn't help), but it seems like making a diode should at least be feasible to do at home with minimal tools, so I'll attempt that first. If it works, it'll be useful for creating ROM memories at least. It apparently is photovoltaic too and I recall someone using a burned copper wire as a thermoelectric generator to power a LED, so it might be useful as a source of energy too. Other than that (and admittedly somewhat besides the point), the "€1 computer" might be of interest too: https://olimex.wordpress.com/2025/04/30/rvpc-the-open-source-hardware-and-software-euro-1-risc-v-computer-now-got-basic-interpreter/ though that particular computer seems too limited to be useful. It does show that very powerful microcontrollers can be acquired for very cheap though. I also second that TTAs (Transport Triggered Architectures) would be ideal for their extreme minimalism while still being general-purpose and programmable in a sensible manner. Depending on your definition of a "Functional Unit" you could perhaps attach a whole microprocessor to a TTA (from, say, scavenged sources), allowing for bizarre but usable Frankenstein systems. Regarding languages: I don't think the choice matters a whole lot long-term, but making an interpreter for a concatenative language (such as Forth) seems the simplest to do, which is valuable if you need to port to many different architectures, so I believe it is worth investigating that path.

Additionaly wrt languages: you can skip the tokenization step if you directly display tokens as their corresponding symbol, as well as wire buttons directly to specific tokens. This is how TI-BASIC works. You could even skip token -> AST conversion with a sufficiently clever editor which operates on the AST directly, though that's a fair bit more involved.

>>42067 If you're going to skip token -> AST you should rather skip AST altogether by designing your language's syntax to not need one. I have an example of that which I'd link but it's too cringe and political, basically for lambda calculi you need to reverse apply(f, x) which is like f(x) to (x)f e.g. apply(operand, operad) to make it work. This is evident in that this reversed ordering makes the identity function expressible as lambda x. x, this doesn't work with conventional application syntax.

I recently learned of the parametron. The basic idea is to use alternating current and transformers for digital logic, by exploiting phase offsets (either 0° or 180° for 0/1, opposite might work too, unsure). Unlike a relay, it has no moving parts, so it doesn't suffer from mechanical wear and is much faster (though far behind modern transistors). I don't fully grasp their operating principle yet and I am still collecting information, but these seem useful: - https://maurycyz.com/projects/magnetic_logic/ article where I first learned of parametrons. - https://ieeemilestones.ethw.org/Milestone-Proposal:Parametron,_1954 A very thorough article on parametrons and computers based on them. I have only skimmed it so far, but it seems like the best place to start if one intends to built a parametron computer. Some pictures: 1. A NAND gate (apparently, haven't tried it myself yet). 2. Boolean logic implemented with majority logic. Parametrons operate with majority logic, which makes design quite different from typical computers then and now. 3. I learned from the ethw.org link that it is referenced in Dr. Stone. I suppose I should read or watch it sometime. I'll spend some time in a circuit simulator to get a better intuition.

I'm still not getting what is the exact technical reason why we can't have a desktop CPU-printer just like we have desktop 3D-printers. Too big infrastructure required? That only matters for mass-production, that would no need for that if you only need 1 chip every once in a while for your personal use. Need for clean-rooms? For the above use case, they could easily be replaced by small portable vacuum-chambers. Too many manufacturing steps? Afaik, it's only the same 3-4 stuff repeated over and over again.

>>42650 Even as a curiosity this is absurd. Nine inductors to make a NAND? You only need two transistors for a NAND. The magnetic effects would prevent you from making a tight circuit, even an 8-bit RISC would be massive. >The basic idea is to use alternating current and transformers for digital logic, by exploiting phase offsets As you push a computer to usable speeds, wouldn't phase shift become more of a problem? Especially if it's transmitting through an arbitrary amount of inductors. >Unlike a relay, it has no moving parts, so it doesn't suffer from mechanical wear and is much faster (though far behind modern transistors). There are solid state relays which also have no moving parts. I just don't see the point of this. There doesn't seem to me like there's anything novel you can do, just a hell of a lot more problems.

>>42664 Smaller semiconductor fabs were bought up and and shut down deliberately to limit how many people know how to make these things. Information and technology is not available to the public for the same reason, to restrict knowledge and capability.

wouldn't it be better to make small yet extensible hardware in which you can actually alter your device as you need but it's naturally small ?

>>32727 >>32728 Platonist aryan vs materialist grug!

>>42650 >>42676 This is actually seemingly equivalent to a method that uses transistors instead of inductors, but without the need for DC bias. The main issue is saturation logic is incapable of switching DC, which means you'll have to control all the clock signals with transistors. Another issue is that you can't store oscillating fields, which means magnetic memory will require semiconductors to convert the signals into DC. I think the real potential of such magnetic logic is in microwave waveguides, where an inductor can be a straight copper trace. With external oscillator and clock signals, it should be possible to directly etch these inductor based logic gates onto PCBs. That's a severe downgrade from ICs, but so far as I'm aware literally no other form of diy computation at that scale is even remotely feasible by comparison. This could actually theoretically be done right now with readily available materials. I don't think it'd be impossible to get to 0.1mm pitch with diy photolithography, and that's 10,000 gates per square centimeter. You might actually be able to build a working computer with that, and if you're efficient enough with memory that could be a kilobyte of RAM at the size of a credit card! This might actually be a big deal!

>>42724 >>42676 A lot of the problems can be neatly solved when you replace inductors and ferrites with capacitors and electrets. They have the exact same saturation behaviour, only the capacitors use voltage signals instead of current signals. There's even commercially available ferroelectric ram being made right now that functions exactly the same as magnetic core memory. Only it's being produced at 130nm scale and clocking at 35ns per store! https://en.wikipedia.org/wiki/Ferroelectric_RAM Given that the PC-1 parametron based computer used entire magnetic circuits, driving it's core memory using magnetic amplifiers without transistors, it's entirely possible that an electret amplifier could be constructed entirely capable of operating FeRAM. Ferroelectric materials also aren't rare or hard to work with and consist of things such as glass, nylon, PTFE, etc... While capacitors can obviously be made out of any old conductor. I don't think it's entirely outside the realm of possibilities that you could build some sort of diy test circuit using foil laminate chip bags if you had the right driving/sensing equipment to operate it!

>>42679 >Smaller semiconductor fabs were bought up and and shut down Can you elaborate on that?

>>42676 I am able to make a transformer and capacitor at home with basic tools. Making transistors at home is, to my knowledge, much harder. Some people manage to make them at home but AFAIK none have managed to produce monocrystalline silicon disks at home. Granted, there is significant design involved in making a parametron work, but I'm more confident in my ability to make that that than making transistors from scratch. Of course, if you do have a stable supply of transistors you should use that. I imagine parametrons would be useful in a "all of our semiconductor industry got nuked" scenario. >>42664 This might be of interest: https://hackaday.com/2022/03/22/old-printer-becomes-direct-laser-lithography-machine/ It is on my DIY to-do list, but other projects have priority.

has anybody here even made a diode at home, much less a transistor, much less an integrated circuit? it is possible to make big, crude diodes out of everyday materials. i'm not sure if it's possible to make big, crude transistors at home that are reliable enough to use as the basis of a big, heavy, slow computer. it is possible for hobbyists to make their own vacuum tubes, which were of course once the basis of even bigger, slower computers. but if you're talking about making your own silicon based integrated circuits, even something as old and slow as a 4004 (possibly the first thing you could call a microprocessor) then you're out of your freakin mind.

>>42845 The difficult part is it's not just any old inductor or capacitor, you need a highly nonlinear one. So you either need to make your own ferrites or dielectric film. Still easier than transistors, but not exactly effortless. Probably in any serious attempt at a parametron I'd expect 80%+ of your time and effort to be making and operating the machinery required to manufacture the components. Luckily parametrons are extremely robust unlike vacuum tubes so once you get one working it's pretty much bomb proof and will probably outlive you if properly maintained.

>>42849 >but if you're talking about making your own silicon based integrated circuits, even something as old and slow as a 4004 (possibly the first thing you could call a microprocessor) then you're out of your freakin mind. i wrote that. i'm happy to report that i was wrong. i did a search just out of curiosity, and i found a wired article about a guy who is making integrated circuits in his parents' garage. coincidentally, he specifically mentions getting ready to make one on the scale of an intel 4004 microprocessor (pic related) as his next project. he does his own design, ultraviolet pattern writing, and acid etching. well i'll be damned. i didn't read the whole article yet, and i suspect that he still has to buy ultra-pure sliced silicon, but that's still utterly amazing. https://www.wired.com/story/22-year-old-builds-chips-parents-garage/

same guy. let's see if i can be wrong some more, ha ha. as far as an interpreter in rom, the early ibm-pc and apple ][ had basic in rom. i remember playing with a small c interpreter a long time ago. it would be great to have that in rom. i can't think of any language that would be more useful. the apple ][ also had what it called a "monitor" in rom. with that, you could examine the contents of ram, and directly edit ram using hex code. it also allowed you to disassemble the contents of ram on the fly. woz was a friggin genius. all of that would be great on a so-called sovereign computer. you could do pretty much anything the op mentions with a 6502 based apple ][, or a z80 would be even better.