DougWebb

I became a Perl developer at the tail end of the 90's. I learned a lot of functional development and Lisp before I had any idea what they were.

I'll check out Google Workspace; that sounds like the right level of kludge for me, since this is the first time I've ever bothered to try to setup off-site backups. I only started using RAID a couple of years ago.

What's confusing is that the calculator has "Restore Requests" as the # of requests, "Data Retrievals" as TB/month, but there's also a "Data Transfer" section for the S3 calculator. If I add 1 restore request for 10TB of data (eg: restoring my full backup to the NAS), that adds about $26 for that month. Totally reasonable.

However, if "Data Transfer" is relevant, and I can't tell if it is or isn't, uploading my backup data is free but retrieving 10TB would cost $922! Is that right?

This is what has always deterred me from using AWS. It's so unclear what services and fees will apply to any given use case, and it seems like there's no way to know until Amazon decides that you've incurred them. At $10/month for storage and $26 if I need to restore, I can just set this up and I don't need to plan for disaster recovery expenses. But if it's going to cost me $922 to get my data back, I've got to figure out how to make sure my insurance is going to cover that. This isn't a no-brainer anymore. Also, what assurance do I have that the cost isn't going to be higher when I need the data, or that there won't be other fees tacked on that I've missed?

[1] https://calculator.aws/#/createCalculator/S3

Whatever these phenomena are, sharing all of the information that's available about them can only help us to understand them. If all of that information can be accounted for by physics we know, that's fine. At least we'll know for sure. And if it can't, then we need to work on learning some new physics, as we've been doing for centuries.

Yes, performance is an issue with that old approach. Around the turn of the century I was responsible for a Perl web application that ran as a CGI script, and to speed it up I wrote my own Perl httpd server that had my web application code pre-loaded. Then for each request I forked a new process, which carried over all of the pre-loaded code and already-running perl.exe, so there was very little startup time (compared to a normal CGI script startup.) I was careful to take full advantage of the operating system's Copy-on-write memory semantics, so that the only memory that had to be allocated for the new process was Perl's runtime stack. All of the memory containing the application code was shared across processes because it never got written to.

This web application is still running today, though I left the company in 2010. Back then, it was handling about six million requests per day, about 75% of which was during US daytime working hours. So, around 160 requests/second, spread across five or six servers that were getting old in 2010.

The modern frameworks have taken the same concept a step further, and replaced the process fork with a thread pool. That's faster, but it allows memory leaking in a way process forking does not. You have to go out of your way to share memory between processes, but with threads it's easy to do accidentally.

    node 1
      child of node 1
    node 2
      : (2)

A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune.

I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs.

I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.

No registration or configuration is needed, because the types are hard coded. If you need mocking support, a single IsTest config setting could be used in a conditional statement to determine which implementation to return.

That's very little additional coding if you use a ternary statement, and it lets you opt-in to the mocking mechanism if/when/where you need it, instead of permiating your entire architecture with it.

The method could return a MyService, or an IMyService if you want to be more flexible. It can always create a fresh object, manage and return a singleton object, or manage a pool of objects. For the new and pool cases, you can have another static method for 'returning' the object when the controller/page is done with it, so you can manage disposal or pool availability.

The biggest advantage I see to this approach is in debugging: there is a clear stack trace back to the source of the object, and also to its implementation if you're not using an interface. With DI you often can't tell where an object came from, and sometimes it takes some digging to even find out its exact type (unless you only have one implementation of each interface, which is often the case.)

Going from three meals a day to a 16:8 eating pattern (16 hrs fasting, 8 hrs eating window) isn't too bad. It's basically skipping breakfast. Shortening the eating window until you're eating one meal a day is tougher. Then extending the fasting period > 24 hrs is tougher still. You can't just jump into this stuff while you're carb-addicted and your body is screaming for glucose. Getting used to a keto-style diet, even if your carb intake is just low but not keto-low, helps a lot.

However, most of what I've read about prehistoric advanced civilizations discussed them using crystals (quartz) and deriving energy from the earth. Some form of piezoelectricity. There are theories today connecting earth quakes, quartz deposits, and ball lightning, which could be hinting at an energy source we haven't explored yet.

