ProblemFactory

I don't think you can actually have the "unlimited downside" at least as a casual investor.

Nobody trusts you to be able to pay up for the "unlimited downside", so when you short stock, you are required to provide some collateral. For example USD or other stock held in your trading account. When the price of the stock you borrowed rises enough to match your collateral, you need to either provide more, or it gets used to buy the stock and repay the stock debt. You lose your entire collateral but don't get stuck with unlimited debt.

This limits the amount you can lose in total - but actually makes losing some amounts more likely. If you short a stock, but it goes up for a brief while before dropping - then you can still lose your investment at the peak even if you were correct in the long term.

    import envkey   # Fetches and install environment

In Python at least, that feels a bit icky. Modules can run complex code at import time, but it's rarely done.

The import order between modules is often not specified or carefully maintained, and web projects can have many main entry points. For example, a Django app might start from "wsgi.py" if run in a web server, from "manage.py" when running command-line utility scripts or tests, or from any other script file at all if a few setup lines are added.

People prefer to put all imports at the top of the file, but may want to do something right before or after envkey runs. Imports are not supposed to fail or throw exceptions, unless there is a serious code bug.

It would be nicer to have

    import envkey   # No important side-effects
    envkey.setup()  # Can be placed at the appropriate place

or similar.

> The missions targeted by this technology are GOCE-like spacecrafts which by design must fly low

Once the technology matures, it could be used by more missions. Flying low has its benefits:

* Lower latency for communication satellites,

* Better resolution for Earth imaging / spy satellites,

* When the satellite fails, it quickly deorbits by itself.

Until now, flying low has just not been economical, but if this thruster has similar lifetime to medium and high orbit satellites, then many more missions could choose lower orbits.

> True, in that it would better to fix the underlying problems that allow companies to pretend they have no profit.

This is the core problem, but it's also very difficult to solve.

Google makes money in Europe by selling advertising to European customers. It moves money out tax-free by claiming that much of its income is used to pay for the worldwide tech infrastructure and brand usage to its parent company.

But this is not entirely fictional. To run its business in EU, the local branches do need the infrastructure and Google brand, and paying for it is a valid business expense. The problem is calculating a realistic price for it. How much does Google UK benefit from the "dinosaur game" in Chrome, or how much should the Google Germany share of its development cost be?

Coming up with a fair and loophole-free formula seems impossible. It might be easier to just put a lower tax on revenue than a higher tax on profit.

> I live in the Netherlands where 40K is quite a reasonable income. I really dont get why you would need 100k to do the things you need. Perhaps people need to become a bit more frugal?

What I have found is that the majority of "happiness from money" comes from the financial security, not actually spending the money. The reduction in stress going from a chronically broke PhD student to having 5 years of living expenses in savings is huge.

It's the knowledge that you can immediately solve almost every problem that pops up with a bit of money, and figure out the details later. Missed your flight? Book another one. Car trouble? Call assistance and take an uber. Lost your job? Take a short vacation and then hit up your network on LinkedIn.

And in most countries in Europe, you can feel secure with a lot less in income/savings than in the US. You don't need to worry about what your health insurance does not cover, probably don't have any student loan debt - and probably don't need to worry about a college fund for kids, can commute by public transport in cities, have better unemployment protections, and so on.

It depends on how many spaces the cafe has and how expensive rent is.

If the cafe has plenty of free space, then people working on laptops is extra customers and beneficial. If it has little space, then a person ordering a coffee every two hours is taking away space from more profitable customers who eat, drink and leave in 30 minutes.

> For example, they think that they can scrape data about traffic from thousands or millions of connected cars.

It's not something Google/Waze could also do, it's what they already have been doing for years.

Google Maps has great traffic speed and accidents layer for all large cities in the world. And already uses it for routing, time estimates, and even calendar alerts like "leave early because of high traffic".

What makes this technology fundamentally different from and more dangerous than Adobe Photoshop?

I don't understand why Tether would be doing all that. They could have a very simple business model:

1. Accept USD and issue USDT in return,

2. Buy US Treasury bonds, which yield 1.5-2.5% for 3 month to 5 year bonds,

3. If people cash out their USDT later, Tether gets to keep the interest profit.

There is essentially zero risk: as they are buying USD bonds, they always keep their principal, and no exposure to currency fluctuations. And in the extremely unlikely case that the US Treasury would refuse to honor its debt, the world economy would be in such a crisis that nobody would even notice a small crypto exchange going under.

