HN user

ecdavis

858 karma
Posts4
Comments213
View on HN

I think this comment oversimplifies gambling addiction. Yes, chasing losses is a behaviour common to many gamblers, and yes, winning money provides an incentive to gamble in the first place, but many (most?) gambling addicts have different motivations.

Here are some quotes from _Addiction by Design_, by Natasha Dow Shüll -- a book I highly recommend if you're interested in this subject:

Julie explains: "If it's a moderate day - win, lose, win, lose - you keep the same pace. But if you win big, it can prevent you from staying in the zone." [...] "You're not playing for money," says Julie, "you're playing for credit -- credit so you can sit there longer, which is the goal. It's not about winning, it's about continuing to play."

[Pete says:] After sitting at the machine for fourteen hours, so tired I can barely keep my eyes open, no money in my pocket, no gas in my car, and no groceries at home, I still can't leave because I have four hundred credits in the machine. So I sit there for another hour until it's all gone, praying for me to lose: "Please God take this money so I can get up and go home." You might ask, "Why didn't you hit the cash out button?" That never occurred to me -- that was not an option.

I don't think the importance of the monetary payout is particularly clear-cut. The payin is what does the financial damage, by moving money out of the player's control. The incentives and reinforcement are what get the player hooked -- but perhaps those don't have to be financial? I won't discount the importance of the payout entirely; maybe it's critical to get hooked in the first place? But I also wouldn't be surprised if gambling addiction can arise in games which don't provide to ability to cash out.

So, if the plaintiff can prove the content was pirated, then the use of that content downstream is tainted.

Has that been tested in court?

This is quite an interesting case.

Obtaining the book in the first place[0] appears to be quite a clear case of copyright infrigement.

The question of whether a work derived from the book is infringment is pretty complex, and there's a wide range of tests that get applied to determine that.

But is it necessarily true that if you obtained the original work via copyright infringement and then created an otherwise non-infringing derived work, your derived work is nevertheless infringing due to the provenance of your copy of the original work?

[0] https://news.ycombinator.com/item?id=36659041

What you're arguing for are more accessible immigrant visas ("green cards").

AFAIK there is nothing currently stopping a US company from hiring a person, sponsoring them for an immigrant visa, and then waiting for that immigrant visa to be issued before the person relocates to the US. The main issue with this approach is that it takes many years for immigrant visas to be issued and companies want people to relocate right away. If an individual could use a current I-140 to get an infinitely-renewable non-immigrant visa I feel like that would resolve most complaints that we see about the H-1B here on HN.

If the H-1B visa was changed like you describe above I think it would leave a gap in available US non-immigrant visas. I think that gap would end up being filled by a new type of non-immigrant visa functionally very similar to the current H-1B. The H-1B visa serves an important purpose[0] which has been wildly distorted by tech companies using them for permanent employees on the pathway to permanent residency.

[0] Its intention was to provide US firms unable to find specialist workers locally with a means to fill vacancies with temporary workers.

I've used this for many real applications that I would characterise as small (biggest being ~10KLOC excluding tests, types, etc.). I've applied the pattern across entire codebases and to specific components within much larger codebases which follow other patterns. I tend to combine it with some of the ideas in Mitchell Hashimoto's talk Advanced Testing with Go[0] - particularly small interfaces and defining test stubs alongside real implementations.

In practice my imperative shell tends to have two layers. The inner layer is responsible for executing the imperative logic, while the outer layer is responsible for initialising configuration and dependencies, invoking the inner layer, and adhering to any sort of external interface that it may need to satisfy. Everything from the inner layer down through the functional core can be comprehensively tested using stub objects only -- no need to patch anything.

Unfortunately everything I've applied this pattern to is proprietary, so I can't share any code examples.

[0] https://www.youtube.com/watch?v=yszygk1cpEc

I agree with the parent and grandparent comments.

That said, when I was sponsored for an E-3 visa by a US company the recruiters made it clear that my position was permanent (subject to performance) and that the company would sponsor me for a Green Card.

These representations were contradicted by the legal documents I presented in my interview at the US consulate.

Nonetheless, I can imagine some employees on these sorts of visas might take their employer at their word and plan their lives accordingly.

The one doesn't excuse the other; if you're required to keep this data you should be treating it with the respect it deserves.

That said, yes: government legislators and regulators have been zealously telling private companies to hoover up sensitive PII for years. Here's ACMA's rules for customer auth for telcos: https://www.acma.gov.au/customer-identity-authentication-rul...

