dperfect

> The IPO is the carrot that you're dangling ahead of early employees many years prior to getting to that point.

Yes, that's essentially what I'm saying, but I wonder if there aren't some better alternatives to incentivize early employees when cash is scarce. Maybe (just off the top of my head) something like a contract to pay the employee a set dollar amount (with interest) at an undetermined point in the future, and it must be paid before any profits can be distributed to owners (there could be other triggers as well). This would be in addition to the employee's salary, which is likely to be at below-market levels when the company is still young.

It could come with additional features similar to a vesting schedule, but essentially it would (1) give the employee a known dollar amount of compensation contingent on the company's future success, (2) allow the company to remain private (if desired) while still delivering the "carrot", (3) avoid the need for an option pool, and (4) avoid the issues I described in my earlier comment. After some or all of that amount is paid to an employee, the difficulty in keeping the employee around is no different, but at that point (where profitability allows for the payout), a company is more likely be in a position to offer/renegotiate competitive salaries in the first place.

Then again, a lot of founders/owners probably don't want something so concrete because of course they benefit from being able to attract talented people at a discount by offering a tiny bit of equity and the dream of becoming a millionaire when the company IPOs or gets acquired. Heck, I've been there - on both sides of the conversation. But the truth is, a lot of people are realizing that equity isn't usually worth what a founder thinks it is, so that's becoming a less effective bargaining chip as time goes on.

This makes sense from an investor’s perspective. My objection to IPOs is not so much financial, but more about what it does to a company’s internal culture. Having been at a company that went through an IPO, I saw how that culture shifted - almost overnight. You had employees that once cared about doing their best at their jobs to ones that focused only on how their contributions would affect the public stock performance (which can overlap, but often doesn’t). Every time the stock price took a (short-term) hit, employee morale suffered. It was as if a large LED stock ticker were installed on every desk, constantly reminding employees that this is the new key indicator that matters above all. It was obvious even among upper management; discussion went from big picture, somewhat ambitious ideas to short-term thinking, centered on how to show good numbers in the next quarter with obvious, incremental adjustments (like pushing more ads rather than developing more interesting products and features).

The funny thing is, the company didn’t actually need the funds raised in the IPO. They had an almost endless supply of interested private investors pouring in money regularly, and the company’s CEO (in private) admitted that they never wanted to do an IPO. It was only necessary in order to appease the expectations of early employees who had been promised a big payday for the shares they were offered instead of competitive salaries. I understand why that was done in the company’s early days, but there ought to be a better way to reward/incentivize early employees that doesn’t rely on the fickle and myopic nature of publicly-traded stock.

I'm on a fairly new machine (i9-9900K OC'd to 5.1 GHz, 32GB RAM, NVMe, RTX 2080 Super), and I was expecting smooth, stable frame rates at 1080p. Unfortunately, the game seems to be limited by one or two CPU threads consuming a constant 90-100% of those cores, while the other cores hover around 10-25%. As a result, I get fairly decent frame rates (25-50fps, depending on the area), but even in the best cases, it has a really annoying "micro stutter" that randomly - yet consistently - interrupts what would otherwise be an amazing experience.

I'm hopeful that an update could improve performance, especially with respect to spreading CPU load over more cores, but it sounds like a lot of other simmers are mostly content, so maybe that will never happen.

My experience has been the opposite; it's significantly faster than any screen sharing I've ever used, and I've not encountered any bugs so far. I suppose there are a lot of factors at play (connection speed, server specs, phone specs, etc), so YMMV.

FYI - you can host this yourself in a docker container using https://github.com/cdr/code-server .

I recently set this up on a server running from my home (only accessible via WireGuard) precisely so I can code anywhere from my iPhone. Combined with a folding bluetooth keyboard (because typing code on an iPhone screen is terrible), it's turning out to be a pretty useful portable dev environment.

I'm not faulting consumers for wanting free stuff. If anything, it's a symptom of companies (and investors) putting too much value in vanity metrics and expecting that it will be easy to transition to revenue.

I've seen it first-hand: startups intentionally forgoing revenue so they can be measured by the stick of imaginary future profits correlated with their free product's success. Then when investors finally do start asking to see real returns, it's a scramble to find something that doesn't involve charging their current user base (because of course no one wants to pay for something that has been free previously). That's when the "creative" money-making ideas start getting real consideration.