When I had to rename something, it was a manual process: one terminal opened to the command line, using grep to locate all of the instances I might want to rename. From there I could use sed or perl on the command line to do the renaming, or I could open individual files in vim. Once in vim, I could use a global search and replace command, or search for each instance and replace manually or with a macro or . command.

Slower than an IDE? Absolutely. But it never changed something I didn't intend to change, and the process taught me the value of good naming conventions. I never felt it was a hassle, and I became very good at refactoring without breaking things.

Today, I use Visual Studio to develop in C#, Javascript, and sometimes Typescript. The C# refactoring tools are great, and I've learned to trust them, though my naming convention habits are still useful when it comes to refactoring names in comments. Javascript, and to a large extent Typescript, generally require my old manual search and replace process. And whenever I do any refactoring, I always have a separate commit for it, which I carefully review to make sure the tools didn't do anything unexpected.

1. Employee buys their own plan from healthcare.gov.

2. Employee can choose to pay directly, using pre-tax dollars. Tax law is changed to that healthcare premiums are deducted from AGI for everyone who pays them.

3. Employee can choose to submit plan documentation to employer, who will pay some/all of the premium on the employee's behalf. In this case, employer gets the tax break. If only partially paid, employee pays the rest and gets to deduct that portion.

Financially, it's a wash either way. It gives the employee control over their health plan, and it changes the 'perk' status of employer-paid healthcare. It also gives time for employers to transition away from the "reduced salary + healthcare premium" model, because they'll be competing with employers who pay higher salary and no healthcare premium. Many employees will probably prefer the higher salary, because it's more flexible and feels better. That transition can occur over time without disadvantaging any employees, because the overall costs and tax implications are the same.

Today's drug startup company, which thinks it has a product that could be successfully developed, would write up a proposal to apply for FDA funding. If the FDA scientists decide the proposal has merit, they get funding. If the FDA thinks the company is nuts, the company can still self-fund and do the R&D on their own. Either way the normal testing phases are needed for final approval.

After that, if the FDA funded the R&D, it gets ownership and licenses out the manufacturing. The startup company can move on to work on something else, or having already been paid by the FDA to do the R&D, they can close up shop. If they self-funded the R&D, then they keep ownership and get to license the manufacturing, just like they do today. (Getting bought-out is just a transfer of manufacturing rights from the startup to the pharma, so that can still happen if the startup retains the rights.)

I'm imagining lots of startup companies developing nutritional-based vitamins and herbal products, getting paid to take them through the testing process, and then after approval the startup just moves on to another compound and/or disease. They could run as profitable little businesses for a long time doing this, and we'll get lots of non-patentable but fully tested products on the market that are cheap as dirt for the consumers. We can't get these products today because no one will pay for the testing process, so instead we have unregulated snake-oil products with little to no quality control and vague unverifiable claims about what they're good for.

Your second argument could be applied to every government program, which are attacked all the time, with the intent to get rid of them and eventually have no government programs at all. That's a separate problem that needs to be solved.

