Fourthdwarf

Because apple has never taken an existing technology affix and built whole brands around it before. That's why they call it 'phone', 'pod' and 'tunes'.

Stuck at the razer logo? Sounds like a bootloader issue to me. System76 has an article on repairing the bootloader, which is probably worth a shot. https://support.system76.com/articles/bootloader

4 Questions: 1: When you run xinput do you get something like: ⎜ ↳ G2Touch Multi-Touch by G2TSP id=9 [slave pointer (2)] 2: What programs are you expecting touch gestures to work for? 3: Why XFCE? 4: How savvy are you with linux?

Not necessarily. Even current, low level standards like Vulkan are careful not to assume that GPUs are full turing machines, and carefully avoid allowing full mu-recursive functions as shaders. GPUs in general lay in a strange middle ground where most real world programs could feasibly run as shaders with a little support from the CPU. But there exist certain pathological but computable functions that could never run on a GPU.

There is already a port of Linux straight to DS hardware, though its extremely outdated by now. But if you have a Pi Zero W hidden off to the side, you could use the DS as a thin client via DSVNC. No hardware futzing required. Really you could have the remote session be any hardware. You could connect up to a PC and play Elden Ring, albeit at an extremely low framerate and with terrible controls.

Ok, I tried it out myself - It seems the VM is being wrongly detected as EFI enabled. There's an easy fix - Enable EFI! Try heading to Settings>System>Motherboard for your VM, and there should be an option to enable EFI. If you run into further issues, there are two likely causes - virtual drive is too small for EFI (12-16 GB will work well), or you've set up for a 64 bit OS, but are installing a 32 bit os. Either way, the quick solution is to start a new VM, but don't forget to set EFI on again.

/dev/sda is the hard drive you're installing to. As this is a virtual machine, this means it's a virtual hard drive. If you look in the settings for the virtual machine, you should be able to find some information about the virtual hard drive it's using. If you can find that, a screenshot of that would be very helpful.

You need to be able to build algorithms using well known strategies, and know when it's appropriate to use them. Strategies like: Greedy Algorithms Memoization Dynamic Programming Monte Carlo Methods Divide and Conquer Exhaustive searches

I'm going to answer the question again, extremely concisely. Khronos is a collaboration between all the major hardware manufacturers and many game engine developers, among others. Khronos makes OpenGL and Vulkan. These are available, either directly or indirectly, on most devices. OpenGL is an API for doing graphics. Vulkan is an API for working with graphics hardware. Microsoft makes DirectX. DirectX is available on Microsoft devices. DirectX 11 is an API for doing graphics. DirectX 12 is an API for working with graphics hardware. Apple makes Metal. Metal is available on Apple devices. Metal is for working with graphics hardware.

The var tag is just a way of delimiting the 'numbers' - If i didn't have some kind of delimiter I'd just be using concatenation without HTML, which is not the point of the exercise. The semantics of the var tag are almost besides the point - all that I care about is that the two strings are concatenated, because concatenation is an equivalent operation to addition. Using <var> was just a joke, which I could make as the particular choice of tags that do this was arbritrary. This is clearly not a serious way of doing addition - but it is a technically correct way of doing addition. My point is, any definition of programming language either must include HTML, or must exclude domain specific languages that clearly *are* programming languages.

As others have said, this is a really bad criteria. There are no turing complete programming languages (because there are no infinite tape turing machines!). Of course it can. Because we're doing programming, let's use the <var> tag to encode numbers. I'm going to encode the numbers as a string - the value of the numeral is the number of characters in the string. For example 6 + 7: <var>Hello,<\var> <var> World!<\var> Generates a string 13 characters long. Which in my encoding, means that it is the numeral 13, which is 6 + 7. Therefore you can add numbers by doing "Hello, World!".

So, of the options I mentioned, PyPy (The RPython version of python) is actually faster than CPython (the normal version of python), but LLVM is actually used in the Clang C compiler, so may be the better option.

I'm going to say that this is bad advice! In part, it depends on what you want to do with your language. But also, it makes for an unusable language. Nobody wants to use a 6502 in 2019. With modern compiler building tools, targeting something like LLVM would be good for procedural languages, as it provides optimisation, register allocation, and every backend you could want. You would have to learn SSA form, and how to use phi instructions, but it's actually easier than most assembly languages. But if the language is very similar to python, you may want to build an interpreter on top of python, rather than a compiler. Then, you can use the Futamura projections to collapse the tower of interpreters into a compiler. If you're willing to dive deep into the tools, the PyPy project provides tools for building a JIT compiler this way, with the RPython toolchain, though it is a limited form of python. This is kind of an arcane way of doing it, and won't teach you too much about traditional compilation techniques, but it is also fascinating and fun. +1 on the dragon book(s). Perhaps a little dated, but still good.

Apple have basically abandoned industry standard graphics APIs and gone with their own thing. Unless you specifically want to target macOS, you'll likely find more and better tools on other machines. This isn't going to be that important with basic unity stuff, but if you end up going into deep graphics magic, you may find vulkan/dx12 better supported at the bleeding edge than metal, and if developing for an indie game, the first two will let you develop for a wider audience. But unless you're doing some really experimental stuff, that shouldn't matter too much, and you could just go with an older version of openGL. Going with macOS, since you're familiar with it, may serve you better in that case.