In effect, those actions end up communicating to the public that software is free when it really isn't. It gives the impression that there isn't a cost associated with developing and maintaining software, when really it might just be funded temporarily by investors with deep pockets and high expectations, or supported by other revenue sources that the end user would not agree to in full transparency.

It's true - charging for something that was once free can be risky, but it isn't always bad as some might believe. I have great respect for businesses that charge for a service that provides real value - even if it was once free. Often times (especially in the startup world), companies start out offering a free product (operating at a loss) to gain market share. It's not often the best strategy, but in some markets it's one of the few ways to break in and gain traction. Obviously, you can't sustain operating a business that way forever, so you eventually have to make up for it somehow.

Unfortunately, a lot of tech companies have (perhaps unintentionally) conditioned consumers to expect software to be free. The terrible consequence is that in response to that pressure, many companies choose ethically-questionable ways to make money when they need to, rather than simply charging a fair and honest price for their product (this includes selling users' data, overwhelming the user experience with ads, in-app purchase shenanigans, etc). Paying fair prices for things we use isn't the most appealing idea in the world, but (in my opinion) we probably need more of it, not less.

Yes, you and I both recognize that they're only talking about the VPN's own websites, but I'd bet good money that a majority of less-technical readers (not HN readers) won't understand that distinction. It feels like the author knows that, and deliberately failed to point out the fact that the tracking in question doesn't affect a person's privacy while using the VPNs.

Case in point:

> Remember, these trackers are made so that they can track your online behavior, and follow you wherever you go on the internet. Having even 1 of them on your website really defeats any argument for ultimate privacy and anonymity.

Tell me that isn't trying to scare the reader into thinking the trackers can follow your activity while using the VPNs.

Maybe it's just me, but it feels like this is trying to scare people into thinking that the VPNs mentioned are doing this tracking on the sites you visit while using their VPN, when it's really only about the VPN's own website (which people usually visit only when they sign up). It doesn't explicitly say the tracking is happening while using the VPNs in question, but I would bet a large portion of readers assume that's what they're saying.

It really doesn't bother me if a VPN company uses trackers and other tools to optimize their own website, other than the fact that some third parties may have good reason to believe that a visitor uses a VPN if the person visited the VPN's website. That says nothing (or very little) about how private you are when actually using the VPN.

In the spirit of asking silly questions (as encouraged in some comments here), here's mine:

My small SaaS company's PostgreSQL RDS instance and app servers are in a VPC with security groups configured to only allow connections from the app servers to the DB (no public access to the RDS instance). My client (ruby-pg) on the app servers is connecting via SSL, but not currently with certificate validation (though I believe the cert date still needs to be valid [?], hence the need to rotate the PostgreSQL server's certificate).

In this scenario, how important is certificate validation? I understand the theoretical risk of clients not being able to fully trust that they're connected to the database I intend, but from a practical standpoint, it seems that if an attacker is able to poison the VPC's DNS and trick the app servers into connecting to something else, I'm already hosed and cert validation wouldn't do much to help me. Am I missing something obvious and very dangerous?

Fair enough, and what you do sounds cool. What I'm saying isn't really directed at you specifically, but rather to the people I see/hear every day making the same claims in a business context. A lot of vanity metrics without a lot of connection to the bottom line.

> I use my IG for promoting my music and need to know how well each post is doing ... There’s literally no point for me otherwise.

