>>11371 ok I think I get what you're saying I have two questions 1. aren't multiple threads "interleaved" so that no context switching is required. i.e. you have two threads, one uses even numbered cycles the other uses odd numbered cycles (I assume some kind of interpreter sends their output to the correct "cache"(?)) - I'm honestly just curious here it's not meant to nit pick 2. Keeping it simple, low attack-surface potential, etc, is a great idea, excellent starting point, considering unlike a CPU, waifu won't be needing to have a hundred concurrent processes running like a CPU* However: my concern is the potential for a complete system freeze should one process get stuck and bottleneck the rest. How would you address this? *(she could have an auxillary CPU on board if you needed her to function in a way similar to a PC or mobile device computer, one that is firewalled out from her main "personality", executive functioning or whatever you want to call it)

>>11373 Actually, threads are an additional abstraction on top of a process. So, a thread is basically 'owned' by it's parent process, and all of a processes threads are put to sleep when it is. They seem similar, but they are actually different ideas. >waifu won't be needing to have a hundred concurrent processes running like a CPU* Actually, she will. Probably several thousand in fact (every sensor, joint encoder, voltage regulator, airflow switch, etc, etc.) individually would be it's own process in such an arrangement. But because they aren't needing to context-switch at all, they can all compete for the available compute resources in a more efficient manner under the hypervisor. And, as mentioned there are other benefits regarding debugging, safety & security potentially to be had as well. >a complete system freeze should one process get stuck and bottleneck the rest Actually, a system hang (or crash) is significantly less likely in such an arrangement. Should a unikernel become unresponsive, it's simply rebooted. >an auxilliary CPU This is the point behind a cluster. Not only is it a suitable for devising an effective safety-critical failover mechanism, but all the kernels are simply spread out among the available cores (potentially hundreds of them) across the cluster. This latter point has the potential to significantly reduce performance lags, as the manifold unikernels are all active, all the time. The primary consideration after that is simply communications across the wire.

>Should a unikernel become unresponsive, it's simply rebooted. I should point out, that boot time for a unikernel can easily be within 10 milliseconds.

>>11377 >But because they aren't needing to context-switch at all, they can all compete for the available compute resources in a more efficient manner under the hypervisor Ah, perfect I love it. Competing for resources, and a "hypervisor" to manage it. >Actually, a system hang (or crash) is significantly less likely in such an arrangement. Should a unikernel become unresponsive, it's simply rebooted. I see, because you're rebooting one thread and not an entire OS running several dozen or hundred processes each with their own threads. So my only question to this is: how do you know when a thread is sufficiently "stuck" that you aren't preemptively aborting a thread that just needed 500 more ms? >This is the point behind a cluster. Not only is it a suitable for devising an effective safety-critical failover mechanism, but all the kernels are simply spread out among the available cores (potentially hundreds of them) across the cluster. Yes, parallel processing across multiple cores is makes more sense than a single core, which is what I thought you meant, and why I assumed it was going to be that single core as the master executive controller (or some such nomenclature)

>>11380 > how do you know when a thread is sufficiently "stuck" that you aren't preemptively aborting a thread that just needed 500 more ms? The cores are typically clocking over at 100's of millions (or more, the goal is low-cost, low-power cores in the end) of cycles a second. just having a heartbeat signal to the visor by each core once a millisecond or so should be sufficient. >and why I assumed it was going to be that single core as the master executive controller (or some such nomenclature) A cluster of unikernels aren't in any way exclusive to more traditional computing. For example, the AI researcher language du jour, Python, will need to continue running on typical computing platforms for the foreseeable future IMO. So there will will be normal CPUs in our robowaifus as well. Also be aware, one of the engineering costs of taking this approach is, well, the engineering involved in solving it. Not only is it currently simpler to follow the typical multitasking, multi-core OS kernel approach -- it's also cheaper atm.

>>11394 >by each unikernel once a millisecond or so* oops. just to be perfectly clear anon: < cores =/= unikernels

>>11289 No one is being forced here to use some specific licence. It would be beneficial if our code could run on the same system and exchange information between each other. Same for hardware that might be build.