Puppy Linux is likely your best bet. It loads the OS (~210mb) entirely into RAM, in order to negate the slowness of the USB. TinyCore/Core does this as well, but they aren't as full featured as puppy.

I'm unfamiliar with any implementation of ray tracing that works purely by operating on an acyclic graph. I can see the argument that you produce a DAG in 3D space, but that's not a graph problem. RTX does use octrees, but it has specific hardware to accelerate those octrees, and this only accelerates raytracing (by culling objects) AFAIK. And BSP is also used to similar effect. But in both cases, you have acyclic graphs with relatively few edges, as opposed to well connected graphs with cycles, that may cause issues. Also, it's only relatively recently that GPUs have outperformed CPUs in raytracing, partly because detecting intersections is difficult without breaking uniform control flow. So yeah, some graph algorithms do work well on GPUs, but add cycles, backtracking, and other common graph algorithm issues or techniques, and you have something possibly much less suited to GPUs. GPUs might find a small advantage here, but nothing near what other kinds of problems can have.

Are you sure? With graph theoretic algorithms you might need non-uniform control flow, which is a big no-no on GPUs. Which is something others have brushed past, but its hecka important. For efficiencies sake, you need every invocation* to have the same control flow, because every invocation will take every path. * An invocation is like a thread, but per work-item (in a graphical setting, these may be vertices or pixels, in GPGPU, these can be anything)

Take a leaf out of apples book and don't start from scratch. Start with, say, L4, which is probably the most successful modern microkernel, and build your own services etcetera. If you use L4Linux as a basis, you can possibly treat L4 like an exokernel, having the features of Linux (though running in userspace) alongside a microkernel API allowing access closer to the metal. You might need to build an arcane X11 setup if you go for this option, but it would be nothing on starting from scratch on modern hardware, which is the result of 50 decades of workarounds. I like the Idea though. Personally, I'd like to do a huge refactor of Linux to build a microkernel OS, or split L4Linux into multiple services, but that'd be a full time job.

More properly: Run Kali in a VM, not directly on hardware! It's primarily a set of tools, and not a useful OS!

So, it turns out, that at a small scale, it's cheaper to go solar, because it requires less engineering. On my favourite electronic component supply website I can get panels at £3/W, whereas the cheapest motors come in at around £5-£10, and have a built in gearbox which may help or hinder your project. And an AC motor, which produces a nicer waveform, costs at least £30. And then, you need the actual turbine blades! While you could build a William Kamkwamba style turbine, it might not win favour with a HOA. You'll possibly end up 3D printing it. Oh, and a housing. These costs add up. Meanwhile, on the solar project, we're already at the power conditioning stage. Once again, solar comes out on top, since we'll likely be using DC-DC conversion, with a relatively stable signal. Output 5v to charge a phone, or whatever. On the wind side, we'd need much better power conditioning, as DC motors are noisy, and an AC motor won't produces a useful waveform either. You'd need to do either AC-DC conversion, or AC-AC conversion, both of which are more complicated than DC-DC regulation. AC-DC conversion needs a bridge rectifier, and some smoothing circuitry to ensure a nice flat DC signal. AC-AC conversion is even more difficult. This is because you have your input signal, which is within some range of frequencies, and then you need to convert it into a specific frequency. For a hobbyist, perhaps you'd choose a motor-generator set - tripling the cost of the motors (at least)! TL:DR Solar is cheaper to build at small scales, if you have access to the internet.

SPIR-V - the fifth iteration of SPIR - is an important (and cross platform) assembly like language for GPUs. It allows for the front end of the compilation process to be done ahead of time, and with a single front end. Vulkan no longer requires opengl. Instead, it uses SPIR-V. The shaders are compiled to SPIR-V. And these shaders (in theory) will work on any platform with vulkan support, be it a PC with an Radeon VII, a Nintendo Switch with it's nVidia Tegra GPU, or a smartphone with a Mali or Adreno GPU. It can even be used when developing for iOS and macOS, although it will have to be converted into MSL, using tools like those in MoltenVK.

Cooling this kind of processor too much will just increase the resistivity of the silicon, making the critical path (length of a clock cycle) longer. They just don't put out enough heat for cooling to be the bottleneck.

Have the game and the file owned by another user to the actual user, and the game changes the permissions of the file. Let's say we have users user - the actual intended user gamer - the owner of certain files and files -rws--x--x gamer gamer 34927 Jul 30 17:50 snake -rw------- gamer gamer 1268 Jul 30 17:48 secret The snake binary is setuid gamer, so when it runs, it runs as gamer. This means that the snake program can change the permissions for secret (perhaps to -rw-r--r--). However, due to permissions, user cannot change the permissions for secret.

It looks like all the software is released under GPL v2 or more permissive licenses. This means that Samsung were obliged to give you access to the source code if asked, but they are under no obligation to help or allow you to easily modify the software on the actual device (the GPLv3 has a 'tivoisation' clause that gives that obligation, but any GPLv3 software was likely avoided because of this) TL;DR It's unlikely you'll be able to do anything without using security exploits.

If you want a cheap, small display, there is the possibility you could use the display from a digital camcorder viewfinder. It's only really practical for CRT based viewfinders, which are very long, and use very high voltages. Do not do this unless you are absolutely certain that you know how to deal with high voltages and all the other risks! It is a really dumb idea and not really practical anyway!