CHY872

I do some sim racing. I can race for hours with a Reverb G2 but get nauseous within minutes with a Meta Quest Pro.

From my perspective:

1. Eye tracking for interaction vs hand tracking. If the UX works out, the amount of precision that can be reached is just far higher with less effort - just seems to be an easier technical problem.

2. Resolution and lensing. Most VR headsets have fairly low quality fresnel lenses which cause distortion near the edges (basically - if you want to see something in good detail, you have to tilt your whole head to look at it), and in general the resolution is not good enough to see things that are 'far away' (those who play games like DCS have to use the 'binoculars' feature with headsets to accurately see targets). With a device like an HP Reverb, the resolution is probably close to good enough, the lensing is not - the Meta Quest Pro has a good enough lens, but not resolution. I'd expect the lensing on the Apple device to be top of market, and we know the resolution is ~2.5x more dense than the Meta Quest Pro - which should be closer to going from SD to HD TV rather than HD to 4k. Essentially, if you try to code on a Meta Quest Pro, the text looks a bit blurry. With the Vision Pro, it won't.

3. Custom face cushion + prescription lenses. Comfort is everything with these devices and nothing is worse than a headset putting pressure in the wrong places. It'll cost much more, but be totally worth it.

4. People claim common nausea when using VR. I've felt it too, but only on certain headsets. My money is other companies know what causes folks to feel bad, but have had to make technical tradeoffs which mean that nausea remains a problem. I'd put money on Apple having done serious research into 'what causes nausea when using headsets' which causes this to minimised on their headsets.

5. Software stack and usability. VR stacks are typically fairly clunky, usually Android derived, usually behaving a bit like a dodgy phone. iOS/MacOS are usually not most feature-ful, but a core usually works very very well. Will likely push bar a lot higher, change the shape of industry (e.g. samsungs are so good because of the iPhone competition).

Basically, having used some of these devices - the complaints I have with these right now, are the same things that Apple has real, technical solutions for. And the price isn't even _that_ high compared to other players in the market. Pimax Crystal is $1600 for what right now is a fairly buggy user experience. Their vapourware Pimax 12k is listed as starting at $2400 for the most basic model, though it's been in that state for well over a year.

It's also worth noting that this is dependent on model. E.g. I can handle an HP Reverb G2 indefinitely, but a Meta Quest Pro for only about 30 minutes before I feel ill.

IBM = big blue. Red Hat were bought by IBM a few years back.

Obviously, it depends. If you’re anywhere near London, you’ll probably have visited the Oxford Street/Regent Street/Carnaby/Seven Dials areas. The former is pretty horrible with half the shops fairly transparent money laundering operations, the latter are nice areas to visit with nice shops and restaurants. The difference is that the latter are single-landlord developments where the former is composed of many landlords each trying to get the highest bid. The difference is the landlord’s value add.

It really depends on how automated the prover is, this is kind of like reinforcement learning optimising something unintentionally. Theorem prover bugs are problematic if relied upon, but most of the bugs folks cite are only usable in very strange circumstances, and most practitioners will not see their results invalidated by such a bug. E.g. iirc falso required a type with more than 256 variants. If you don’t have one of those, it won’t affect you!

Essentially, you fix the bug, re-run your hol or whatever, and hope your theorem is still true.

Obviously this only applies to bugs in the implementation as opposed to an unsound logic.

Naked shorting certainly leads to unlimited losses, but it’s not the only kind.

Simple example is that i can buy a put option in some company. If the stock price falls below that point, I buy shares and sell them to the option writer and make a profit. My maximum loss is limited to the amount I spent on the option.

Likewise the put seller has not taken unlimited risk - their risk is limited to the cost of the shares they’ve offered to buy at.

10% is close to the point where airlines would retire their planes earlier in order to reduce their fuel cost, as planes spend their value on fuel every 5 odd years.

I've seen a few 'old boys clubs' form, and the conclusion I've come to over time is that a large part of this is due to two characteristics. The first is that it's very hard to find credible talent. Think about the people you've worked with - there's probably 100+ or so of them, yes? Now think of how many of them you think are really exceptionally good. Probably only a few, even amongst people with the same role, and it likely took you quite a while to realise that. So, when you come to hire someone, you look at your network, because you've worked with a lot of people, and have opinions on who is and is not good. You simply have more information. The second is that once in a more senior role, it's much harder to judge whether a peer is doing a good job or not, because you don't see a lot of their work and you're likely more reliant on self reported state of world. That tends to weaken your decision making ability on the above, while heightening the importance of doing it correctly. Neither of those things are excuses, but they're certainly reasons. I think it's relatively straightforward to find incompetent executives who've wasted money and who are known for this.