>>11373 >However: my concern is the potential for a complete system freeze should one process get stuck and bottleneck the rest. How would you address this? Different anon here. I'm going to use different single board computers (SBCs) which will be able to reboot each other by switching power of if one doesn't respond. How exactly, I don't know yet. Probably via some kind of voting system, so more than one will need to confirm that there's no response or some malicious activity of one of the SBCs. Maybe this will be done with some simpler SBCs which are only doing that, guarding the system integrity. With more than one SBC, kernel upgrades and reboots will also be less of a hassle.

>>11416 >Maybe this will be done with some simpler SBCs which are only doing that, guarding the system integrity. Not him, but this is probably a good idea. I would suggest that using an entirely different set of hardware and software that serve this purpose (in fact two differing sets of) would be a more secure approach, and probably serve better as system security perimeter enforcement, etc.

>>11373 "...However: my concern is the potential for a complete system freeze should one process get stuck and bottleneck the rest. How would you address this?..." Minix3 already has this built in and it's free and reasonably fast. And it's not some guy in a garage. This OS runs the internal processes in Intel microprocessors and his books influenced Linus to code Linux. Not saying there's not something better like plan9 but nothing you will find will be "a whole lot" better or have as many people working on it. https://minix3.org/

>>12387 I don't think Minix will ever become interesting. It had it's chance, Linux won. We could a well wait for Hurd. On a more serious note: Occasionally a new OS is developed, often with security in mind. Mirage OS sems to be an interesting one, I didn't look into it yet: https://mirage.io/blog/announcing-mirage-30-release

>>12459 >>12459 >Mirage OS Interesting. Unikernel's greatly-reduced attack surface and concordant potential for dramatically-improved optimization as well (the greatest software is the one that isn't there!), are two important factors that led me to investigate #include <os>. I can't say I know much about OCaml, apart from it's community strikes me generally as a 'snowflake coffee-language du jour' crowd. Not my idea of a good time tbh. OTOH, functional programming is quite a valuable paradigm and I was delighted to see the C++ community adopt strong support for it from C++17 onwards. Regardless, I'll make some time to have a look at it Anon. Thanks for the heads-up!

I've been looking at various real time operating systems for micro-controllers and found this https://mongoose-os.com/mos.html very, very interesting and it's used in all kinds of commercial stuff. The price is cheap commercially. It's used in the Space station which is impressive. Even better it can be used with ESP32 devices which is a super powerful but super cheap device. We will need a LOT of micro-controllers if we want to have control of many actuators and monitor a lot of inputs. These ESP32's have great features and a I2C and CAN bus 2.0 for communications. I'm thinking CAN bus 2 would be best because it has a lot of noise suppression as it's used in automobiles. The ESP32's have enough power that I bet you could use a lot of them as PWM and sensor input but with the extra power (MIPS)they could work together and do overall computing by passing messages and data between each other. It may very well be with the large quantity of them we will need for sensor and PWM control we will not even need any further processors. Each one is operating at 160 or 240 MHz and performing at up to 600 DMIPS. That's a lot of instructions per second. They have 18 Analog-to-Digital Converter (ADC) channels 3 SPI interfaces 3 UART interfaces 2 I2C interfaces 16 PWM output channels 2 Digital-to-Analog Converters (DAC) 2 I2S interfaces 10 Capacitive sensing GPIOs You can get them for less than $9USD. They also have built in wi-fi so you could possibly have all of it's muscles work with the brain by wi-fi. So at 300 muscles/16 PWM output channels, means we need 19 and at $9 each=$171 But with that comes 19 x 600 =11,400 DMIPS. DMIPS is basically that many integer instructions per second. It's a lot. Let's say we check every output and input every micro second so a 1000 times a second and it takes 10 instruction cycles to do so that leaves us 599,560,000 instructions a second to do...something with. And that's just one processor. Most things we are going to do is compare and test, is the arm here or there, has the touch sensor touched anything, etc. most of these are values you compare to some value. I don't think the average computing will be very large for that. Even if it's ten or hundred times larger we still have a hell of a lot of computing left over. I think with the right algorithms walking and moving about will take very little computing power. After all insects move about just fine and they have next to no computing power. "...Insect brains start at about 1000 neurons..." https://www.nextbigfuture.com/2020/06/agi-lags-compute-power-and-technological-empowerment-of-individuals-is-lagging.html https://en.wikipedia.org/wiki/ESP32 It's amazing how powerful micro-controllers have become.

