pdehaan

Yet another example that being "ugly" has little impact on utility. This looks right in line (if on a smaller scale) with the masterpiece that is McMaster-Carr https://mcmaster.com/

My anecdotal experience is that it briefly gets better, then much worse. Build scripts downloading tarballs from dead URLs and dependencies on unspecified versions of libraries that have since had breaking API changes are frequent issues.

…it’s still awesome that people put in the effort to do these things at all, but the tools often have a tendency to make me feel like an archaeologist trying to piece what ancient artifacts are missing and how they were supposed to all fit together.

DSP and more recently SBIRS are satellite-based systems, both use IR. If you track the missile to the end of it's burn you'll have a pretty good idea of where it's going after that -- ballistic trajectories are fairly predictable.

https://en.wikipedia.org/wiki/Defense_Support_Program

https://www.lockheedmartin.com/content/dam/lockheed-martin/s...

I'd be curious about what you mean by software experience. Presumably oculus home gets replaced, but is the performance of things like tracking noticably different?

The Quest is unfortunately still a bit unique as the only standalone 6DoF headset. Edit: not truly unique as pointed out.

The Index is more than double the cost for something that requires spending more money for a computer to run the whole setup.

...not that that's for nothing, the results are better than any of Oculus' products graphically. But it's a different product.

I've been using one of the knockoffs for about 6 years as lounge/work chair. It's comfortable for things like reading, listening to music, and sitting in video meetings, but not the best posture for heavy typing.

I like the design and it fits me, but it's worth pointing out the lack of adjustment. Unless you want a purely decorative chair, I recommend finding someone with one you can test drive.

The seller I bought the knockoff from has since evaporated, so that's another potential concern if it ever needs repairs.

Are there any problems we have a proof for, and a corresponding proof that no algorithm can exist to provide said proof?

Basically, why can't I write an algorithm that can be given input for "is the halting problem decidable?" and return "no"?

Thanks, that's new to me (or at least I've ignored it long enough to have forgotten if I had learned it before).

At a guess, it makes the language simpler. The main function is just that -- a function. It uses tools the language already has to deal with arguments and exit codes.

Arguably it also keeps things like libraries simpler. For example, what would it mean for me to have top-level expressions in a dynamic shared library? Does it execute as soon as I dlopen() it? Does it create an implicit "init" function that I need to call?

Not for coding. The resolution just isn't there yet.

Roughly, per-eye resolution is in the same ballpark as HD displays, but stretched over a 90+ degree field of view. Fonts need to be very large to be legible. You can create a theater sized virtual monitor, but it's just taxing to use. Aliasing artifacts make it worse.

At least for text-focused tasks, I'd take virtually any display built in the past 40 years over a modern VR headset.

It would surprise me if the majority of the market for "linux laptop with fast discrete gpu" wasn't really just a subset of "devs that want CUDA support".

If the machine doing the streaming is on the local network maybe.

VR is not a forgiving environment for latency. If your target 72fps (Quest), about 862 miles is an upper bound for distance. That's just to get data round-trip at fiber speed, additional latency sources (wifi, rendering, encoding, wifi again) are going to make things worse. Prediction and "timewarp" only get you so far.

I'm all for wireless headsets to eliminate the tether when using a PC, but to me the Quest is compelling primarily because it's standalone. I can bring it almost anywhere (empty warehouse, a large field outside, hotel rooms) and not need to worry about lugging a bunch of extra gear.

It's also really compelling for quick product demos if that's your thing. We can keep builds of software installed on a headset that can go from packed in a small hard-case to ready to show off in about the time it takes to boot.

Python with type annotations is the closest I've used to that, and I hate it. It beats no type annotations, but only barely.

As soon as I need to use someone else's code, all bets are off. Half the reason I want types is because it makes my life easier when I'm trying to use something written by someone else -- instead I find myself needing to experiment with a debugger to figure out what functions are actually doing.

So much of what I do as a programmer is just try to understand what some existing piece of code does. If I come across code like that, I can search documentation or start to guess at intentions even if it's something I'm not familiar with. I'll probably need to read the documentation associated with some classes or methods to fully understand, but my tools make that readily available.

If I encounter math notation that I'm not already familiar with, my only real options are to start asking people, "hey do you know what this is saying?" or start shotgunning references/papers/books and hoping for the best. Even if I know the names of some symbols, searching something like "integral omega f" doesn't generally yield useful results.

Not just more natural, it also lends itself to better accuracy and/or efficiency in some cases too.

As a quick example, if you're writing a numerical approximation or even just a LUT for sin(x), you can get away with only approximating/storing values for a reduced range by using some bit twiddling. The top bit becomes sign of output if you XOR it out first, the next bit lets you take advantage of sin(pi/2-x) = sin(x+pi/2) to half the input range again, eek out symmetry for the next bit and you can nearly approximate sin(x) as a linear function for some use cases.

I recently discovered greenshot. It's not perfect but I found it covered 95% of what I wanted while putting together some tutorial content recently (drawing decent arrows, highlighting important regions, etc)

In this case wouldn't naming the agent also increase the likelihood that they're targeted? The clients have already been primed to follow the phishing link, so it'd just be a matter of getting a target list. Most agents I'm aware of stick to a local region/market, so targeted ad buys ("people in X county buying homes")/email lists/etc could be worth it for a motivated phisher.

Maybe I'm misunderstanding the use case then? I'm imagining something like:

A and B are on a phone call. A starts a video meeting. B goes to shortlink.dtmf or opens the app, which starts listening. A clicks "transmit room code" which goes over the existing phone connection. B's client hears the signal, decodes it, and gives them a link to join.

For the phone only route, it seems like you could still mostly automate it by going oldschool. Give the host an option to play the meeting code as a DTMF signal (or whatever) while the other person holds their phone near the mic.

That thing is basically just a laser range finder, it doesn't produce a 2D "image" of distances (unless you pair it with something to spin it around, at which point you just have a bad version of existing lidars).

I haven't looked into MegaTexture much, but from what I can tell it doesn't repeat terrain textures.

In most modern games, smaller textures are tiled over larger areas, allowing for lots of detail for less memory at the expense of variation. Most do something to mix it up (mixtures of textures, adding random variations), but it ultimately constrains what can be done.

MegaTexture seems to solve the problem of using a single large texture by streaming only the parts needed, but requires much more data on the disk to match the detail level of tiling.

I was a 5-year-old with a penchant for opening electronics, so I'm fairly sure they exist. However, I'd be more worried about adults doing more harm than good by taking apart/putting things back together in an attempt to 'fix' it before going to someone that knows what they're doing.

Also, many people ignore that most of those crazy looking screw drives also have benefits such as better cam-out resistance.

First off, apologies if I was coming off as rude, I wasn't trying to be.

My point was more that slurping a file without spawning another process is already quite easy in perl. That method of slurping contradicts common patterns like "while (<$fh>)". I'm not saying it's strictly wrong or even bad, just not necassarily the best option.

This isn't exactly idiomatic Perl and fails completely in environments that don't have cat (Windows).

For one-time uses there's not a problem. However, if you find yourself writing what amount to shell scripts in Perl, you might be better off just writing shell scripts.

   Fabric Engine has released version 1.0 of its platform for multi-threaded optimised execution of scripting languages.

Kind of cool, if somewhat misleading. The way that's written seems to imply it speeds up the scripting language itself, but reading further it seems to just be a lower level language that's easy to use from within those scripting languages. Using an FFI to speed things up is nothing new, but making it easier is always nice.