I think you're reading a little too much into that. I think it's worth comparing it to other forms of evidence. It's incredibly common in civil disputes for one party to give untruthful evidence, sometimes out of malice, sometimes simply due to the human psyche (plenty of evidence of people believing falsehoods after all). Likewise, tampering with physical evidence is far from new - tampered photographs have been going around for over a hundred years, while altered financial records and planted drugs are seen in a court somewhere every day. Practically then, the status quo appears to be that if a prosecutor or litigant has done some due diligence and have a good faith evidence based conclusion that the evidence has not been tampered with (by e.g. having the cameraperson swear under oath that the video is an accurate representation of what they saw), then they will be allowed to present it, and that won't change with the proliferation of deepfake video and audio.

At that point the reliability of the evidence may of course be called into question, as with any evidence or witness. The question mark would be whether it was convincing.

I think most EV drivers will tell you that they use the brakes very infrequently - perhaps once or twice per hundred miles if one is driving long distances. Certainly if you're careful it'd be possible to never use the brakes. I think that's what EV owners think of as different to traditional cars. Yes, brakes can last a long time on traditional cars, but it seems intuitively obvious that if you're just not using them, they'll last longer for the same equipment.

While it’s true that if you were e.g. traversing a random linked list doing pointer chasing, that might be true, it should be noted that the effective number of operations is significantly improved by the prefetcher. For example, on an i7 9700k, memcpy can copy at 13.7GB/sec, which is probably 400M operations in practice.

It's worth saying that GitHub also has GitHub AE, which has some requirements (e.g. 500+ heads) but is a lot better for paranoid administrators, offering stricter audit results (FedRAMP High is no joke), data residency, stricter auth requirements, etc etc. I'd _imagine_ that such an environment is deployed as an isolated managed GitHub Enterprise instance, and at the very least in that environment I'd expect all data to be secured encrypted at rest.

Yes, this is the way. Surprising how high level you can make this work - I’ve seen Collection implementations and all sorts.

Java uses thread local allocation buffers such that objects allocated one after another are typically contiguous in RAM. Most modern Java gcs are also compacting, meaning that the heap ends up approximately breadth first ordered after GC.

What this means is that in practice, pointer chasing is less of an issue than you’d expect. Even a linked list will end up with decent cache locality.

Obviously this won’t always work, but it generally works a lot better than the same structure in a systems language.

https://shipilev.net/jvm/anatomy-quarks/11-moving-gc-localit...

And the FAA is a bad idea because it insulates travelers from the need to monitor what their plane is doing?

I know a team who used JooQ (code-generated query builder for Java) to generate SQL which worked on both Postgres and Oracle and worked well enough that they could support both in production (Oracle for top end perf, Postgres for everything else). There were certain places where they had to switch on SQL format, but over years they felt comfortable enough only unit testing on one kind of database.

Few things: Regarding unit testing, it's now very possible to productively unit test a SQL database - I'm familiar with a Java package that boots up an embedded PostgreSQL, obviously Docker is now in vogue, etc, etc. It's not quite 'just run a function', but you write your code in the same style as a unit test and you're running hundreds of tests in seconds. You can use transactions to automagically clear out your state, which means performance is also excellent. Regarding the standardization of the language - no, it's not totally standard (although arguably that's a good thing, we don't want 10 implementations of exactly the same thing, they'd never evolve), but because they all work sort-of-the-same, a lot of language support ends up transferrable. You can use ActiveRecord on many backing databases, for example. Query planner problem is definitely true, know folks who've spent a lot of time hinting Oracle and scaring Postgres into the same, though personally only took a few days.

However, SQL is IMO the best of a bad bunch. Most non-SQL databases I've used have been extremely sharp cornered, whether this be via: unpredictable/unbounded worst case performance in pessimal storage cases (RocksDB, Cassandra), various parts of the code where unbounded memory/storage usage is required (Cassandra, Spark, Elasticsearch), extremely low level APIs making it easy to make unobservably (as in, you won't notice it and will eat the pain every read) slow APIs (RocksDB). I'm not saying there's nothing better, but it's probably not an all-rounder.

There are certainly things I don't like about most SQL databases. Few SQL databases are columnar, which is _the_ key to good performance in the 2010s, and native LZ4-style data compression is also not widely used. But for most engineers they solve a lot of problems for you without having to think about them.

In the USA my expectation is that the higher fees cover two things. The first is much higher all around credit limits - with higher fees you can handle more delinquency. In the UK it's typical to get a credit limit of around 10% of your salary, whereas from what I know it's easier to get a higher limit in the US. That may be a good or a bad thing. The second thing is that some credit cards are basically an asset transfer from the poor to the rich. Get a Chase Sapphire Reserve? $500 fee per year, then you get $300 back immediately on travel, $0.015 on travel per dollar spent ($0.075 if spent on flights), $25/year value on global entry applications, and various free other things (airline lounge, auto rental insurance, etc etc). You don't get that if you're poor.