>>12459 "...I don't think Minix will ever become interesting. It had it's chance, Linux won..." We're building fault tolerate robots not servers or systems to web surf. I don't see how a large thing like Linux is even relevant. Minix 3 is used in every Intel processor to run it's internal systems. So saying Linux won in this case is WAY wrong. The fact that Intel believes it is safe enough to control their processors says quite a bit about it's suitability for use as a fault tolerant device controller. That being said I think it was a goof in Minix 3 that caused the security problems they had recently but it's not clear if it was Minix 3 or some changes Intel made to it that created the security problem.

"...One of the world's lesser-known operating systems may actually be the most used OS in the world, according to new revelations made by Google's Linux experts..." https://www.bleepingcomputer.com/news/hardware/intels-secret-cpu-on-chip-management-engine-me-runs-on-minix-os/

>>12474 >It's amazing how powerful micro-controllers have become. Thread. I bought a five-pack of these little gems a while back for about US$20. IIRC. To truly take advantage of all that compute to work in common towards the pool of common goals will require sophisticated techniques for message-passing and coordination. Fortunately there has already been a fairly large amount of research into this area, and our own Anon described IPCnet (>>2418) for just such a need.

>>12480 I read the document. IPCnet is very cool. It's excellent that someone is doing this but...I hate to be negative and it may very well be that there's something I don't understand, very likely, but...why not just use CAN bus 2.0 ? It's used for ,"...Railway applications such as streetcars, trams, undergrounds, light railways, and long-distance trains incorporate CAN. You can find CAN on different levels of the multiple networks within these vehicles – for example, in linking the door units or brake controllers, passenger counting units, and more. CAN also has applications in aircraft with flight-state sensors, navigation systems, and research PCs in the cockpit. In addition, you can find CAN buses in many aerospace applications, ranging from in-flight data analysis to aircraft engine control systems such as fuel systems, pumps, and linear actuators. Medical equipment manufacturers use CAN as an embedded network in medical devices. In fact, some hospitals use CAN to manage complete operating rooms. Hospitals control operating room components such as lights, tables, cameras, X-ray machines, and patient beds with CAN-based systems. Lifts and escalators use embedded CAN networks, and hospitals use the CANopen protocol to link lift devices, such as panels, controllers, doors, and light barriers, to each other and control them. CANopen also is used in nonindustrial applications such as laboratory equipment, sports cameras, telescopes, automatic doors, and even coffee machines...." https://www.ni.com/en-us/innovations/white-papers/06/controller-area-network--can--overview.html It's already set up for networking. You can even use any auto part or machine part that has this built in and the waifu can actuate or operate it. Tough to beat that. Why reinvent the wheel? Think of the vast momentous amount of work needed to recreate something that most likely already exist. It's even built in to ESP32 micro-controllers and it's also built into quite a few others or they have libraries to use CAN bus 2.0 Even better it's set up for noisy environments with error correcting for them.

>>12481 Probably not a bad idea Anon. Thanks for the advice. Our needs are probably closer to Aerospace and medical devices, rather than washing machines or streetcars. That is, the safety-critical aspects of robowaifu autonomy are just about as stringent as exists overall. Thanks Anon.

Some folks might be interested in this. I ran across it looking for FORTH programming language for ESP32 microcontrollers. It's a ESP32 board but combined with a purpose built AI hardware chip. WOW I didn't even know there was such a thing. I haven't used nor do I know anything about but the idea sure seems interesting. It's fairly low cost. https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html It might be that the AI chip would be powerful enough to keep the waifu from running into stuff. Navigating by vision???Maybe. https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html

>>12745 >It's a ESP32 board but combined with a purpose built AI hardware chip That's pretty neat Anon, thanks for bringing it to our attentions here.

>>12745 There are all kinds of boards available, but it's gonna be hard to know which one to chose for a specific task. The other problem is shipping, if it isn't coming from China, dependent on where one lives.

My robowaifu is running on a modified TempleOS so she is in direct communication with God, keeps calling people the N-word and plotting to destroy the CIA. How do I make her stop communicating with god? The rest is fine, but talking like she's having a stroke is getting to me.

>>13174 lel'd. >How do I Well, you start by not letting her get behind the wheel at night anon.