There are efforts underway to enable complying with these rules _without_ hoovering up data, but they are not progressing nearly as fast as they need to.

Ah, yeah, "restart the process" was not the right description of what was happening in the cases I was thinking of - they'd exec themselves to hot reload code which I see is the first suggestion on the SA answer you linked.

Depends what you mean by server.

Some old game server processes would support a "copyover" function. They would write the file descriptors of connected sockets to a file, restart the process, then read the list of file descriptors back into memory and resume normal use of the socket. Unsophisticated, but it works. It's completely transparent to the client because the connection is never actually closed. The worst the client might experience is some latency as their input gets buffered by the OS while the server process restarts.

Of course the connection would not persist over a physical server restart (or something like a pod being killed or whatever). I imagine it's possible to move a connection between nodes, though, with a fairly similar process.

Highly complex, in-depth, system simulation is like a siren song for game developers and players alike.

There's this perception that an amazing simulation will be the basis for an amazing game.

In practice, high-quality simulations seem to be interesting but not all that fun. See: F.E.A.R.'s Goal-Oriented Action Planning (https://alumni.media.mit.edu/~jorkin/goap.html) which had to be modified to broadcast its intent to the player, because play-testers felt the game was unfair and that the A.I. was cheating.

And it also seems like players can't really tell the difference between a sophisticated simulation and a handful of heuristics with some calls to random() thrown in. From the perspective of a player who does not know how the simulation works, the latter can _seem_ like the output of a complex system. See: _Designing Games_ by Tynan Sylvester, developer of RimWorld (https://tynansylvester.com/book/).

Dwarf Fortress, I think, is the exception which proves this rule.

Anyway, I think simulations like this are really cool to build, but hard to turn into a fun game.

I don't watch baseball, but I always assumed MLB.tv and NHL.tv used the same technology.

The way NHL.tv used to work, the blackout check would be done when you opened the stream. So you could connect to a VPN in, say, Germany, start the stream, then disconnect the VPN and after a brief interruption the playback would continue. If you did the VPN connection from your router you could stream from any device, too.

Funny thing, the ads always seemed to know exactly what market you were in.

I worked for the APS as a very junior programmer 10 years ago.

To interact with our database we had a custom JDBC driver which used a VT100 terminal emulator to connect to what had at one point been a user-facing mainframe application. When a query was executed, the driver would:

- Emulate a user entering a series of key-presses in the terminal to navigate to the correct screen in the application.

- Tab to the query input field, enter the query, then send a return key-press to run the query.

- Read 20 rows of output, then send a key-press to show the next page of results, rinse and repeat.

- Parse the array of rows-represented-as-strings into properly types objects.

- Repeatedly "press" escape to get back to the main screen so that the application state would be ready for the next query.

One of my first tasks was to make this driver work with a column type that stored binary data.

I kind of admired the ingenuity.

Why Tony Blair is singled out, for something in hindsight, and the other 411 people are given a pass?

Your point that the legislature voted on the invasion is a reasonable one, but Blair's government gave them incorrect information on which to base their vote.

Blair was the head of the government that produced that bad intelligence. It makes sense to single him out.

"The buck stops here," and all that.

Foxes were introduced to Australia for sport hunting, not to control the rabbit population. The presence of rabbits likely helped foxes spread across Australia.

I agree with your point, though.

As you learn the measure, increase speed, but only so much that you can still play expressively.

This summary omits one of the major themes of the book. Granted, the discussion of speed is quite nuanced. See 1.II.13: https://fundamentals-of-piano-practice.readthedocs.io/chapte...

One relevant excerpt, though large chunks of the book are dedicated to this topic:

To vary the speed, first get up to some manageable “maximum speed” at which you can play accurately. Then go faster (using parallel sets, etc., if necessary), and take note of how the playing needs to be changed (don’t worry if you are not playing accurately at this point because you are not repeating it many times). Then use that motion and play at the previous “maximum accurate speed”. It should now be noticeably easier. Practice at this speed for a while, then try slower speeds to make sure that you are completely relaxed and absolutely accurate. Then repeat the whole procedure. In this way, you ratchet up the speed in manageable jumps and work on each needed skill separately.

I think it is the fault of the MUD developers, because they feel like they must support those players.

The group of people who play MUDs "traditionally" (with a dedicated, telnet-based MUD client) is small and shrinking every year.

The group of people who play lo-fi, retro-style games is large and growing every year.

Why give special treatment to the former group if it hinders your ability to appeal to the latter group?