moth-fuzz

I discovered this article a while ago when I was toying around with using plan 9 as it was designed, as a fully transparent distributed operating system. After reading this article I was a little shocked because the author didn't do any configuration or setup for the other machines, so I thought, wow! Plan 9 was so advanced that all you need are multiple machines present on the same network and it will automatically 'clusterize' them.

So I went out to make my own cluster and realized that no, sadly, the author simply did not activate nor configure the other machines at all.

I still love plan 9 and still use it on the occasion, but I'd love more detail on how to actually set up a plan9 cluster and really 'get into' the power of distributed computing.

Personally, it's because Linux is a wonderful development environment that meets my needs better than windows. Plus emacs (and most linux-first editors, for that matter) is lightyears faster on wsl than on the native windows builds.

The only issue is with WSL I'm limited to console apps, so if I want to build an OpenGL or Vulkan or GUI project, I have to use Visual Studio or VSCode if I want a good development experience, and even then, it's not quite as comfy.

I can only hope that with better GUI support comes some kind of GPU passthrough, but a woman can only hope.

Most of those technologies are deployment and infrastructure. There's Twitter the server program, and then there's Twitter the business. But whether or not an app runs on docker, or kubernetes, or is version-controlled by git, or what database it speaks to, is orthogonal to the technologies used in the app itself (or at least it should be). I wonder if one had a source package for the Twitter server if you could just run it on an arbitrary device with an arbitrary configuration, or if it actually was bound at the hip to docker or mysql or whatever configuration they choose for their own servers. Ideally, they should be separate concerns.

I think this comment is slightly disingenuous, I think it's more obvious that the aesthetics of any game (let alone engine) will primarily depend on the quality of the Assets. If you loaded up these quake 3-era meshes and textures into Unreal Engine 4 or something else you'd call 'modern', I guarantee you they'd look the same or similar.

The lighting isn't even that bad sans indirect illumination, which unreal only just got recently and Unity is losing due to Enlighten being shut down.

This reminds me of people comparing open source software with proprietary software on account of aesthetics - it's not the licensing model, or the game engine, it's the presence or absence of artists that makes the difference.

In the olden days of C, pointers were not considered types on their own (you cannot have just a pointer, a pointer must point ‘to’ something, grammatically speaking). The type of the object of that declaration is a char. So it’s not really read as ‘I’m declaring a char-pointer called a’, it’s more along the lines of ‘I’m declaring an unnamed char, which will be accessed when one dereferences a’. Hence the * for dereferencing.

I’m going to flip this one around and ask: why are businesses entitled to low-cost labor? In other markets, markets of objects, if you don’t have the funds to purchase something you don’t get to have the thing, and if you attempt to coerce the thing into your ownership, we call that robbery, and prosecute it accordingly. So why doesn’t that apply to human labor? Labor is a product, it exists in a market, and there is a baseline amount of money a person needs to survive - the ‘price’ of a human doing work (compare this to covering the cost of materials, production, etc for some nonhuman item). If companies cannot meet that price, why are either laborers or governments expected to shoulder it so that businesses can get their hands on the human product regardless? Why is human labor constantly sold at a loss?

> The VST integration is called Overbridge [0] and is available for all of the modern non-Model Elektron hardware.

Unfortunately overbridge does not support the octatrack mkI/II in addition to the Model series.

My personal experience with hardware devices seem to be the opposite of most people's experiences. So many people buy a lot of hardware that does the same thing as (or less than) a computer simply to not use a computer at all costs - and cost it does! I spent a good chunk of money on a 2000xl expecting a radically different workflow, a paradigm shift, a more 'jammable' music-making experience, and I found that it was the exact same architecturally as working on the computer (or maschine if I want a tactile interface) except 10x slower technically and 40x slower mentally. Nothing was radically different, it was the same beats and bars as I was used to, except it was slower and less capable from a technical standpoint. I get that hardware works for many but for me it's just not so.

All that said I admire the 3000 for its sound capabilities - if they weren't so expensive I'd buy one just to resample masters into. But I guess that's what 'vintage' emulation plugins are for. And of course there's the historical pedigree - enabling the invention of genres and all that.

>If this can happen, and it does, the author of the Derived class must KNOW how the Base class has been implemented. And they must be informed about every change in the Base class since it could break their Derived class in unpredictable ways.

Yes...? If you are manually overriding implementation details you must be aware of the implementation details and the contract the parent class is meant to fulfill as well as invariants it must hold.

>With Black Box programming, we can be completely ignorant of the implementation since we cannot inject code into the Base class by overriding one of its functions. We only have to concern ourselves with the Interface.

>This trend is disturbing…

it is not a trend and it should not disturb anyone. It seems author wants to change the behaviour of a type... without knowing or understanding the behaviour to start with.

>But if a parent and child could arbitrarily switch places, then clearly something is wrong with this model.

If a parent and child can arbitrarily switch places then it's obviously not a hierarchical model. Classes are not folders, they are a convenient subset of type theory. A 'Company'-related file is not a subtype of a 'Document'-related file, or vice versa. They aren't related, let alone related hierarchically.

>If you look at the real world, you’ll see Containment (or Exclusive Ownership) Hierarchies everywhere.

>What you won’t find is Categorical Hierarchies.

You won't find any hierarchies in the 'real world', they are abstract mental models that we, humans, use to organize things. Which one is more applicable depends on what you're looking at and thinking about.

I won't comment in depth on the latter 2 sections as they're comparatively short and nonsensical.

Don't get me wrong, I love FP and write Haskell and Elm relatively frequently, but this is not an indictment of OOP as much as it is an indictment of poor practices. And I know that's thrown around a lot as an excuse for the real pitfalls of OOP, and I will refuse to say that it's not "true OOP" for that reason, but, it's at least not good OOP.

Historically, the classic graph structures are adjacency lists and adjacency matrices. Those are quite easy to represent in Rust if you use indices instead of pointers. Node/Pointer type graph structures aren't particularly efficient anyway, even in C or C++.

As someone with ADHD, I don't think articles like this one do any of us justice. The tone of this whole article is piteous and negative.

I truly wish more people would see ADHD as a neutral brain difference than a ~disease~. There are just as many positives to having ADHD as there are negatives. It's not like a broken bone which is a damage that will heal, it's a different type of brain from the get-go from which we see and live in the world differently.

The key is not trying to "cure" this difference, the key is using its strengths to your advantage while working on (or working around) the weaknesses.

The long term solution is, then, not eradicating ADHD's existence, but building a society in which individuals with ADHD can prosper in their unique ways.