Do you think that Tether got greedy, invested its USD reserves in more risky assets (crypto or real world), lost money, and is now trying to cover up the shortfall?

> calculates that the return interval for a two-year drought of this severity is 1150 years (!)

This is however calculated based on historical weather data from 1920s onwards. With climate change ongoing and increasing, we can't rely on historical weather patterns staying accurate for future predictions. Old every 100 or 1000-year droughts can become every 10-year droughts.

> If you're in a creative industry - and I consider software a creative industry - giving away your creations for a wage is psychically harmful. If you're genuinely creating something of value, you want to own some fraction of its value - its revenue-generating value, its future cash flow.

If you work as a freelancer or partner in a small agency that does software development for non-technical clients, then keeping ownership and reselling your work is often possible. You can negotiate to sell the client a non-exclusive license.

But it's not realistically possible for an individual contributor at a medium to large tech company. There are too many people involved with each project or product, and no part of it is individually useful. You can't resell a git patch that fixes a bug in an existing codebase.

> how that ever got approved if the security model was clearly leaking

When you consider a theoretical model of the CPU, then it's not leaking - the speculative execution, cache, other parts of the CPU are designed carefully so that no data can "escape" and be read by processes that don't have the permission to do it. Speculated execution can happen, but before any results from that are released, the permissions are checked, and if they fail, the results are discarded.

What people did not consider is the timing attacks that do leak information. It's only "clear" to us now after the attack has been demonstrated, even if it has been present in CPU design for the last 20 years.

There are probably many more of these side channel data extraction paths possible. For example, in the recent years attacks on cryptographic algorithms have looked at similar timing measurements, and in some cases power consumption measurements.

> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM?

From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory).

Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised and make their results available. This is faster, and loading some memory into the cache is normally invisible to the unprivileged code. The checks would still be done when actually reading that memory. But nobody spent enough time considering the timing side-effects of the cache.

Now even if the protected memory reads are fixed by the OS updates - then it still leaves the Spectre attack - code running in a process reading all of "its own" memory, regardless of any software sandboxing. This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. And the OS patches can't help here, because the sandbox isn't in protected memory.

> There are so many laws on the books, many of them horribly outdated, and legislatures are overworked / grid locked. Often, the only way for us to have a working body of law that makes sense is for the government to simply stop enforcing the outdated ones.

Normalising this is a dangerous precedent. It leads to the situation where every citizen is technically a criminal according to the letter of the law, but it's not enforced as long as you don't stand out. But as soon as you annoy someone in government, they can choose to arrest and imprison you.

We don't know what the actual bug is yet, or how easy it would be to exploit it. People are speculating that either:

a) It would allow any non-root process to read full memory, including the kernel and other processes, or

b) It would allow one cloud VM to read full memory of other cloud VMs on the same physical machine, or

c) With enough cleverness, it would allow even sandboxed Javascript on a web page to read full memory of the computer that it is running on.

Yes, the algorithm is breakable with a few examples to figure out the base word and the pattern. But this requires human attention at your personal algorithm.

Unless you are enough of a celebrity or public figure to be personally targeted, nobody will bother. A password leak is going to have 100 million accounts in it, at least 50% of these reused without modification at other websites. Any automated bots and spammers will just try the exact passwords on other sites. If it doesn't work, they move on to the next account and password, instead of trying to guess modifications of non-working passwords.

You can't blindly overwrite existing data based on the UUID, sure.

But I find that the security checks against "stealing UUIDs" are much simpler to implement than a system of composite primary keys (deviceid+autoincrement or userid+autoincrement) or some sort of temporary primary keys. If you see suspicious UUIDs, you can just discard the data.

Having the client generate the "final" IDs for objects is particularly convenient when the client can produce a complex graph of objects offline, for example an order + order items + comments + more. If using temporary IDs until first contact with server, all these links would have to be patched up when the objects get real server-side-assigned IDs.

The Algorithm is a great solution - breaking the pattern would require password leaks from 3-4 different sites, and a human to spend time puzzling over it. For automated bots the passwords look unique.

What's your solution for annoying sites that require changing your password every 3-12 months, and not reusing previous passwords? If eHunterG8 becomes eHunterG9 and then eHunterG10, how do you remember the number you are up to?

UUIDs (and other mostly random IDs) also have the important advantage that they can be generated offline - in mobile apps, client-side javascript or elsewhere.

With autoincrement keys, you need to either contact the database server for each data object you create, or implement complex logic to replace temporary IDs with database IDs later.