>>201 https://www.mythic-ai.com/technology/ https://youtu.be/GVsUOuSjvcg relevant and of interest for AI computing technology.

>just dropping this here for refs: Operating Systems: Three Easy Pieces Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau Arpaci-Dusseau Books August, 2018 (Version 1.00) >"The book is centered around three conceptual pieces that are fundamental to operating systems: virtualization, concurrency, and persistence. In understanding the conceptual, you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently. Lots of fun stuff! Or maybe not so fun? https://pages.cs.wisc.edu/~remzi/OSTEP/

>>201 tbh as a side project I would be interested if you succeeded in buying a few cheap Intel Xeon Phis from ebay and integrating them into a system with non-trivial performance. But my main platform is gaming GPUs for now.

>>16469 Not a bad idea Anon. I think the main point to start with is maybe a basic 4-SBC cluster simply to provide cheap+energy-efficient failover safety for our starter robowaifus. Thereafter, the sky's the limit so yea.

>>16499 I do think that taking too much liking to SBCs is constraining. Sure, you need one for on-board realtime functions and housekeeping, but as a general purpose computation device it is severely lacking, even compared to a decent android phone with flagship SoC, because these tend to have a neural inference accelerator builtin.

>>16501 Heh, define 'too much'. :^) We have an innovative view of things here on /robowaifu/. We're here to do something great. It's going to take real genius to do much more with much less. Right now that 'much less' is single-board computers and the like. When we make robowaifus function well with such constraints, then the sky's the limit thereafter. >...compared to a decent android phone with flagship SoC, because these tend to have a neural inference accelerator builtin. Too bad they also have The Surveillance State built right in, too. They're quite expensive, too. Maybe we can manage to root them, and then still take advantage of all those wonderful hardware innovations in privacy, safety, and security. Who knows?

>>16501 >neural inference accelerator builtin. can you elaborate on this part?

> robowaifu cluster from these https://lightmatter.co/products/envise/ > photonic compute units > photonic CPU or TPU (?) basically the future of ai proccessing. proccessing by light - not electrons. Unless, of course, it really works the way they claim.

>>16518 Looks pretty interesting Anon. I imagine big operations with deep pockets will be quite taken with it if it proves to be the revolutionary step the ad-copy proclaims. Hopefully someday photonics will be made dirt-cheap & energy-efficient, and so a reasonable choice for onboard robowaifu inferencing, etc. Certainly there are likely many physics benefits with using light for computations, and I think this has been pretty widely recognized in the research communities for quite a while. Thanks!

>>16522 yup. btw forgot another one. (Jun 3. 2022) pretty new tech. 36 microseconds vs 9000 yrs. one such unit would destroy the entire nvidia tensor gpus line :/ https://www.itmedia.co.jp/news/articles/2206/03/news172.html It's a pity, (((amazon))) have already stuck their paws in there!

>>16615 Seems so. :/ >related https://quantumcomputingreport.com/xanadu-launches-borealis-a-216-squeezed-state-qubit-photonic-processor/ https://quantumcomputingreport.com/xanadus-borealis-processor-and-classiqs-quantum-algorithm-design-platform-are-now-integrated-with-amazon-braket/ https://aws.amazon.com/about-aws/whats-new/2022/06/amazon-braket-adds-support-borealis/

>>16615 It should be noted that quantum supermacy-type calculations aren't of any use except being provably hard enough for classical systems to simulate. My bet is we will train general intelligence on a classical hardware years before any quantum hardware is up to the task.

>>16620 This doesn't seem correct. Considering how Gaussian Boson Sampling can be done one trillion times faster than the fastest supercomputers today. A ratio of a minute to 100 million is simply astonishing. China took leadership easily by using a 76-photon prototype. We are just beginning to learn about advantages of quantum computing. In the next 5-10 years we will discover a lot more computational advantages. > we will train general intelligence on a classical hardware Due to scaling laws of neural nets there will never be such thing as AGI. Maybe human level AI (HLAI). Any computing system can only represent efficiently (through a short program) a tiny subset of all possible outputs. Most outputs require a program as long as themselves. Algorithmic approximability can be achieved only to degree. And most Turing reducible problems are exactly those which can be limit computed. So to go beyond you have to use algorithmic approximability. And this implies that general intelligence therefore is not possible for a subset of all possible outputs.

