Kube Doom, Kill Kubernetes Pods Using Id's Doom

You might be thinking of psDoom, which let you kill processes. http://psdoom.sourceforge.net/

Right? I think it's because DooM is so recognizable and so snappy. Fast action, clear visuals, no cutscenes or chainsaw animations to interrupt the flow. Only Quake1,2,3 games have similar traits and are also used for tech demos and proofs of concept.

'Can it run Doom' and 'Can it run Crysis' are two very famous benchmarks for entirely different goals, but they still stick around because they're easy to remember and easy to grasp. The versatility of Doom is really one of the best example of hackery that has ever been

Looks like it's a fork of a fork of psdoom

I seem to recall this being covered in Wired #1 way back.

I'd love to see some exploration of how VR could be used past the idea of "you have infinite monitor space now".

I think being able to stack things that would normally be a sub menu might be interesting. it would need something better than a mouse though.

I thought it was a pretty compelling idea when I first saw it in the original Jurassic Park movie, even if that was a metaphor for "hacking."

Yes, for three dimensional data visualizations and especially three dimensional visualization that can be seen changing over time.

We sort of already have a 3D environment: windowing systems. But every IDE I’ve used in years instead uses tabs. Perhaps something of note there.

> Do you think that a 3D environment can in some way be(come) a better GUI for development/operations than the 2D stuff we have now?

There's a whole new dimension to work with. Working with it is optional. In principle I'd say yes.

That assumes we've found ways to efficiently use the extra dimension, including visualizing and interacting with it.

I was working on a 'visual debugger' that centered around a 3D display of data structures evolving in time[0], and learned some lessons from it.

I would say the key thing is to understand the specific properties that differ when adding another dimension.

The main thing you gain in terms of expressing information, or in terms of designing an interaction scheme, is another axis on which you can 'analyze' your problem: this is a generalization of the basic idea you see with a 3D data plot vs 2D. This 3rd dimension is a new element of the 'syntax' of your UI, which can be made to map to a specific concept in your program.

So then the question is: does the problem you're trying to solve have a matching structure that would be clarified by having an additional axis to map its visual representation on to?

Additionally, the property that caught my attention initially was about using 3D space + human visual processing to define an information prioritization scheme: 'depth' into a 3D scene is is a natural, ready-made system for indicating priority:

Objects nearer to the camera (less 'depth'), occlude further objects. Further objects have their (projected) size reduced as a function of their depth, and are often darkened as well. All this adds up to a convenient/flexible way of talking about priority (from the programmer's perspective) and a natural way of reading priority (from the user's perspective).

That's the theory anyway: my experience with it was a mixed bag, and at least for my specific project, when I've thought about how I'd do things differently now I think I'd just stick with 2D—at least to start with.

There are a lot of more unsolved problems that show up when thinking about UI in 3D, possibly because the design space is larger, but certainly at least because it's less explored. And the number of possible ways things can go wrong, or at least considerations needing to be made, from both programming and design standpoints, is also significantly larger in my experience.

[0] http://symbolflux.com/projects/avd

Given that the most natural space for a human to operate in is 3D (given the physical world), I believe so. I think the fact that GUIs mostly show 2D data is a product of the limitation of their display medium. For example, watching videos in 360 degrees has been possible for a while now.

I think VR might have potential (forgetting motion sickness), but one thing I think we need is the ability to see our hands. Therefore I think AR is realistically the productivity interface of tomorrow.

I think ultimately AR solves some massive problems:

1. Your "display" is wherever you need it to be. No need to lug around a laptop or monitor. It's as large or small as you need it to be, even partially transparent if required.

2. The ability to integrate information overlay on reality will be really useful, especially if natural hand tracking continues to get better. Imagine a sat nav app helping you navigate some populated area or building. Imagine an app guiding you through the shopping mall based on an optimal route computed from your shopping list, performing price comparisons for you. Imagine working on a document or piece of code and being able to walk over to your colleague and share your display with them. The possibilities are potentially endless.

3. Energy usage should be much less, as you're not wasting light making your background brighter. Suddenly your only real energy concerns are computation, and with cloud computing and internet connectivity improving, maybe you can offload most of the energy usage onto dedicated machines elsewhere.

