4,399 karma · joined March 25, 2011
The initial keeper is happy, because it's cheaper for them. ~100% of them will lease it for <4 years, and you can consult my table to discover this.
Subsequent buyers are less happy... but, wait, fuck those guys. When N>0, the Nth owner pays owner N-1, not BMW. So previously BMW would see nothing from these transactions. And now there's a >0% chance these subsequent owners will pay them $80/year.
(Many software vendors have been trying to move to a subscription model. They want the recurring revenue. The iOS and Android video game markets have by now almost entirely switched to a free-to-play model - which is basically the same thing, just with a more compelling free sample, so they can sucker in the punters. This is basically the same!)
This might make a dent in resale values, but I assume the >0% chance of getting $80/year from future owners makes up for this. I do admit, though, that I really don't have a good feel for how this would play out.
Of course, people that buy a BMW with the intention of keeping it for >=5 years will get the shaft.... so I expect you can be sure that they've got good evidence that most keepers of a new BMW get rid of it before that point.
Maybe it's different in America or something, but in the UK approximately 100% of BMWs are leased, or bought with some kind of loan secured on the vehicle (I think based on estimated resale value when the period is up). So the "owner" will have the car for 2-3 years, maybe 4, then they'll chop it in for whatever's newer at the time.
With that in mind:
1 year. Old way: $300. New way: $0.
2 years. Old way: $300. New way: $80.
3 years. Old way: $300. New way: $160.
4 years. Old way: $300. New way: $240.
Cheaper! 5 years. Old way: $300. New way: $320.
OK, but I wonder how many people keep their car for this long?The roads end up mainly for traffic anyway, because people aren't dumb, and they're well aware that most drivers would prefer to kill them than make the effort to press the brake pedal. But there's no need to enshrine this in law and prevent people from crossing where they please when the road is empty, the traffic light and/or slow-moving, or the mass of people large enough.
In my experience, if you have a language with a compilation-like step, e.g., assembly language, then you automatically have a massive advantage over a language without, e.g., Javascript or Python.
The advantage over languages such as Javascript only grows wider if you opt for a language with a comparatively sophisticated and thorough static type system, e.g., C89.
Now, suppose the Javascript code has 100% test coverage, and the C89 code has 0%. But so what? I was assuming that already. In my experience, the C89 code is still easier to work with.
My assumption was/is that it refreshes stuff on a timer. On each timeout it puts a refresh event on some kind of queue... and then somehow manages to fuck it up, and ends up having a bunch of these events to deal with all at once, rather than handling each one as it comes in with a sensible gap between each one. Well, sometimes it happens, and don't ask me how I know.
But I have to say that you usually don't release it like that :(
Multi-way scrolling was common for BBC Micro games, as the hardware directly supported the barrel-type scrolling described in the article, though only on a full-screen basis. Uridium programmed the CRTC in a particular way, however, allowing the screen's base address to be set halfway down the screen, giving a stationary area at the top and a fixed area at the bottom.
I think the only other game of the period that did anything like this was Firetrack (https://www.youtube.com/watch?v=8bxdd2_qrpg), which used it to get smooth vertical scrolling.
The technique is easy to do (http://www.cpcwiki.eu/forum/programming/rupture/), but you do have to know the trick! It's know a well-known thing, and there's a couple of modern BBC Micro games that use it.
(Atari Falcon: https://en.wikipedia.org/wiki/Atari_Falcon - it's quite a lot better than the original ST, but still doesn't have sprites or multiple playfields)
The STe fixed both of these problems, and had variable wid5h rows and the pixel offset thing too. That meant a setup that was roughly equivalent to a 4-bit Amiga screen, though with interleaved bitplanes (which is not necessarily a bad thing).
(After a while you get attuned to the HN hive mind/group subconscious, and it's easy to tell which articles will induce this sort of thing.)
In case you were having difficult guessing, I'm minded to agree with tptacek. (And not just because of my sibling comment, in which I admit that my home network is indistinguishable from that of a 90 year old technophobe who got his not-daft-but-still-technically-ignorant grandson to set it up for him.) Is the interviewee's home network, assuming they even have one, really relevant?
If they're going to be setting up a network for you, wouldn't you rather they had experience doing something significant on a professional basis, not just setting something up at home?
If they're going to be doing something else, what relevance does any of this have?
EDIT: My precious internet points! ;) - wait, is this not a page of examples, as linked to from the GitHub page?