The total US spend for pharmaceuticals include tens, hundreds, or thousands of dollar-per-dose retail cost that patients are paying either out-of-pocket or through their insurance. Those high prices are justified by two things: the cost of R&D (both for the specific drug and to cover losses from drugs that don't make it to market) and advertising/marketing. My proposal nationalizes the R&D cost so it's spread out over both the full spectrum of drugs being developed instead of just one company's drugs, and over the full taxpaying population of the US rather than just over the patients purchasing the drug.

As for the advertising and marketing cost, there'd be much less incentive to push drugs as hard as they're pushed today, because there'd be no need for the manufacturing company to try to recoup the R&D cost. So long as their earnings are greater than the actual manufacturing cost and the FDA licensing fee, they're making a profit. And they'd have the whole FDA catalog to choose from when they're deciding which drugs they can manufacture and sell at a profit. I also think it would be reasonable for the FDA licensing terms to include a reasonable limit on margins and profits, so that costs for the patients are reasonable.

So, nothing has to be zeroed out. So long as this setup reduces the retail cost, it'll reduce costs for the insurance companies, and so premiums can drop. That puts more money into everyone's pockets, which will make any additional taxes needed for this scheme less painful (so long as the tax is less than the premium reduction.)

Corrupt behavior of government employees is already illegal, so if your concern is that they'd approve R&D funding for a drug and development company they have a financial stake in, that wouldn't be allowed and would be dealt with, unless they can prove that the drug really should be developed and the company getting the contract and funding really is the best choice.

Same goes for the manufacturing side, once the drug is approved.

And for the approval process, what perverse incentives would be created that don't already exist, and are already being dealt with? Today, anyone at the FDA who approves a drug that they've got some way to benefit from is already breaking the law.

If other agencies are a better fit for various parts of this plan, I'd do some reorganizing to bring them into a single organization. Maybe that's called FDA, maybe not. It would definitely be doing the FDA's current role in drug approval.

1. Pharmas separate drug R&D from manufacturing and sales.

2. R&D companies submit proposals to the FDA for new drugs they want to develop. The FDA can also send out RFPs for drugs they'd like to prioritize.

3. The FDA chooses drugs based on likely public benefit, rather than the profitability-driven selection we have today.

4. The FDA _funds the R&D_ for the drugs it chooses. This allows the R&D company to operate with positive cash flow, separately from the eventual (possible) future income from manufacturing and sales. This is also the incentive for developing drugs that aren't patentable, or which will be required only in small quantities.

5. When a drug is approved for release, the FDA will license one or more manufacturers to produce it, based on their quality, cost, and scale. This is why the Pharmas break into separate companies. Some may focus only on R&D, some may focus only on manufacturing. Some manufacturers can focus on large-scale high volume production, while others can focus on small-scale production. This prevents the excuse for charging huge prices for rarely-needed drugs "because the equipment needed would otherwise be producing much higher volume drugs at lower cost".

This arm of the FDA would be funded partly by the public, and partly by licensing fees. The math for insurance costs and premiums would change because retails prices for most drugs would drop. That would make insurance cheaper, and some of those savings would probably need to go towards a tax for the FDA's R&D funding. But longer term, the licensing fees might be adequate on their own since the FDA would operate as a non-profit.

This sort of filtering (which includes albumin replacement) is already available for humans. My ex-wife was hospitalized when her liver failed. Her blood was full of toxins, which overwhelmed her kidneys and eventually caused them to fail too. The toxins in the blood had a lot of bad effects, and would have killed her. While she was waiting for a liver donation, she had to undergo blood dialysis pretty much every day. She was hooked up to a machine that pumped her blood out, filtered it, replaced albumin (which was lost in the filter), and then pumped it back in. Each treatment took about two hours, and was really stressful and dangerous. Her blood pressure had to be carefully managed, and the machine couldn't keep her blood at the exactly correct temperature so it ached when going back in.

Bad as it was, it kept her blood clean enough for her to hang on until she got a transplant. She was on kidney dialysis for a year after that until she got a kidney transplant too.

This was incredibly expensive, because of the albumin. Also incredibly dangerous. You would not want to do this as an elective procedure.

Or, maybe better, glue on a stopwatch.

I do need a better way to view and report my data though, so what I've done is write a read-only reporting GUI that can parse my text file, give me daily/weekly/per-task/per-client reporting on my time tracking, per-day views of any journal entries, and a TODO list. It can even export the current week's entries in a format that pastes into my invoice spreadsheet template.

This is all managed in a per-year text file, 2020.txt, that's easy to back up and could be version controlled if I needed to do that.

If that's not done, then UBI would encourage migration from higher cost-of-living areas to lower cost-of-living areas. That might not be a terrible outcome; it would probably lead to balancing the cost-of-living across regions as the populations change.

Not average. It's Basic. It's just enough to get by. That's the incentive to work: most people want to do more than just get by. Anyone who doesn't want that would be a drag on any system, so that's a separate problem to deal with. But there are a lot of people who can't get ahead with the current system who would do better in a UBI system, and we'd all be better off if we could get those people productive and happy.