serhei

There are... multiple blog posts online now about how to use freely available data and modest amounts of compute to train a custom GPT-2-sized model from scratch. It would be quite a policing effort to prevent.

Clearly Apple's decision is based on paternalism, which most people don't appreciate when it's combined with government power. Compare:

"Clearly the ability to eliminate opposing viewpoints was a huge part of the Chinese government's decision, but was far from the only one. Stability and economic prosperity are also very important. My grandma can obey simple laws. But telling her to go to research contradictory political perspectives and decide the correct course of action is a completely different story. Not to mention how many people will just vote for the candidate that pushes their emotional buttons, and read whatever crap on Facebook and click next, next, next until they've elected Donald Trump."

It's still completely illogical to install an update just to wait for another update to fix the problems introduced by the first update.

Apple has had a planned-obsolescence approach for years and years [1], but with the way software used to be distributed and the consumer expectations on hardware design it was less of a problem before. If you want to keep using an old Mac, there are plenty of OS install disks, copies of old shareware floating around, sites like Low End Mac which document what works and what doesn't. The hardware was also usually more repairable. I'm worried that current Macs in the age of App Store OS updates and glued battery will be rendered into expensive paperweights that much more certainly when Apple withdraws support.

[1]: https://www.folklore.org/StoryView.py?story=Diagnostic_Port.... -- "[Steve] would also rather have them buy a new 512K Mac instead of them buying more RAM from a third-party."

You may laugh, but it seems scarily plausible to develop a machine algorithm that generates 12 articles, have a human go through to pick the 3 least-ridiculous ones and do some light editing, and push it out to the news.

Yes, that was a typo on my part. Lake Ontario lengthens any NY-Toronto train line. Lake Erie lengthens any NY-Detroit train line.

I'm not sure that makes sense as a single rail route. If Toronto and Detroit are intermediate stops on a line from NY to Chicago, that would mean the train either goes the long way around Lake Ontario (pointlessly adding travel time) or it goes to Toronto via Niagara and then doubles back west (pointlessly adding travel time for NY-Detroit-Chicago passengers).

Really, Lake Ontario makes any NY-Detroit train line much longer than it could be otherwise.

There could also be a desire to push partial-autonomy features in the short term, when Model 3 owners are making the decision day-by-day whether to drive the car completely manually or whether to rely on whatever level of Autopilot is available now or in 2 years. If driving the car without Autopilot is deliberately made to feel weird and akward, more people will turn on Autopilot in more situations.

Don't worry, those buildings can always be repurposed as condominiums. Unless the housing bubble implodes in which case Toronto has bigger problems.

I'm more concerned about whether the streetcar running on top of there will ever be more than just a sketch. An extension of the streetcar network in that direction has been proposed, canceled, procrastinated, debated for years but nothing actually happening so far.

The ability to buy something on Steam is sadly no longer a guarantee that it works.

Seems like Peter Thiel just has a policy to keep a finger in a lot of pies. Reminds me of the time Yarvin wrote a criticism of Sam Altman:

> Sam Altman (whom I don't know, but SF is a small town and I probably know someone who knows him) ... [1]

It's amusing that the missing link between them would be Peter Thiel.

([1]: If you really want to read the full post you can easily find it using Google.)

To paint a less rosy picture, many countries are good at keeping out US based tracking / social media monopolies because they want to support their own tracking / social media monopolies. It's kind of a "well, duh" moment that China is going to support its own Internet services rather than let that data be collected by people in the United States.

Russia has a similar government-backed Internet services ecosystem going on, although they dropped the ball on blogging and wound up having to do a complex operation to buy Livejournal (where all the Russians were) and move the servers to Russian territory.

Have a look at https://sandstorm.io/

> After a lot of lunacy including running around in the backyard and driveway looking for a spot of coverage, we finally settled on a system of handwritten IOU notes, and most people had to buy in twice and have an appointed stranger promise to send them BTC later. > > I would argue that there were few people savvier than our group when it came to Bitcoin, and we were having this experience? I realized I was maybe a little too immersed in the hype to see where Bitcoin was falling short in usability.

Ironically, this is not too different from how the financial industry solved the problem of having trouble moving large quantities of precious metals. Lots and lots of IOU notes. Eventually, the IOU notes were so ubiquitous that the underlying precious metals could be dispensed with entirely, and we got fiat.

The reasoning on this guy's website is often pretty fascinating: http://www.worlddreambank.org/P/PLANETS.HTM -- these are entire fantasy planets. For a warm-up exercise, he started out by tilting the Earth in different ways and working out how that would affect climate and biomes.

It's worth noting that conventional railways tend to sacrifice a bit of speed (relative to what you could engineer them for) in favour of being flexible in terms of how much passenger capacity can be provided, supporting a mixture of local/express services, and so forth. So the 'sweet spot' for a conventional or high-speed rail line between two locations may tend to be larger.

That's pretty similar to how languages like Scala with higher-order features translate down to the JVM bytecode (which is subject to certain restrictions).

The next boom will be in whatever _isn't_ being hyped right now.

I believe hype is actually Musk's primary product: by constantly coming up with these announcements he plays his part in maintaining the narrative of the US being the leader in tech innovation, over and above the narrative of the US being a formerly cutting-edge economy that is in the process of falling behind. (Which one is actually true is debatable, but managing perceptions is an important part of keeping the economy running.) Someone who merely organized solid electric car manufacturing or workable private space launches would probably not be as successful in attracting investment.

I certainly don't look forward to auditing a Solidity contract with the complexity of the federal tax code.

Imitating other code that is known to work [1]. Lots of testing. Fixing the bug when someone runs into it and complains (a viable last-resort for almost anything besides a Solidity contract).

[1]: For example, when working with filesystems, people write code that they saw other people using. The code may or may not work as designed depending on the specific filesystem. see e.g. https://danluu.com/file-consistency/

Thanks, I edited my comment to be more readable.

Heck, the basic methods of writing provably correct programs have been explained in plain English since at least the 70s:

https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...

https://www.amazon.com/Science-Programming-Monographs-Comput...

This is not some rocket science type verification with a dependently typed theorem prover language, it's fairly simple paper and pencil logic. It should not be hard to adapt it to Solidity specific concepts like running out of gas.

The reason these techniques are mostly ignored is that the techniques don't scale at all to large programs calling APIs with imprecise semantics (e.g. filesystem, network), and most people would rather publish imperfect software and iterate rather than spec everything up front. Well, unlike most software, contracts are not large, their semantics are meant to be 100% precise, and most people would rather take the time to make sure a contract does what it claims to do rather than discover a bug afterwards. I would hope.

It sure makes me wonder if Ethereum would do better with a less forgiving programming language. The fact that the syntax resembles Javascript is not reassuring, neither is the fact that the very first code snippet in "Solidity By Example" [1] is littered with comments like this:

        // Forward the delegation as long as
        // `to` also delegated.
        // In general, such loops are very dangerous,
        // because if they run too long, they might
        // need more gas than is available in a block.
        // In this case, the delegation will not be executed,
        // but in other situations, such loops might
        // cause a contract to get "stuck" completely.

[1]: https://solidity.readthedocs.io/en/develop/solidity-by-examp...

In general, the easier the code is to read and the harder it is to write, the better. (Force the programmer to think carefully, not the reader!) Anything that gets a comment like that in the Solidity examples should at the very least refuse to compile without the programmer adding some attention-grabbing _UNSAFE annotation. Better, there should be mechanisms to make sure the code is written in a way that everyone understands the consequences of e.g. running out of gas in the middle of a function.

Agreed.

The Swiss did study something similar (https://en.wikipedia.org/wiki/Swissmetro) but their proposal looks a lot more expensive and is entirely in-tunnel.

"200MPH is not high-speed."

Says who?

Originally anything over 125mph was "high-speed rail" simply because it required new engineering techniques to be developed (existing trains and tracks were physically not engineered to withstand those speeds). As the engineering was developed further, 125mph became old news and the 'typical' definition became more like 160mph [1].

[1]: https://en.wikipedia.org/wiki/High-speed_rail

If you compare to highway travel, even 100mph would be "high speed" because people aren't going to drive 100mph on the Interstate. If you compare to airplanes, nothing is high speed, not even maglev. No one is planning to build maglev with a cruising speed of 550mph.

Another important point is that high speed rail is still rail, whereas maglev requires a custom alignment. This could be important or it might not matter at all, depending on where you're building -- e.g. France's system relies heavily on the TGVs being able to use existing conventional tracks (to reach the centre of Paris, and to branch out into smaller cities that don't merit constructing a dedicated line), Japan's doesn't (because the conventional railways in Japan are narrow-gauge).

Likewise, California HSR plans to share most of the peninsula rail corridor with Caltrain. Theoretically it's a win-win (HSR doesn't have to tear a completely new alignment through a heavily-built-up area, Caltrain gets financial support for upgrading its corridor) -- you couldn't do that with a maglev. In practice, the project is not well-coordinated, but see what I said above about Brezhnevian stagnation.

All that said, a train that can travel on both maglev and conventional track would actually be an interesting next step for high speed rail. It doesn't seem impossible.

A typical third rail metro moves at around 25-30mph if you factor in station stops. Top speed varies, e.g. for Washington Metro the cars can accelerate up to 75mph but could plausibly be much slower depending on the track characteristics, how well sections of it are maintained, and how well the trains are scheduled. Hence it's unsurprising that Metro trains will get passed on a freeway unless there's a traffic jam.

Where Metro wins is on capacity. When the trains are full, one track of Metro carries an amount of people that would fill up 10 lanes of freeway. Of course, one major problem is that building mass transit is sold to the public as a way to 'reduce congestion' i.e. "other people will ride the subway so that my freeway will be clear". Due to induced demand from other people shifting their travel to the highway, this is not really truthful advertising.

It's more accurate to say that the mass transit provides an alternative for people who are fed up with traffic jams and want a more predictable way of getting downtown. Buses fail to provide that alternative, because unless the transit agency manages to get a dedicated bus lane along the whole route (it's probably not), they are going to be stuck in the same traffic that an ordinary car is stuck in.

Many of the existing freight rail corridors are twisty and not designed in a way that works for high-speed rail at all (unless you buy land anyways to straighten out the more extreme curves) [1]. They might work for conventional passenger rail if you could get the freight railroads to play nice and do better maintenance on the tracks.

[1]: typical example -- https://en.wikipedia.org/wiki/Horseshoe_Curve_(Pennsylvania)

[2]: For a detailed example of what's possible & what isn't with existing corridors, you can look at this independent engineer's study of how to upgrade a rail route through Northern California: http://zierke.com/shasta_route/

The dilemma is no different from "should I buy Product X now, or wait a year for version 2 of Product X", only on a national scale. Needless to say, if you play to this psychology successfully, you can delay a project indefinitely.