Even if others don't discover and adopt your ideas - there is a limited market size for most investment strategies.

If you are good at picking winners for some specific type of startups, but there are only 10 of them per year, then you can't grow your fund from 10 to 100 investments per year and keep the same returns.

If you discover a clever arbitrage opportunity or market inefficiency, but there is only 1M of trades happening in that market, then you can't dump 100M into the strategy and keep the same returns.

Any discussion on ORMs needs to consider what sort of app and queries you are writing.

ORMs are fantastic for the very common case:

* Fetch 20 rows and display them as a table,

* Fetch 1 row by primary key and display it as a form,

* Write updated fields from the form back into the 1 row in the database.

Anything more complicated, and direct SQL starts being more attractive. But for the common case that ORMs are designed for, they are a major productivity boost.

> No idea how much extra it would cost

I thought the "European delivery" scheme's attraction was that it is cheaper than buying the same car in the US - because you are driving it around Europe, it's imported as an used car.

Yes, that's the argument in the article: that the RDA is far too low.

> I work in a large corporation and they're still planning their transition to 1.5 and then to 2.

Angular 1 -> 2 is an actual "major release". "Rewrite all your apps from scratch" major.

But starting from Angular 4, the "major version number changes" doesn't mean a major effort to update. There's a decent chance that 4 -> 5 -> 6 -> 7 etc will work without any code changes. But as long as there is a backwards-incompatible change, no matter how small and in how obscure submodule, it requires bumping the version number according to semver.

Most enterprise users will probably skip multiple versions between upgrades, just as they skip Ubuntu releases and Django releases and Rails releases and so on.

4 -> 5 included some new cool features but was a smooth upgrade. 6 is coming out in March and then a new "major version" is scheduled every 6 months.

This is common for end-user apps but feels very weird for developer libraries and frameworks.

We are used to X.Y.Z releases where X are "major rewrite", Y are significant updates, and Z are bugfixes.

That said, Angular's new scheme could be technically correct strict "semantic versioning". In semver X.Y.Z, Z releases are supposed to be bugfixes with no feature additions, Y releases add features but with perfect backwards compatibility, and X releases introduce breaking changes. A backwards incompatible change, no matter how small and easy to adjust for, should be a major version bump according to semver.

> I would guess WD is putting a user accessible CPU in each of their disk drives, idea being that if you have a CPU living close to the drive, then e.g. map+reduce workloads can be more efficiently executed.

I don't see how this would be better than our current systems architecture. Is the interconnect between the disk drive and the main CPU/memory really the bottleneck?

Even if the CPU lives inside the disk drive case, it would still be limited by the same read/write speeds as a CPU 20cm away.

> Helium-3 (He3) is gas that has the potential to be used as a fuel in future nuclear fusion power plants.

There is potential, but this is for very far in the future.

Getting an energy-positive fusion reaction going in ITER is still at minimum 20 years away - and it uses the simpler to fuse Deuterium+Tritium fuel. Getting commercial fusion power plants, and ones that fuse Helium-3 instead, might easily be 50-100 years away.

With the price of wind and solar energy dropping fast, people and politicians are getting less and less interested in funding fusion research at all.

My prediction is that nobody will be willing to pay for Helium-3 mining on the Moon in this century.

I have seen many of these companies and potential "build a real database-backed web app" projects during my software consulting career.

This seems like a good idea at first: automate manual processes, have a real database with one source of truth and consistency rules, multiple people can access it at the same time, etc. You can do it if the process is very well known and fixed.

But most of the time a web app would cause more hassle for the companies than having a team of people doing the work "by hand" in Excel would be.

* The process and desired data schema might change every few months - or even weekly when doing something like marketing reports. * Now they need regular maintenance - keeping servers up, doing and testing backups, applying security patches. * But the problem being solved is not big enough to justify hiring a full-time team of software developers to maintain it forever.

The author isn't arguing that any of the services or products are a bad idea.

She's arguing against the over-the-top marketing for something entirely ordinary. "We will revolutionise transport with this new invention" instead of "we started a bus route".

> Single PG node can handle easily

I think that's exactly what people are asking for. A single PG node (or even a shared node) managed and monitored by competent people for a "hobbyist" price. You start your project on that, and when you outgrow it, click a button to upgrade to the real Citus Cloud.

Now it's entirely possible that the customer support and separate infrastructure maintenance doesn't make sense for Citus at hobbyist price points - but it would be a way for them to capture potential customers before they standardise on RDS, Redshift and other database scaling options.