This is an older article (2012) showing how one excellent UK university does admissions. I think it covers some of the challenges your statement implies and showing some of the hard work such universities do. There's an interesting anecdote about a student who tutors believe simply won't keep up with the course due to starting from too far back (they are described as being from a hopeless school), another where a student has been guided by their school to study the wrong classes. In the UK, education is split into 'state schools' (free) and 'private schools' (paid for), and within both bands there is much variety, but in general private schools have better outcomes (as do state schools in wealthier areas). In the UK, this 'private vs state' debate is one of the most polarizing - should you be able to pay to win? At least at Cambridge, careful effort has dramatically changed representation over the last 20 years - from approximately 50% in 2000, to 62% in 2012, to 73% now (with private schools representing approximately 15% of students at age 18 this is a pretty good effort), and I think this article represents some of the hard work that has to go in to ensuring equality of opportunity (they describe: careful thought of each application, metadata held about schools, analysis of school provided documentation, etc, review, second chances, etc. they also do a _tonne_ of access things specifically designed to widen the funnel at all parts of the pipe).

I don't know or think it's the same for Stanford - after all, 16% of Stanford admissions are legacies - but it can be done with hard work! I'd certainly be interested in a similar article for Stanford, though.

https://www.theguardian.com/education/2012/jan/10/how-cambri...

I'm not sure about exact ratios, but in general society appears to agree that collective harm is worse. For example, the UK had 'Pals battalions' in WW1, and stopped when they realised that you could end up with whole villages losing all their young men in a single day. The damage to society from this tactic was too high, even if the camaraderie was short term better and the recruitment statistics were aided. If you wanted to learn more about why society cares more about collective death, I'd advise you start by researching topics like Pals battalions, on which plenty of research has no doubt been done.

But credit cards in the US also charge about 3%. Paypal’s somewhat pegging to what’s ‘reasonable’ in the locale.

K8s another example. Kind of amazing that Google effectively owns the now-standard deployment solution off of 'we don't really use K8s but want you to build your applications like us and K8s is a bit like something we do use'. At least Tensorflow's actually what Google runs internally (to best of my knowledge)!

It varies on focus area. Most big OSS projects are infrastructural in nature, and so if you're working in that space there's actually a lot of engineers who you meet with OSS experience beyond fixing random bugs. Even then, for every OSS engineer doing big OSS contributions, there are many who never do, it's just the nature of the business. I know of just one hiring decision (out of hundreds and hundreds) that was made because of OSS contributions, and I know no interviewers who routinely checked OSS contributions beyond surface level.

Ah, this is a bit of a false one. (A)GPL's pretty great for things that look like applications (or alternatively, pretty much anything GNU's ever made), but for anything looking like a library that is designed to be both free as in speech and free as in beer (Qt is the former but not the latter - want commercial usage? Pay us for a differently licensed edition!) it's a complete non-starter because it says that any usage of a library is a derivative work and infects. This is always going to be poisonous to any commercial use, and PyTorch and Tensorflow only gained the traction they have because they could be used commercially - they wouldn't have been successful if GPL'd.

Even LGPL is super challenging here due to requiring dynamic linking. This is fine in Java (unless you use Graal AOT compilation) and Python, impossible in Go, and at best discouraged in other compiled languages like Rust and C++.

I think there's likely a copyleft middle ground - something like the Mozilla public license seems about right, where it copylefts improvements without infecting users. I don't know why Google chose Apache 2.0 over MPL or the like - for something like Android it makes sense, for something like Guava it's not clearcut. But, when people talk copyleft, they're rarely, rarely talking MPL.

I think it's unlikely that Google opensourced Tensorflow with a view to getting some free dev hours, they're doing it to push their OSS agenda, to wield influence over how everyone else does work.

I think there's probably a few things here that are worth a comment:

- Information imbalance: from people I've talked to in decently senior roles at even very large companies, it might be surprising to learn that information can be poor at every level, because generally the people who are responsible for hiring at even fairly senior levels are not directly also responsible for expenditure, especially when macro-economic conditions are responsible for those financial decision. Essentially, the person who is responsible for setting the hiring targets to enable 20% growth is likely not responsible for modelling what happens if the cost of short term debt goes from 2% to 10%. Probably this is most likely in the superscalers, and it's likely hardest in the companies from 2-5k people - with a tech org of about 1k, you're likely acutely aware of the impact hiring strong people can have on your product while lacking the numbers to approach the problem analytically and with a sophisticated finance org. Basically, the number of people who could reasonably be expected to consider 'if we hire too many people, we'll have to fire them' as a significant part of their brief is smaller than you might think.