(assuming your comment wasn't sarcastic - maybe it was?)

I've never understood this. Shouldn't the metric for how well a promotional post performs be... actual sales (or at the very least, traffic to whatever you're promoting)?

Granted, likes might be a useful proxy metric for (roughly) gauging interest in something, but are you really making important business decisions based on a post's likes? What are you comparing those numbers to, and how do you know what they mean in terms of real business impact? How do you know people are responding to the product, and not just the model (or "influencer") you happened to use in your promotional image?

As others have pointed out, the claimed link between banknotes and terminal dimensions is unclear, if not flat out wrong. The article's own logic is missing a crucial connection right here:

> At one point sales of punchcards and related tooling constituted a completely bonkers 30% of IBM’s annual profit margin, so you can understand that IBM had a lot invested in getting that consistently, precisely correct.

> At around this time John Logie Baird invented the first “mechanical television”; like punchcards, the first television cameras were hand-cranked devices...

It goes on to argue that the television standards influenced terminal dimensions, but there is no link (unless I missed something) between the banknote/punchcard discussion and that of the television - other than the fact that they used hand-cranked devices. No mention as to the punchcard's size/dimensions being carried over to television (and by extension, terminals) other than what appears to be a coincidence in the number of characters fitting on a line of a punchcard.

Looking at the origins of the television standards (at least for the number of terminal lines, since the number of characters per line seems to have been influenced by typewriters), one could trace it back to William Kennedy Dickson (created the 35mm standard by cutting 70mm roll film in half), or previously to Peter & David Houston and George Eastman for their creation/marketing of early roll film cameras.

The most interesting thing about this (compared to results from similar research/projects) is that in all of the examples, camera movement is forward and down relative to the original perspective. The results are really good, and some of that may be due to a superior algorithm, but it's also aided in large part by the choice of movement. Since objects lower in the frame tend to be closer (foreground elements), the downward camera movement causes those objects to occlude parts of the background above (and behind) them, meaning that a relatively small portion of the background needs to be inpainted by the algorithm. If too much is interpolated, visual artifacts often ruin the illusion.

The forward movement also helps in this case as those foreground objects grow in size (relative to the background) with time, so there's even less need for interpolation. If the movement were primarily lateral (or reversed relative to the original image), I imagine the algorithm would have a much harder time producing good results [1].

EDIT: After skimming the paper, it appears that the algorithm is automatically choosing these best-case virtual camera movements:

> This system provides a fully automatic solution where the start- and end-view of the virtual camera path are automatically determined so as to minimize the amount of disocclusion.

That is pretty impressive. I had originally assumed the paths were cherry-picked by humans, so it's cool that the paths themselves are automatically chosen (and that the algorithm matches the intuitive best-case scenario in most cases). It's still slightly misleading in terms of results because they mention that user-defined movements can be used instead, but of course, the results are likely to suffer significantly if the movement doesn't match the optimal path chosen by the algorithm.

[1] The last example shown in the full results video illustrates the issue with too much background interpolation in lateral movement: http://sniklaus.com/papers/kenburns-results

> No server needed. No expensive hardware required... You can use your Router, NAS, Raspberry Pi, Smart TV.

So... it turns those things into servers then (many of which already run servers by default)? Maybe I'm misunderstanding, but a device running server software is still a server, even if it isn't dedicated to only that task.

> Why can't you simply average adjacent frames during your framerate decimation?

In theory you could, but in practice, it doesn't work very well and you tend to get some really nasty artifacts depending on the motion of the scene. There's a lot more to it than simply averaging adjacent frames since those source frames likely aren't capturing perfect 360° shutter angle time slices that seamlessly align (temporally) back-to-back.

> Superior reproductive technology in no way prevents you from creating a scene that has that and any other kind of artificially applied crappiness...

The technology to produce movies at high frame rates has been around for a long time (and projection/display technology could have supported it much sooner if the content were there), and yet directors have deliberately, almost universally chosen what you categorize as "artificially applied crappiness" (24 fps). Practically speaking, it is artificially applied, and that's exactly it - it's an intentionally distorted version of reality, and it's that way on purpose. You're free to attempt to remove that filter (by smoothing motion on your TV), but that doesn't represent what the director intended.

Even with "superior reproductive technology", directors are still choosing to produce films at 24 fps, so can you at least appreciate and respect that that's how most of them intend their work to be displayed? True, "reality does not judder" (proper 24 fps content doesn't either, by the way), but reality isn't what filmmaking is about. To argue otherwise misses the point of film as an artistic medium. For other types of content, I agree - reality is the target, but not in film.

Yes, cinematographers do vary the shutter angle for artistic purposes, but that just confirms the fact that the amount of motion blur present in a film is a deliberate artistic decision rather than a side effect of using an "antiquated" frame rate.

As for downsampling, I believe your math is off. 120 fps at 360° means each frame is exposed at 1/120s. Conforming that to 24 fps gives you the same exposure duration per frame (you're just throwing out 4/5 frames), so you're effectively at a 72° shutter angle - less than half of what's considered "normal".

> I find the suggestion that videogames don't need to suspect disbelief, but films do, very strange.

True, the distinction may seem strange to some, and it's not always a clear distinction. Here's how I'd describe it in more detail (just my opinion of course):

In film, we see a person depicted on the screen with certain characteristics that convey emotion (just as we do with a group of lines comprising a stick figure with similar emotion), but we are forced to activate parts of our brain that span the gap between what we see (which obviously isn't reality) and what that character might feel in his/her universe.

To some degree that same experience happens in video games, but I would argue that instead of seeing the emotions and trying to understand them, we (as players) are the person feeling the emotion. In one, we are witnessing events happen to someone else (and exercising empathy), whereas in the other, we are experiencing the events first-hand (even in a 3rd person view, we're playing as if we are the character in view).

A first-hand experience feels most believable when it's actually realistic (hence the need for high frame rates), but a simple stick figure can feel "believable" if we're engaged and sharing the emotion we believe it to be feeling.

As a side note, maybe that's why I personally prefer classic (8-bit era) video games over modern 3D video games :)

Yes.

"By far the most common setting for cinema has been a shutter angle near 180°, which equates to a shutter speed near 1/48 of a second at 24 fps." [1]

"A 180° shutter angle is considered normal." [2]

[1] https://www.red.com/red-101/shutter-angle-tutorial

[2] https://en.wikipedia.org/wiki/Rotary_disc_shutter

> You can losslessly go from 120 to the other popular frame rates, including 24.

Not true. Something filmed natively at 24 fps and a 180° shutter angle is vastly different in terms of perceived motion than 120 fps converted to 24 fps.

Panning shots probably look awful if you're watching 24 fps content on a device running at 60Hz (many consumer devices, computers, and Blu Ray players do this by default). Since 24 frames can't be evenly spread out over 60 frames, you'll see motion judder, and it does look terrible.

However, 24 fps running at a true 24Hz is perfectly fine, and you will not see flicker - at least not if produced by competent filmmakers. That's because the camera's shutter angle is normally set such that motion blur makes the motion look smooth. Real cinematographers also know exactly how fast they can pan with a given lens without causing any noticeable strobing motion.

Comparisons to video games completely miss the point. Most video games are unable to properly simulate motion blur (some try, but it doesn't usually work well), so you have to have high frame rates for things to look smooth. Since you need to react quickly in video games, high frame rates (combined with the lack of motion blur) are also helpful in preserving crisp edges on moving objects (so it's a practical advantage). And finally, video games generally try to simulate reality for the player, so players are more concerned that the technology makes the experience believable rather than intentionally suspending disbelief (as in film or theater) to passively unpack the narrative nuance of artwork unfolding on a screen.

For those same reasons, sports also do well with higher frame rates, but when fiction (which is obviously disconnected with the present reality) tries to use high frame rates, it falls into "uncanny valley" territory - much like the computer-generated humans of movies like "The Polar Express". As others have noted, a few directors have really tried to push HFR film to the public, but it has never been received well (whether or not HFR is recognized as being responsible for the uneasiness felt by audiences watching HFR content).

As for HFR content being "easily" downsampled - it really isn't, at least not with respect to motion blur (which is an essential point that many people miss in these discussions).

From the article:

> he soon felt at ease in the Rachmaninoff, which he had prepared but did not expect to come until after the Tchaikovsky, in the final round of the competition [emphasis added]

It's a bit ambiguous, but it sounds like he had prepared to play it in another round of the competition, not in the same performance. There's a significant difference between having practiced a song and being fully (and mentally) prepared to play it in a specific performance.

I don't think this will do anything to help with the "crappy iPhone [app] ports to the iPad", at least not for a while. Those apps will still be there, and they'll likely still be approved in the future.

From my understanding, "iPadOS" is essentially just a marketing signal that the iPad-version of the OS will have more features unique to iPad. For developers, Xcode will still have the option to compile the same codebase for iOS and iPadOS. It's up to the developer to take advantage of more screen real estate when available, though SwiftUI will probably make that easier on the developer (i.e., more likely to show up in the apps you use).

I believe it happens for any guest OS (search for "amd reset bug"). Some people are using a workaround that involves removing the device (in the sysfs), suspending the host, and then rescanning, but for me, that's not much better than a host reboot, so when the AMD GPU occasionally does get stuck in D3 (preventing starting the VM after a VM reboot), I just reboot the host. It doesn't happen very often, and when it does, it's only when I'm in the process of rebooting the VM anyway.

Previously, I also attempted using a kernel patch that's been floating around (DECLARE_PCI_FIXUP_HEADER ... quirk_no_bus_reset), but it just gives me corrupt graphics when rebooting the VM.

In case anyone runs across similar AMD GPU issues, the "disable_idle_d3=1" option in the second pastebin link (when used as a kernel parameter) should be prefixed as "vfio-pci.disable_idle_d3=1". Even then, it can still be hit-or-miss with some cards (it works most of the time for me, but some VM restarts still find that the GPU has entered D3 and won't come back without rebooting the host).

I don't have any specific guides about my setup, but here are a few things that have been helpful to me:

- Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM

- DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in...

- AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d...

- Kernel extension that can help with some GPU issues: https://github.com/acidanthera/WhateverGreen

The DSDT/SSDT patch was probably the trickiest thing. I've posted my particular patch here if you're interested: https://pastebin.com/ngvkVZYN

Also, a few of my other scripts/config: https://pastebin.com/9Nh5rheZ

I do this using Proxmox (QEMU under the hood), and it's been mostly a nice experience. I currently run 3 VMs on a single Linux box with 3 GPUs (one per VM via VFIO passthrough). I've used both NVIDIA and AMD graphics cards with success. Before Mojave, NVIDIA cards were easier with their web driver, but Apple and NVIDIA don't get along in Mojave (both companies are blaming each other) and there is no web driver. So for macOS, I've switched to an AMD GPU which works mostly out of the box, apart from needing a small tweak in the Linux host's kernel parameters ("disable_idle_d3=1" to avoid a bug preventing the device from being used after a VM restart).

To get macOS to see my GPUs with full acceleration and audio over HDMI, I use the Clover bootloader to inject a small section into the DSDT, mapping the emulated PCI address to a device that actually looks like a graphics card to macOS. This same DSDT patch works for both NVIDIA and AMD GPUs (the ones I've tried anyway).

The best thing about Hackintosh in a VM is that you no longer need to fear macOS upgrades. Just create a snapshot, try the upgrade, and if it doesn't work out, you can restore, investigate, and try again.

LTT's video is a nice overview, but his claim that "because this is a VM... it will run on any hardware" isn't quite true when talking about GPUs. Unlike the CPU, memory, and some other devices, the GPU is seen (nearly) directly by the guest VM, so guest OS support is in fact required to see the advantages of GPU passthrough.

In summary, it's never going to be super easy, but it's not too difficult either, and the performance (and flexibility) is actually really great.

Spotlight in macOS is terrible when it comes to this sort of thing, and it's been that way forever. I can't count how many times I've tried to launch an app with Spotlight only to realize that macOS has conveniently replaced the highlighted top hit (that I wanted) with something else between the time my brain said "go" and my pinky hit "return".

For more context into Facebook's decision-making process when it comes to censorship, you might find this episode of Radiolab insightful (it was for me):

https://www.wnycstudios.org/story/post-no-evil

From what I recall: Facebook's dilemmas over how/what to censor have existed since very early in the company's history. Internally, FB developed a policy document - separate from the public one we see - which would be applied by both human and AI enforcers. The employment of those human enforcers could be considered unethical in itself (at least without providing adequate therapy). Over time, the secret policy document has grown substantially to account for a lot of edge cases. While terrorist/graphic violence is normally censored, there are provisions for allowing content that would otherwise not be seen/known if not shared on FB (e.g., content that governments seek to cover up). Still, there is considerable internal disagreement among executives at FB when it comes to handling edge cases.

The fact that this secret document (and the processes that define and apply it) has so much power in shaping public perception, politics, etc. with so little transparency is perhaps the most disturbing part of this.