mewse

I think the post you're replying to was intended as a pun.

As a gamedev who is running his own (small, indie) studio.. That "cost of setting up and running an MMO gamedev studio for 12 months" is absurdly low; it's at least an order of magnitude off and possibly two depending on how big a studio we're talking about.

Which means that the metaverse funding of $240 billion/year would actually only fund a mere 24,000 reasonably-sized MMO game studios per year.

The question is whether you knew how that sentence was going to end when you started writing it, or indeed whether I knew that I was going to add this comma-separated adjunct when I started writing the preceding clause, and I cannot honestly say at this precise moment of typing whether the final word in this sentence is going to end up being 'yes' or 'no'.

I have a "Permanent Resident" visa in Australia which expires every five years. Kind of funny that they have a "Temporary Resident" visa which is permanent! :D

(the Permanent Resident visa can be renewed online in about fifteen minutes when it expires, they just want you to attest that you still live here)

It's worth noting that if you go fifty years back or so, fountain pens and dip pens were a lot more similar to each other than they are today. Both typically had flexible nibs and the real difference between them was just whether the ink automatically flowed from a reservoir inside the pen or was manually collected from an inkwell once in a while.

(okay, yes, also the inks themselves were completely different, with fountain pens having to use dyed water solutions to avoid clogging the pen, whereas dip pen inks actually have solid particles of pigment held in suspension in their ink, giving bolder colors and darker blacks when dry on the page; if you put a dip pen's ink in a fountain pen it would very quickly clog up with those pigment particles. And back in the day, it would probably eat right through the latex bladders the ink was stored in)

The fountain pens you get today are very different from the ones back then; they have stiff nibs which can survive the sorts of pressures that ballpoint users are used to inflicting on their pens, and they're equipped with quick-drying ink. They're pretty much indestructable under normal usage. But back in the day a fountain pen required a very light touch and some patience (or blotting paper) to ensure the writing didn't smudge and that you didn't damage the nib.

(there's been a mild resurgence in the popularity of flex nibs in fountain pens over the past few years. I haven't seen any which have anything like the flexibility you see in real vintage pens, but it's a lot more than we've seen in fifty years and it's nice to see them making a modest return!)

You can put anything in a texture these days; they're just generic pod arrays now and you can do pretty much whatever you want with them; they definitely aren't always images that get stretched over explicit meshes! In my game, for example, I have one texture which contains the xyz positions and rgb colors of lights. And another which contains connectivity data for a road network. Neither one is an image that gets displayed or stretched over things, but they're used as data within various shaders.

The most "pure" way to do a "no mesh" render would probably be to use geometry shaders to emit your geometric primitives. (You do need to give it at least one "starting" primitive to make the draw call, but you're free to entirely ignore that primitive). It'd be trivial to embed some mesh data into a "texture", for example, just by reading vertex xyz positions into the rgb channels of a 1D texture that's `number_of_triangles*3` elements wide, and your geometry shader could walk along that texture and output those vertices and triangles and have them get rendered, without ever accessing a vertex buffer object.

The Wii (like the GameCube) was weird. It was more than fixed-function, but less than fully-programmable; you'd basically assemble a simple "pixel shader" by clicking together up to 16 operations from a hardcoded list, using up to 8 textures. ('TEV Stages' is the term to Google if you want the gory technical details)

If you were coming to it from the PS2 (like I was), it was super-freeing and amazing and so much more flexible and powerful than anything you were used to. But if you were coming to it from the Xbox (like many of my co-workers were) it was more like suddenly being handcuffed.

"Simpler" is maybe a bit of a stretch, since what's happened is that a lot of the data which previously existed in vertices has been moved to substantially higher-detail storage in texture maps. If you weren't using the texture maps, you'd have to have a lot more vertices to compensate and get an acceptable look.

In modern games, you often can't really separate the model from the textures the way that you used to. Hell, I have a couple models I render in my game which take their geometry entirely from textures and don't use traditional model vertices to carry their mesh at all. These days you kind of have to consider models and textures to be basically the same thing; just different data sources that get fed into your shader and accessed in different ways, and you can often move data back and forth between them depending on the exact effect you want to get. But I wouldn't call my no-vertex-data models "simpler" than a version which was drawn from a static mesh; all that complexity is still there, it's just being carried in a texture instead of in a vertex buffer object.

I don't believe that's true; unused gold coins expire at the end of the same month during which you acquired them, one year later. (I believe silver/platinum coins are similar, but only last six months)

So for example if you acquired 10 gold coins during July 2020 (it doesn't matter when or how many purchases or how spread they are through the month), all ten of those coins would expire simultaneously at the end of July 2021, while any coins you acquired later would remain. It's not a radioactive decay at all; it's a simple expiration date on each individual coin, like you get on coupons or other incentive programs.

The coins expire for the same reason that coupons expire, airline loyalty program miles expire, etc -- they're a liability on the company's balance sheet which potentially could build up infinitely if there wasn't some limit to how long they needed to be tracked and redeemable.

As I said in my original reply, I think it’s most likely that Dow never received the sneakers at all; it seems entirely plausible to me that the resaleable-looking shoes were being diverted and exported by the contractors who had been hired to collect the sneakers from the donation bins. (and I’m not 100% certain that I have a problem with that, for “reuse is better than recycling” reasons also discussed elsewhere in these comments, but I can see how Dow might be displeased with it if it was a contractual violation)

But that doesn’t change the fact that stuff which is going to be shredded always goes through a screening process first and those specific shoes-with-trackers-in-them were never going to reach the grinders and were never going to end up in paths/pavings, even if they did get to Dow. Because I mean, obviously.

I mean, the journalists put a giant hunk of metal and a battery in the shoes. There’s zero chance those shoes would ever have been allowed anywhere near the big expensive industrial textile shredders.

If it’s a modern operation they’d be automatically and individually plucked out of the ingress path, or if it’s an older one they’d invalidate all the shoes in their bin at some earlier “bulk metal detection” step. And either way, those shoes would have to be disposed of in some other manner.

I get the “big company bad” crowd, but I mean.. what alternate option did Dow have in this case? (From the article Dow appears to be throwing contractors under the bus — plausibly, in my opinion, based upon the article. But let’s assume that the ‘malfeasance’ here was done directly by Dow — what’s the “right thing” they should have done when receiving donated intentionally-tampered-with shoes that would have damaged their machinery?)

Interestingly, Zeno had said the exact opposite, a hundred years earlier -- that since a 'whole' could be divided into an infinite number of smaller 'parts', which themselves could be divided ad infinitum, that these infinite parts when summed up must be far greater than the whole. Which was the basis for nearly all of his popular paradoxes.

(And then Newton and Leibnitz, some two millennia later, spoiled everybody's fun by developing the integral calculus such that whole categories of amusing philosophical conundrums became utterly mundane mathematical word problems with rigorously defined correct answers)

"Nonsignificant" is the key word in that quote. Both times. (and in fact several other times in the linked article).

So, it's not a strong enough or consistent enough difference between treatment and placebo to be certain that it isn't just chance. (this could happen if for example if out of our 1000 data points, 2 people on placebo were hospitalised but only 1 on the treatment was hospitalised. That'd be "a 50% reduction in risk", but not be statistically significant since it could easily have just been random chance when we're talking about such a small difference).

Probably needs an even larger sample population to really nail down whether it's real or not. Seems suggestive that all the various reported tests showed (inconclusive) benefits when you'd expect an actually-ineffective treatment to show results varying randomly in both "effective" and "not-effective" directions, though that could certainly be positive reporting bias, especially since it's being run and reported by a company with a financial stake in the results.

The "the only product known to have embedded unobfuscated Measurement Systems malware" phrase got used a whole lot, in the OP and in comments here as well as in the original email thread, but nobody really explained why that factor was important (or maybe I just missed it?)

Can somebody explain the significance of the malware being unobfuscated, and why that's apparently more concerning than if it had been obfuscated?

That quote actually isn't in the article; it's in a different article on the same site, which you may have followed a link to: https://www.theguardian.com/commentisfree/2022/mar/18/the-gu...

> There's some bad apples

[caution: good-natured linguistic pedantry follows. Apologies in advance!]

As a point of interest, this usage of "bad apple" derives from the old folk wisdom: "one bad apple spoils the bunch".

Unlike quite a lot of old folk wisdom, this saying is literally true: mold growing on one apple will quickly jump to and colonise other nearby apples, and overripe apples emit a gas which causes other nearby fruit to ripen (and then overripen) much faster than normal; so it's important not to store overripe/moldy apples together with regular fruit!

Anyhow, my point is just this: "bad apples" doesn't mean that something is in the minority and therefore doesn't have much effect and can be safely ignored -- it means that something is in the minority but is likely to infect everything around it if urgent action isn't taken to separate them. If that wasn't your intended meaning, then "bad apples" was definitely the wrong metaphor to reach for. :)

The PS2 was actually kind of ahead of its time in this regard, with programmable vector units right there in the middle of the rendering pipeline; you could actually write the equivalent of vertex shaders and even simple geometry shaders *long* before those were available on standard home GPUs. (although you had to code them in assembly)

No fragment shaders, though, it's true.

@dang: This submission links to a PR site written by the company producing the product.

As per the new policy introduced here: https://news.ycombinator.com/item?id=33884441, should this url be replaced by a third-party site we just googled?

For example, here's one I just googled which provides useful extra context about the company and the safety record of their previous products: https://www.geekwire.com/2022/rad-power-bikes-launches-radtr...

On a Chinese 10 yen coin, even the largest of its faces has less than 50% of the coin's total surface area.

On an American silver dollar, though, the two faces added together have more than 95% of the coin's total surface area.

This is a highly meaningful comparison.

(I have sympathy for the article's main thesis statement, but this particular argument in support was a little silly)

> The advantage of Vim is efficiency and speed. The disadvantage is that it has a longer learning curve.

I'm not disagreeing with this comment all, just throwing my anecdata at the somewhat squishy "longer" word in that sentence.

For me, I went cold-turkey with vim (my employer wanted me coding on both Mac and Windows at more or less simultaneously; I figured it would be a useful investment of time to learn a single set of hotkeys that I could use on both systems and get into my muscle memory, rather than trying to keep Xcode hotkeys and Visual Studio hotkeys straight in my head)

I stopped using literally any other text editor or IDE either at work or at home, just to try to learn vim as fast as possible, and spent a bunch of recreational time playing VimGolf.

As I'd expected, it was catastrophic for my productivity initially, but I reached a basic proficiency within five days; I got back to my normal development cadence quickly enough that my lead didn't even notice I had taken time to teach myself to use a "difficult" text editor; I just had one week where I was slightly behind schedule, before catching back up and getting ahead during the following week, where my skills improved even further.

It definitely is a longer learning curve before you can say that you've "mastered" vim than most other editors. But you can reach a basic competence equivalent to other (non-emacs) text editors pretty quickly; it's just that there's still a lot more useful functionality you can learn after that point.

I'm not sure I buy the popular "the internet is full of assholes" theory. I think it's more likely to be hanlon's razor.

I suspect that a lot of people have just internalised social media as a way to casually chat with their friends, without really grokking that their comments online are quite literally potentially visible to a large percentage of the entire species, forever -- including the people being discussed. That all those rules about rudeness apply to public-space interactions that you probably think of as 'private' because the target of the conversation isn't present in the conversation yet at that precise moment.

Like.. one way or another, your great-grandkids, their spouses, and their employers are all going to be able to read every single word you ever wrote on Twitter or in a HN comment or on your blog or nearly anywhere else, and all it'll take them is a random whim to look you up. A large percentage of everything you ever write/wrote online is effectively accessible forever, now, and available to anybody with an interest and an internet connection.

Most of the usenet posts I wrote as a early teenager 30 years ago (written under my real name) are still easily accessible online, for example, and it certainly never occurred to me at the time that that'd be the case. I wonder whether today's kids, who've grown up with all of these forever-archives already in place, are generally more front-of-mind aware about the situation and more careful with what they write than we were back in the early days before we really understood what the internet was going to become.

Your quoted source has that backward -- messages you've received always appear in light grey bubbles, regardless of whether they came in via SMS or iMessage.

It's only messages which you *sent* which appear in green or blue, to let you know whether each message was sent via SMS (which may have incurred a charge from your telco) or iMessage (which is free). At least to a casual glance, there's nothing on received messages to indicate whether they came in via SMS or iMessage.

NB: This article is about the $115 million Mango Markets hack of a few days ago, not about the $127 million exploit of Binance's blockchain from last week or the $160 million Wintermute hack from last month or the $1.2 billion-with-a-'b' Acala hack from the month before, or...

I'm not the original asker, but evaluating programmers based upon the number of commits per day is a lot like evaluating them based on the number of lines of code written per day -- it's a measure of activity, rather than a measure of productivity, and those often aren't the same thing.

(I'm not trying to imply that that's a mistake you've made; it's just something that it's easy to forget as a manager of programmers, and is maybe worth pointing out explicitly; you need a way to measure the team's productivity, but it's very hard to find a good, measurable proxy for 'productivity' which isn't eventually going to end up being gamed by the whole team!)

Back in those days when we couldn’t patch games post-release, our team felt it was much too dangerous to change anything for the release for fear of code layout changing exposing some bug which had previously been harmless and undetected by QA, and so we would typically leave all of our debugging tools and runtime checks enabled in the final release builds of the game. It was just safer that way.

But with that said, we didn’t generally crash the game due to a missing texture, even during development, as that’s a super common problem which would have impacted development too much; instead, we just drew anything which used a missing texture in max-saturation pink and green instead, alternating between the two colors once per second, to make sure it’d be super visible to anyone looking at the game during development.

We did usually change that behaviour to instead render missing tetxures in alternating black/near-black instead of pink/green for our final releases, as that was deemed a relatively safe change.

But the journalists too are just following the incentives that are provided to them. Don’t they deserve some of that “but that’s like blaming the fox for killing the hens, instead of whoever left a hole in the hen house” blanket pardon you’re handing out, here?

I was a believer in the "my code should never crash, no matter what" school of thought until I shipped a Dreamcast game with an out-of-date opening cutscene.

It was an in-engine opening cutscene which was very nearly final; the file we shipped was about two or three weeks out of date compared against the version that should have gone on the disc (It had one missing shape key on a character's face at the end of a shot, and a couple other missing elements). My code was wrangling the whole animation; doing all the stuff which our at-the-time-primitive animation system couldn't do itself (animating texture coordinates and etc). And my code was just silently handling all the errors it ran into so that we never even noticed that anything was wrong.

The difference was subtle enough that in the twelve years since the game was released, nobody but the original animator has ever noticed and mentioned it to me (and that, years after release). But that one experience and knowing how much worse it could have been was enough to convince me that "crashes early and crashes loudly with as much detail as possible" is by far the better strategy. At least for entertainment products. And doubly so for entertainment products which can't be patched after release.

(for clarity, this screw-up was 100% my fault. The animators had made the final changes to the cutscene data files in plenty of time for inclusion in the final build, I just somehow didn't import the changed data files into the game when I made the matching changes to the code side, and then my code didn't throw any errors to tell me or anyone else on the project that anything was wrong.)

The counterpoint is that if you as the leader just do the work yourself, then:

1. You're not being as effective a leader for your team while your attention is on your own individual contributor-level work, and

2. Your people aren't getting the learning experience of tackling the difficult jobs themselves, which means that the same thing is probably going to happen again the next time this kind of difficult blocker turns up.

In essence, you're getting a better result in the short term at the expense of better results in the long term.

And don't get me wrong -- sometimes that's the right choice!

I feel like one of the marks of a really strong working manager is the ability to recognise whether a situation is so critical to the company's survival that they (the manager) needs to handle it personally as a matter of simple survival, or whether they can get away with delegating it to team members who perhaps won't do as good or as quick a job as the manager themselves could, but who will learn and grow and improve as a result of being given the challenging task plus mentoring and feedback.

Most of the time, the most important, impactful thing a leader can do is to deepen their bench; increasing the skill of your team pays dividends for decades, even long after you've been further promoted or left the company.

Yes, passed early last year and it goes into effect at the start of 2023.

I’m not a big fan of your implication that there’s something wrong with discussing legislation while it’s still pending, though. That’s honestly the best and most useful time for people to be discussing it.

If Microsoft asserts and represents that their tool doesn’t generate copyright-infringing code, then surely Microsoft is the party which should be liable, rather than the poor unlucky programmer who was lied to by the billion-dollar corporation’s marketing agency?