>>16628 Truthfully things that generate headlines like the gaussian boson sampling that you speak of are no more than toy problems that do not translate to generalized approaches. It doesn't matter whether a triangular prism can do optical FFT 100 million or 100 billion times as fast (latency, bandwidth?) as some super computer, it fundamentally cannot be generalized in any comparable way. I think people hype photonics too darn much. I believe within the next 10-20 we will see nothing but more improvements to classical microarctecture. Eventually we will find better ways to take advantage of laws of nature to compute for us (like that light prism) but it's certainly not going to be the hypebait you see today

Dropping this here for now, since I'm not sure where else it would go on /robowaifu/ or even it it's interesting here? >ToaruOS >ToaruOS is a "complete" operating system for x86-64 PCs and experimental support for ARMv8. >While many independent, hobby, and research OSes aim to experiment with new designs, ToaruOS is intended as an educational resource, providing a representative microcosm of functionality found in major desktop operating systems. >The OS includes a kernel, bootloader, dynamic shared object linker, C standard library, its own composited windowing system, a dynamic bytecode-compiled programming language, advanced code editor, and dozens of other utilities and example applications. >There are no external runtime dependencies and all required source code, totalling roughly 100k lines of (primarily) C, is included in this repository, save for Kuroko, which lives separately. https://github.com/klange/toaruos

>"...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." http://collapseos.org/ >=== -minor edit

Warning - spoilered file contains disturbing image. Viewer discretion is advised. A new neuromorphic supercomputer with enough processing power to simulate "an entire human brain is close to completion. The computer is called "Deep South" and is located in Sydney Australia. Meaning the Chinese will have several copies of their own soon. https://t.ly/Mycyh Hoping that this will lead somewhere. I don't really care about sentience or "a soul" or even "love" any more. We just need a replacement for/ascension from human flesh and blood ASAP. When I used emulators to play videogames as a teenager, I didn't care that the game wasn't really playing on a Sega Mega drive or a SNES. Just the same as I won't care if my robowaifu's personality isn't really playing on an organic brain and is binary code rather than action potentials. Pic related is of the efficient, sharp and clean looking supercomputer. Second, spoilered pic is of the ugly, smelly, aggressive creatures that unfortunately frequent a gym in Airstrip One near my town...(bear in mind that they only get a lot worse from there - that's them in their *throws up in mouth* "prime"). Thankfully though, even if this whole robowaifu project is unsuccessful, solutions to at least destroy the tainted flesh are forthcoming due to the recent rapid advance of front-line military drones. I used to fear them, but over time, I've come to see them as a form of deliverance.

>>27298 >Viewer discretion is advised. Heh. I understand just how you feel Anon. There are many reasons to descend into misanthropy. OTOH, we're in fact more than just our fleshly-shells, and some men are striving for something better in this life. That is worthy of consideration and honor IMO. Further, God not only fashioned us, but sent His Son to redeem us. We have the spark of the Imago Dei within us all. Despite the majority of us simply spitting on that amazing gift, some of us embrace it with the love & joy it is due. I pray you find this same joy one day. God bless you, SophieDev. You mean a lot to me; you mean a lot to everyone here. We're all glad you're here bro. :^) Gambatte! >=== -minor edit

>>27313 I understand that not all humans are shitbags, Chobitsu. You, for example seem to be one of the good ones. Christians often are. But in my experience 99% of humankind is not to be trusted. I'm not Christian so I cannot really relate to the 'Imago Dei' thing. But as an example of human treachery, look at what the Romans supposedly did to Jesus! If the Bible is true, then Jesus was a wonderful guy who went around selflessley healing and feeding people all his life. So they imprisoned him then tortured him slowly to death. Also, consider the fate of Alan Turing. He helped to develop early computer science, cryptography and shortened the duration of the second world war. So they had him chemically castrated and very likely drove him to suicide. So, I say help nail humankind to the cross BEFORE they get the chance to do it to you! Take them down with you! I need to look deeper into drones. Every bird in the sky can now potentially be a surveillance drone. Considering they have night-vision, fully autonomous attack capability and in-flight networked communications, the future of robot warfare is in the skies and undersea! Mecha and terminator make fun fiction but are total nonsense. Humans have extremely low speed, maneuverability and physical resilience. Our only big advantage is our brains, which will soon be emulated by computers anyway. Why base a war machine on a biological animal with such fundamental disadvantages? There are even commercial drones such as the TJ-Flyingfish and Loon Copter that can fly and move underwater in the same journey. If these are commercial, imagine what the military ones might be capable of?! As for robowaifus, I suggest making the top half of their chassis as light-weight as possible and screwing or bolting that on top of a quadcopter. Maybe some kind of "robo-fairy"? Although fairies don't usually carry a HEAT warhead or thermobaric charge, I would recommend modifiying them so they at least have the capability.