- 'There's no physical machine the company is adding that allows the workers to do their job which they couldn't themselves easily acquire'. Ignoring the focus on the physical machine bit and focusing more on the creative part of 'what does the company add, what do the people add', your claim may be true in some parts of industry and if you're in that side of industry I lament your situation, but for large parts of industry it's unequivocally false. There's a huge amount of value add that the machinery of an engineering organisation adds. In the more creative spaces, anyone who's operated in a truly high performing culture will have observed that a lot of the culture of building comes from the grouping of people who've been very, very carefully hired for, who've been carefully placed on team together, where memetic techniques have been used to proliferate certain positive behaviours, raising people up. We succeed as a team and fail as a team. You can see this over and over in so many testimonials - the stories from those who worked at Xerox PARC, stories from the MIT LISP hackers, back 50 years, all the way through hearing about the work the M1 team was doing, seeing the companies that spawn hundreds of startups from their alumni. And that's not to talk about the companies who specifically use process and ritual to ensure that engineers are consistently at the bar across massive orgs, from Google's exacting bars for code quality all the way to the consulting arms of Oracle, CapGemini etc who can approach repeated problems and get the most out of their engineers in a space where it's arguably harder to hire talent. And this is totally forgetting the huge non-SWE parts of orgs required to enable success - sales, finance, marketing, etc etc.

- Tech workers are still underpaid - think there'll be a rude awakening coming for you I guess. People across the world get paid based on how much they can get in the market (and if you're already at the company, the switching cost). There's room for places that do it differently, but not much room. If a large number of qualified people join the labour pool, you can bet that the practical market comp goes down.

- Paper losses are not true losses and you can just wait for the price to go back up: Honestly, that's wrong on like every level. Firstly, at the company level, there's a very real risk for many of these companies that they go bankrupt. Spotify has something like $2.8B in cash equivalents, has revenue of $9B and expenditure of about $9B. If their revenue dips by 20% due to e.g. a global recession, that cash supply will last them about 18 months. Before they get there, they have to raise more money. If raising via equity, they're going to be raising at their new and lower valuation, so their investors take a huge haircut. If they raise via debt, they'll be getting charged a lot on interest (because their risk of default is nontrivial). My brief but non-zero insider knowledge of some of these debt deals make it very much sound like a sellers market. A smaller company might expect to see 15% interest demanded - if you need $150M, you're in trouble. The staff who Spotify are dropping today likely represent $300M over that same 18 month period. You can bet that they'll be making this cut after scraping the barrel everywhere else.

Now, for the actual investors - if you take a massive paper loss, you're basically not getting that money back on a reasonable timeframe. https://danluu.com/norstad/risk-time/ is a good article on this topic. The simple way to think about it is that if in the good years you get 4% a year ROI across your portfolio and then you take a 50% haircut once, it will take you 18 years to make that difference back. The people who invest in tech companies are in large part not rich billionaires looking to pay for their next yacht - they're institutional investors, mutuals, pension funds who are looking to maximise returns for their members.

In general if you’re a professional software engineer, the productivity upgrade of upgrading your tools at least every 5-6 years is worth the money.

If you bought high-end-ish laptops in 2021, 2016, 2011, 2006, you’d have gone through 3 different microarchitectures, and had a transformative experience change on each upgrade. If you upgrade every year, not so much.

I don’t like the XCode MacOS version requirements - I couldnt build the JVM a while back because my work hadnt yet approved Monterey but XCode required it. That was annoying.

My experience with Glassdoor is that there is a significant amount of non-disgruntled employees reporting. I think this is because if you want to look at their data, you have to put in some details about your own employer. Certainly most people are writing either milquetoast feedback that gets them through the door or moaning about their employer so the information is biased, but it's not quite Yelp. Either way, Apple has 154k employees, it's such a large company that it'd be surprising if in aggregate it was the best place to work.

How does Clickhouse handle downstream aggregations? E.g...

  SELECT AVG(col) FROM (SELECT MAX(col2) AS col FROM table GROUP BY col3) t;

type query? Essentially, materialized views which are very unstable? Flink has its retract streams where rows can be semantically removed from the output and downstream query plans can understand deletes, but my expectation has been that these have bad worst case performance.

I’m not sure it is. For comparison, Arm A8 is superscalar (can issue two non-conflicting instructions per cycle) whereas the A9 is out of order superscalar. I think the linked Wikipedia article supports me, no? My understanding is that a structure like a reorder buffer is what makes the processor OoO.

> The superscalar technique is traditionally associated with several identifying characteristics (within a given CPU): > Instructions are issued from a sequential instruction stream > The CPU dynamically checks for data dependencies between instructions at run time (versus software checking at compile time) > The CPU can execute multiple instructions per clock cycle