My guess would be within 10 years we see some key break through. It's really a shame that Google backed out with their glass project.

Thinking about VR here, not just 3D: I played a bit of VRChat recently, and it has surprised me how well multiplayer 3D rooms in VR work for socializing. It has benefits over normal audio and video calls: people can naturally cluster to have separate conversations and move between groups as in real life, there's the body language (hands and head positions are tracked and visible to other people) that make it easier to see who is paying attention to who, and the sense of presence given by VR makes your mind feel more involved in the social situation. I really think this is something that VR legitimately does better than traditional computer interfaces.

So if there are development or work scenarios where VR is beneficial, the benefit could come from VR being better for realtime collaboration between people in some scenarios.

Not strictly related, but I've been wanting a 3D debugger for ML models for damn near a year now.

It seems like a slam-dunk idea. Stack images like https://battle.shawwn.com/sdb/visualizations/2020-09-16-117m... in 3D space, like a cube. Put them in order of layers. Ditto for activations.

The spatial structure is important. Right now there's nothing, not even tensorboard, that preserves spatial structure. For example, look at these two images:

https://battle.shawwn.com/sdb/visualizations/2020-09-16-117m...

https://battle.shawwn.com/sdb/visualizations/2020-09-16-117m...

You're looking at weights, followed by bias. You can see visually that the bias lines up with the weights. If you tried visualizing that with tensorboard, it'd shrink the images to squares with padding. Which would be fine if you could rearrange squares so that one is above the other, but you can't. Meaning you lose the ability to correlate visually what's going on.

Someone please make an ML doom blaster so that I can at least reset layers of my ML model by shooting them.

It's all about speed and efficiency.

A 3D environment might be the most intuitive one in the long run but it will never be faster because you either are moving through 3D space just to manipulate a virtual object, or you're waving your hands around in AR/VR space to manipulate virtual objects.

While on the other side I'm simply moving my fingers and hands swiftly across a small surface to perform the same action.

Depends on your problem, programming/teach a robotic arm in all dimensions is often faster in a 3D environment or VR, but programming that arm in just 2 dimensions is probably faster done in normal code aka 2D.

It a bit like the discussion of Gui's vs Terminal even if both of them are 2D.

For software development, I don't quite see it, because what we are building is not really a 2D or 3D thing but more conceptual (not sure what the right word would be). Visualizations help to understand and troubleshoot a system, but for the actual changes or additions I see more potential in NLP to communicate intent to the computer that it then turns into code rather than different GUIs. 3D GUIs I reckon would be similar to visual programming languages in a sense that they are really useful for certain use cases and to interact with a lower level system, but don't universally replace the environments we currently have.

Where I think 3D has much more potential, is using something like google glass or full on VR headset to augment what is seen in the "real world" in professional settings.

E.g. a couple years back I had a conversation with my sister who is anesthetist (at the time in the heart surgery department if I remember correctly) about them experimenting with robotically-assisted and remote surgery. If you only see what you are working on trough a camera where depth perception can be problematic, I could see it beneficial to have real time overlays to outline shapes or other augmentations to what you are seeing.

Also there might be interesting things in manufacturing, like showing you if you are within tolerances during assembly or have some algorithms/AI running over it to highlight aspects that seem out of the normal.

But in either case it might well be more distraction that actually useful for those people.

I'm not sure those are ever going to be open sourced unfortunately.

Doom is playable under an Amiga with a 68060 or a 68040 with an accelerator board.

This kind of thing is what makes me love the hacker community so much. There is probably no conceivable practical use for this (at least from what I can see right now), but it’s fun, and was a challenge, and someone just went ahead and did it.

Sorry if this is very minor, but if possible, please also take out an extra ‘o’ from “Dooom” in the title.

This was an actual thing and probably the original inspiration behind this article: https://www.cs.unm.edu/~dlchao/flake/doom/

It is :-) From the Readme:

> This is a fork of the excellent gideonred/dockerdoomd using a slightly modified Doom, forked from https://github.com/gideonred/dockerdoom, which was forked from psdoom.

Here you go: http://psdoom.sourceforge.net/screenshots.html

this was done many many years ago, it’s called psdoom

No grenades in Doom. Rocket launcher or BFG, though...

Why not DeadOps?