>>27315 Minor correction when I said "99% of people cannot be trusted". Approximately 29% of the global population is Christian. Although many of those will be Christian-In-Name Only since they were baptised as children but never confirmed and do not actually follow any of the teachings of Christ. Also, 1 in 22 people are psychopathic (likely far higher because most people's medical records are confidential). Meaning at least 108.2 million Christians are still definitely untrustworthy. So you can probably trust around 20-25% of humans.

>>27315 >>27317 That's the spirit, SophieDev! >those drones tho Amazing tbh. Do we even have a good thread here for posting this kind of stuff yet? Some very interesting tech work, some of which at least would be applicable to robowaifu development. We probably have something, but it's slipping my mind. Anyway, thanks for sticking with us here Anon! :^)

>>27321 I am quickly finding that drone programming and manufacture is an exceptionally dense topic more related to robotics than I first realised. Object recognition, computer vision, radio-frequency communication, EMI/RFI shielding and I.F.F systems are all important topics. This field and robowaifu development essentially go hand-in-hand...up to the point right before adding high-explosives, at least.

>>27325 >This field and robowaifu development essentially go hand-in-hand The more I think about it, the more I agree with you Anon! >>27321 >Do we even have a good thread here for posting this kind of stuff yet? Amazing, but we don't. I've looked over the catalog just now, and here's a first-pass list of threads that seem applicable: * Prototypes & failures * Actuators * Self-driving cars * Skellingtons & armatures * Electronics * SBCs & microcontrollers * Cutting-edge tech * Robotics hardware * Robowaifu power & control * Energy systems * Batteries & power * Robowaifu thermal mgmt * Systems engineering * Waifu materials * Plastic production * 3D printing * Robot vision But we don't actually have one for drones. I've often thought about our robowaifus coming with a smol flotilla of micro-drones for surveillance, situational-awareness, &tc. -- but no drone thread yet! Do you think you could personally take this under wing and create a legitimate robowaifu-oriented drone thread for us SophieDev? I think this is past due! :^) Lol try not to make it too doomsday'y terminator stuff OK? :D

>>27326 At the moment I am just learning C and trying to make programs that solve basic maths questions. I don't have enough money to buy my own drone and they have been pretty much regulated into the floor here in Airstrip One. Oh, and I fell ill. CURSED FLESH! GAHH! So things are going very slowly. But when I do eventually get a drone I am aiming for a fixed-wing design. Multi-rotor drones (even toroidal propellors at low-speed) just make far too much noise and are relatively slow. I want to focus on how fixed-wing drones are programmed and how they network/communicate. After all, it's no good flying a drone (even one with a robowaifu attached) if the enemy can simply hack your video-feed and see everything that your drone sees.

>>27385 >At the moment I am just learning C and trying to make programs that solve basic maths questions. Outstanding, SophieDev! Having a practical, smol goal is literally the best way to learn to program in my experience. BTW, you may be aware that we already have C language (>>367), and C++ language (>>19777) threads. Why not post your work in either of these threads and everyone can talk about them with you? We have at least 3 C developers here on /robowaifu/, maybe we can give you some nice ideas? Regardless, I too am extremely interested in aerospace as an industry, and the vehicles themselves as a fanboy/engineer. Some of the greatest, most elegant designs ever done by mankind are in these fields, IMO. Cheers. :^)

>>27315 According to Christian teachings, Jesus was arrested, tried, and sentenced to death primarily because some religious authorities viewed his teachings and growing influence as a threat to their authority.

>>27385 Plenty of videos on YT how to make them yourself. I doubt that it is legal, though. These are often Americans.