> One-Way-Door and Two-Way-Door Decisions
See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html
163 karma · joined February 21, 2011
meet.hn/city/45.6306954,-122.6744557/Vancouver
Interests:
AR/VR, Hardware, Mentorship, Open Source, Startups
---
See also the "Linux kernel management style" document that's been in the kernel since forever: https://docs.kernel.org/6.1/process/management-style.html
Computers can't represent 0.1 (in floating point), yet that hasn't stopped anyone from doing finances on their computer.
I don't think this is big news OR a parlor trick. It's just some obscure thing computers can't do that nobody has noticed for 70 years because nobody needed it.
True. But you ignore the fact that NO SOFTWARE IS EVER DONE. Software always has bugs, and even if it didn't, it will bitrot as the business needs change.
In theory, it's better to have 100% working software. In practice, that never happens (or only happens for a few weeks at best). Eventually the software needs to be changed. In that case, software that is "written for humans" will always be easier to change than "software that used to work, but now we need to change it, but nobody understands it".
Yes, otherwise your ISP will use it to serve ads.
Sure. But that is entirely based on their perception. If you asked "Should Microsoft be allowed to charge Dell a Windows license for every CPU, even Dell ships a different OS?", you will get a different answer.
The real problem is that any case takes 10+ years to litigate, so the landscape is completely changed, reducing the willpower of the public to enforce.
There is no such thing, because Nodes (and even entire datacenters) can fail.
In other words, node failure is an infrastructure problem that is best NOT handled by your bespoke application code. Replacing failed nodes should NOT be custom code in your app, that way lies madness.
> kind of looks like K8s wants to invent Erlang/OTP for infrastructure
You can say "K8s and Erlang implement similar ideas implemented at different levels." But you can't pretend one is a substitute for the other, nor that "Erlang has done everything that K8s can do."
E.g. Writing in Erlang doesn't magically get you:
- deploy/upgrade of the Erlang runtime, including rollback + multiple versions co-existing, including any compiled foreign code (which is required in the article). - ability to log, monitor, probe and reroute the connections between services -- In a standard way such that the application doesn't have to be modified.("service mesh") - Ability for an entire ecosystem of tools to inspect the versions of your application services that are deployed, because it's exposed as an API. - A standard ecosystem of plug-ins for operators (autoscale, autoscale to EC2 spot instances, capacity planning, "best practices" of running a MySQL cluster, etc.) None of these should ever be mixed with the application. (Unless you are Kelsey Hightower: https://github.com/kelseyhightower/hello-universe )
On the other hand, that is not the criteria for them to be successful, because they are already better on a different metric: Privacy.
I find that 90% of my queries are just "who is that person?" or "what is that thing?". Those queries can be answered by DDG just as well as Google. So I'm not giving up anything, but gaining privacy. More importantly, I'm (subtly) sending a signal to the market that I find privacy is important.
Even on the 10% of queries that are complex, DDG does "good enough". I sometimes wonder if Google has the results sorted better, but I'll gladly waste a few minutes here and there in exchange for privacy.
So it's not a security hole, but it is slightly less secure.
Everyone's use case is different, they are not experts at your application, you are.
Spend some time learning about the various services, do a deep-dive and maybe even a prototype on the ones that look interesting. There are literally dozens of ways to build any application, depending on what your goals are (low cost, low latency, low maintenance, etc)
> run it for a week
Run it for an hour, you should be able to quickly get a cost/benefit.
There are a ton of instance types, but you generally only need to test 2 or 3 families, and 2-3 sizes. (Do you need lots of RAM? CPU? Disk? FPGAs? GPUs?). It's worth the time to automate this, so you can periodically test it. (Yes, it will cost you a dollar or two.)
> But what if the service is more network latency sensitive
Don't forget your own part of the stack here. Writing in a scripting language can add miliseconds, as can normalizing your data (i.e. NoSQL usually prefers de-normalizing, which trades off more duplication for lower latency).
You can also pay (extra) for no hypervisor.
Ha ha, I feel the same. But don't discount the fact that small percentage returns are actually exponential growth. (For example, 2% returns actually doubles your money every 10 years.) Just because it 'feels' like your investments are stalled doesn't mean that they are.
- Billing: One bills you before shipping, the other bills at the end of the month.
- Cart: One lets you add items to a cart, the other lets you use products via API.
- Delivery: One requires warehouses all over the world, the other requires data centers all over the world. Only warehouses and data centers are so specialized that they aren't interchangeable.
- 3rd parties: One is a platform for creating online storefronts where 3rd parties can sell. The other is a platform that runs any code you want.
- One has a mass market audience of consumers, the other has a highly specialized market of developers.
Hmm, on second thought, maybe they are not the same business.
If you choose to pursue a company with clearly distopian hiring procedures, you are part of the problem.
I don't think all self-driving cars have the same sensors.
If you have LIDAR model X, and they were using LIDAR model Y, will your system "magically figure it out?
If your car has cameras at 5ft high, and the data is from a camera 6ft high?
Sure, someone could release the data, but will it screw up your models more than it fixes them?
(I totally agree the data should be released, I'm just not sure other self-driving cars will directly benefit. Certainly they can indirectly benefit from it.)
But that's good. The employees all made lots of money (and will be taxed on it, often at a higher rate than the corporation would have paid!)
So run the same scenario again, but this time say "stock options" instead of salary.
A patent should be about some process that is so complex that nobody else has figured how to do it before (i.e. some secret trick). When it's published, humanity is better off by publishing it now (even if it's locked up for a little while) so people can investigate related solutions (some of which might not infringe).
But the patent office is allowing patents on obvious things, so the public gets no value in their publication. (Actually negative value, since people have to waste time reading them and companies are afraid to develop products).
The goal of the patent system is not to "pay innovators" - they already get paid by putting good products on the market.
The goal of the patent system is to get innovators to PUBLISH their solutions so that the public can benefit from them. (And build on them in the future.)
If the patent is obvious, then the public gets no benefit, and we're handing out monopolies for free.
But what happens when you have billions of scripts, each executed infrequently? You need some way of fetching the scripts dynamically (they are changing constantly), and way to time-multiplex their execution so you don't waste RAM on inactive scripts. Oh, and load-balancing suddenly becomes non-trivial because you prefer to route to one script spun up on one box (as long as the usage doesn't justify multiple boxes), instead of accidentally spinning up that script on every box.
What's new is the layer that is managing fetching, starting, and stopping the scripts. For developers, it's 'kinda the same'. But for operators, it's a massive change in how things work that enables a different paradigm.
I think you left out "and a lot of money is involved". Do you think there would have been an emergency hard fork if the DAO only had $100 in it? I sincerely doubt it.
> existing enforcement mechanisms will impose themselves as trying to define what moral is.
Morality and Law (code or not) are different things. You can't code morality - you can only encode the programmer's morality. (Which is not the same thing, because the programmer can change his/her mind.)
https://splinternews.com/how-an-internet-mapping-glitch-turn...
That is a terrible example. Comcast would be out of business if their customers had something to switch to. But they are a monopoly (or at best a duopoly) in most of their markets.
No, you don't need to retrieve your keys each year. Before storage, create N transactions moving all your coins to the next derived address. Sign all your transactions at once. Then put it in the safe.
Store the transactions unencrypted on your computer. Send one each year. An attacker can't do anything with them except send them early (and force you to open your safe "sometime within the next year".)
In a unikernel, the kernel is part of the application (like a library). Instead of a complex/slow transition from user space to kernel space, you just call a function.
A unikernel will also know exactly what your application needs (i.e. if you only use UDP, it doesn't bother including TCP.) It's possible to strip down the Linux kernel, but it requires a LOT of work (basically, remove something, then test that your application still works.)
Normally, that code will just error out right away.
But if you add a new branch before the code (such that the branch is taken to avoid the code, but the CPU predicts the branch to NOT be taken), the CPU will speculatively execute the above code just past your branch. The speculative execution doesn't check for memory violations (because that takes time).
Normally, that's cool: if the new branch IS taken, there is no harm because the the result of the (bad) kernel access will be thrown away. If the new branch IS NOT taken, the CPU notices the bad access and complains.
But if you are extra devious, you can ensure that page X is NOT cached when running this code. After, you check if page X suddenly got cached. That tells you the value of the high-bit of your kernel memory. Keep scanning all the bits and you can read out all of kernel memory.
This article sums up how to get a mentor:
https://pindancing.blogspot.com/2010/12/answer-to-will-you-m...
No such option exists anymore.
Sure, they have a Reduced Redundancy "feature". But you would be stupid to use it because RR costs more than the regular redundancy, not less. (One big hint is that it's not even listed on their regular pricing page anymore.)
That is how Amazon phases out features: Instead of raising the price, they just don't lower it. Over time, it becomes more expensive because all the other prices are going down.