That's because pharmaceutical drugs have an inverse relationship between usefulness and cost.
It costs a penny to manufacture a pill, but $300 million to get it tested for safety and efficacy--and 90% of drugs that make it to clinical trials turn out to have intolerable side-effects, so patients won't use them, so they fail. $3Bn to find a good drug.
This happens because you can't tell what drugs do by looking at them. There's a chemical compound--n-methyl-alpha-methyl-beta-hydroxide-phenethylamine--which in its (1R,2S) configuration acts as a systemic adrenal stimulant. If you remove a single oxygen atom, it becomes n-methyl-alpha-methyl-phenethylamine. If the alpha-methyl group is leaned away from you (phenethylamine on the left, alpha-methyl on the bottom), it's a harmless nasal decongestant; if it's leaned toward you, it's d-Methamphetamine. If you bind a CO2 to the 3 and 4 positions on the phenethylamine ring, it's MDMA and will destroy your serotonin system.
Notice one of these was "harmless, does nothing in relatively-high doses" because a bond was tilted a little in one direction, versus "will totally fuck you up and cause brain damage and severe addiction if you regularly take 2-3x as much as necessary to stay awake for 30 goddamn hours" for leaning the bond in the other direction.
One compound we found will kill you immediately at micro-doses in a certain chirality.
We don't know what kind of long-term damage these drugs are doing, so we test on rats for 2-3 years, then on isolated human tissue, then at high doses in preclinical trials to check safety when we're pretty sure we won't seriously injure people. There's a 3-year follow-up after filing hundreds of thousands of pages of data with the FDA for approval: you have to get more data from the drug in use on actual patients.
So what if you made a new ADHD drug?
It's expensive...kind of. $20/pill is pricey. I actually think they should bank on re-standardization, e.g. $5/pill but try to get a bigger market--although people also hate pharmaceutical companies for pushing doctors and patients to move onto their new drugs. If it's safe and it works, you can try it as a front-line treatment to help disperse those R&D costs, right? Why not?
A lot of people have ADHD. ADHD drugs disperse cost extremely well.
What about a Hepatitis-C drug?
Yeah, few people have Hepatitis-C, and the drug cures it in 3 months. You're not going to sell very many pills in total, even selling to everyone. If you get a lot of market share up front, you're going to eradicate the disease and kill your market. That's going to be one hell of an expensive drug.
In this case, a government bail-out seems fine by me: you made a drug that can totally eradicate a disease, and it only cost $3 billion! You can sell it for $90k/pill or we can buy it from you outright.
...then you have the Shkrelis.
Several pharmaceuticals--Mylan's Epipens, Shkreli's toxoplasmosis pills, one generic drug that got marked up to $40k after being bought, and even athsma inhalers--get big numbers due to rent seeking. Pass a law requiring Epipens in schools and the price jumps up for no reason. "We're going to $1 billion, baby!" total profit seeking. Mismanage R&D into new applications for an old drug and jack up the price to recover. Inhalers and insulin injectors use old, cheap drugs in constantly-tweaked new delivery devices, artificially maintaining patents (devices are expensive to manufacture in small batches).
These people are unscrupulous con artists who prey on the lives of the weak and vulnerable. They need their toys taken away.
That would put load on your electric vehicle batteries, cycle them more frequently, and require earlier replacement. What's the cost of replacing a battery in an EV versus replacing it in a giant wall of batteries?
I don't mean transmission efficiency; I mean the efficiency of physically moving around, going to get things, storing them, transporting them, finding them, diagnosing them.
We handle transmission efficiency by using HVDC, stepping down locally to HVAC, and then transforming to 240VAC at point-of-use. Three-phase power helps, too.
Adiabatic CAES uses a different process than the last generation, whereby the energy lost in compression is retained and re-injected into the medium when driving a turbine.
Lithium batteries require lifting, moving, monitoring, building, disassembling, and chemical scrubbing to recycle or dispose. A lot more goes into the battery around its life cycle.
Grid-scale power is a utility service and not something you'd install at your house. Centralization of energy storage is economically more-efficient (i.e. in the end, people living with a giant building 10 miles away servicing a 10-mile radius are going to be able to buy more things per individual in total than people who have batteries strung out along the wire at intervals or install power storage at point-of-use). The arbitration of high-cost power against low-cost power doesn't apply because the energy supplier is operating the energy storage plant or contracting out to a third-party to do it for them.
Likewise, if everyone is pulling power into the battery at off-peak, and drawing it on-peak, they're putting load on the grid during off-peak. That will strain the grid, and the grid operators will raise the price of power during those times to discourage use. I have a single-rate plan because it would cost me 85% more in monthly electricity bills to use the dual-rate plan and only charge my electric vehicle off-peak than it does to use the single-rate plan.
Byzantine Generals can never actually be certain; they simply tolerate fault. You can't identify when M of N components are correct, but only when they are in agreement.
You can further improve on this by using provable, secure software (so the result of each phase is predictable and unlikely to be altered) and encryption where nobody possesses both encryption and decryption keys (since it's effectively impossible to stuff the ballot box).
You can never know that software is secure; you can only be reasonably-certain, and place controls around the attack surface. That's why I used an approach of publishing the software, publishing the image, demonstrating the imaging of the machines, making the media available (and observed continuously) throughout the voting day, not connecting the machines to any network, and generating a one-to-one proof of the output ballot set before moving the ballots: it's impossible to inject tampering code, ever retract any injected tampering code from public scrutiny and potential discovery, or alter the votes after poll close.
The rest is physical barrier. During election day, there have to be indicators to show what's happening--how many voters have voted, alarms if you enter the system, etc.--and logs taken to monitor the system (one-way serial with heavy error correction). You release logs immediately at poll close, and any physical tampering puts the polling center into an unusable state requiring total reinitialization of all voting machines. That means it takes too long to physically tamper with the machines and you need to modify logs to look legitimate and remove anomalies, which takes a long time.
Someone will walk in on you with your pants down.
A system where both the encryption and decryption keys are secret involves trusted third parties who can collude. Even my system is vulnerable to such collusion: election staff can create additional ballot cards and pass them out to people, just like with paper ballots. Every time a card is created, it's logged centrally (yeah, that machine's not casting or recording votes, so we can do this). The problem is reduced to vote-buying; the election staff can't know what votes are actually cast by the individual; and the individual can't vote repeatedly because any public observers will see the same person going to vote again and again and again, or being given a dozen ballot cards, or entering the ballot box booth and coming out after the count of voters who have cast ballots increases a dozen times.
Yes, I thought of that, too.
Nobody can tamper before or after election day. Nobody can tamper before polls open or after polls close. It's 100% detectable.
The effort to put out the hospital, if given constricted resources, will save more lives per unit of energy expended extinguishing building fires; thus you put out the hospital fire first due to the higher per-capita access to lifesaving emergency services in this triage strategy.
You do actually have to feed people. If you have 1,000,000 people to feed and the next town over has 1,000, the large town can reduce its per-capita CO2 output to meet that of the small town by letting 999,000 people starve to death. By contrast, if the town of 1,000 has 1/200 of the CO2 output of the large town, it can take up the technological processes of the larger town and reduce its CO2 output by 80%, whereas the large town is already at the forefront and will have more difficulty making a proportional decrease--and will only need to reduce its output by 0.4% to achieve the same total reduction.
You do understand twice as many people mean twice as much food and water necessary, right? Do you buy the same amount of dog food every month after getting a second dog?
It's not a matter of natural resources, but rather a matter of the scaling of production. If you continue to expand, you can make more food... until you've exhausted fertile land and good climate, and then you're pouring in more irrigation, more tillage, more fertilization, getting less yield, and investing more labor (cost) to produce less food.
This scaling happens with all sorts of resources. At a point, a method of production can't scale with more human labor performing the same tasks. Productivity decreases once you hit that carry capacity. There are also bottlenecks such as shipping (moving stuff requires a lot of coordination and physical trafficking space), as well as the inertia of capital investment (you don't build another billion-dollar fabrication campus for a two-year, hundred-million-dollar market spike).
A layman would perhaps expect that with doubling of all productive factors, the output will also double and with trebling of factors of production, production would also be trebled, and so on. But actually this is not so. In other words, when all inputs are increased in the same proportion, the total product may increase at an increasing rate, are a constant rate or diminishing rate. Accordingly the returns to scale could be ‘increasing, ‘constant’, or ‘decreasing’.
Early on, you have increasing returns to scale ("Economy of Scale"). In the middle, you have constant RTS. At the upper end, you have decreasing RTS. This is represented in introduction of new products, which we can see in cell phone technology, and is fairly generic.
Power is a simple example. If you run a motor at high output, it becomes less-efficient and consumes more fuel; you could build more motors, but single, large engines are more-efficient than several small engines. Eventually, you hit a feedstock problem: you need refined fuel to obtain maximum efficiency, yet fuel refinement also requires more resources, pumping raw fuel out of mines faster is difficult, and you wind up running burners hotter and losing more energy along the way.
This is all fine until you realize spreading out by building more power plants and more refineries raises complexity of some logistics geometrically, others exponentially, so you suddenly find yourself sitting on a superlinear factor: you can scale efficiently for a while, and then you need to find a way to more-efficiently generate power. Solar, wind, and geothermal energy don't require feedstock distribution, and so their much-lower logistics (to handle less-intensive maintenance) kicks you back down to the linear portion of the curve, restoring economies of scale.
You just need to figure out how to build those power sources efficiently.
This, of course, ignores basic economic policy issues like scaling minimum wage: if you scale it to inflation or otherwise less than productivity, you start creating poverty-stricken societies which can't purchase as much, and a demand bottleneck. If you scale it with productivity, you constrict job growth, although your economy stays healthy.
Population of Uganda grew 88.8% from 1980 to 2010; United States, 36.5%. GDP-per-Capita of Uganda grew by 600%, GDP 1,620%; United States, 384% and 523%. Uganda is gaining access to resources at a higher rate and has a higher rate of population gain; both have relatively-low unemployment.
Albania's population grew by 23% from 1980 to 1990. From 1990 to 2010, it fell 2.6% (low point 2000, at 6.6% drop from 1990). Unemployment rate rose from 12% in 1997 to over 18% in 2000; unemployment was 22% in 1993.
People emigrate from these countries or die. They don't have social services to feed their excess children or jobs for people to work and feed themselves; they can have all the babies they want, and if they can't feed them they'll starve. Whether or not there's food is immaterial: if there's food over there but those people are relatively-wealthy and have well-fed guards, you're not eating.
It's actually the opposite: population in total is constricted by resource availability, and the microeconomics of individual family growth do not resemble the macroeconomics of population growth.
Each time technology has ticked forward or wages have risen less than productivity, jobs have become more-plentiful. The workforce and the population have expanded in these events, until the abundance of jobs ceases. People point to impoverished nations with large families or to welfare families with poor family planning (too many children) while ignoring the overall population trend.
You can enable population control by constricting the labor force size: increase minimum wages to hold a percentage of per-person productivity; shorten working hours to reduce the amount produced per person and push the hourly wage up (so the yearly wage remains the same percentage of productivity). Do this slowly so you don't create unemployment, but rather slow the growth of the labor force by not creating as much new employment.
Absolutely true. You implement systems like this in an incremental manner, with parallel deployment so you can thoroughly test. Basically, you form the foundations first, then begin building components, and create adapters to connect your existing system to these new components where they replace parts of the old one; and you run this stuff side by side, duplicating all actions so you can compare results from both systems. Each time you've sufficiently demonstrated a subset of components, you replace production with the new stack.
It's not cheap, and it's not easy; it's something you do when the risk of maintaining legacy is getting too big.
Programs are connected sets of operations and projects to fulfill a common business need; each project is a finite, well-defined, planned, and temporary endeavor. No project should vary its scope unless some risk event makes the prior scope unusable; changes within scope are common and natural, and your project needs a change control board to determine if and how to make those changes.
Unscrupulous project management shops with little technical expertise will suck your business dry by proclaiming that "the customer is always right!" and doing whatever you ask. As a project manager, it is your job to discover what your client wants--not what they're asking for, but what they expect to achieve. If they want you to build something and it won't achieve their purposes, you push back. They can cut the contract or force things through their executive suites if they want, and it's your job to drive them that far if they're trying to make unnecessary and damaging scope changes that will harm their business and ultimately cause the project to fail by delivering something not appropriate or functional.
They call that "Agile"; that's not agile. Iterative and incremental delivery is agile: show each workable unit so the customer can test, analyze, and give feedback before you go basing the next piece on that. This increases customer interaction frequency and reduces risk by continuously validating that the project is developing as expected and actually fits the needs of the business and the product. Running around with no plan and no governance isn't agile; it's bullshit.
Of course I like to get shit done; a lot of people seem to just like money.
Oh, you can architect software that way; it just takes one hell of a lot of investment. It's not so much expensive as it is time-intensive and procedural. This is where you use project management to the fullest, you have a real QA team, you have disaster recovery and hot sites, and all that. Those things are all products of risk decisions, and the requirements here dictate a large investment in risk mitigation.
This is the kind of system for which you produce architectural documents first; you build test suites; and you ensure your organizational history is archived, indexed, and maintained by a dedicated department. It's not just about writing good code; it's about not flying by the seat of your pants on a system nobody understands with a bunch of very smart people who can tinker with it until it works and hope it doesn't break again.
COBOL hasn't lasted 50 years; it's an old legacy language that's running because people are still using it and paying huge money for it. MS-DOS still runs some POS systems.
You make a disjoint argument, as well: if something is so popular and powerful that it lasts 50 years, why would something else critically-important to large, super-rich clients simply fall out of maintenance?
Finally, C# is current, it's well-known, it's easily-maintained, it has modern OOP which allows extensibility and flexibility in your architecture to reduce long-term risks. In the future, C# will probably not be a language--or maybe it will. We then cycle this around again when it becomes clear we may end up stuck with an event nobody can resolve, with the global banking system in tatters, with nobody able to spend money, and our best countermeasure is trying to get people invested in a dead-end career doing nothing exciting.
Better question: why aren't they rewriting this stuff?
This is technical debt, a particular type of risk that piles up over time unless mitigated by taking other risks. Technical debt occurs when you solve a problem with a less-than-optimal solution to avoid a cost--whether that be time, money, or risk. Time isn't a factor here; rather, it's expense (small) and risk (large).
Banks pay quite a lot for maintenance of these systems, and can afford redevelopment. It's not that they're loaded with money, but rather that redevelopment isn't much more expensive (and is possibly short-term cheaper) than maintenance. Because time isn't a factor, a slow approach expending little cost per time--stretch the schedule to accommodate the available budget per quarter--would allow for redevelopment at about any cost constraint; and an agile delivery method integrating the old system onto a new baseline and delivering new components over time would allow better testing, earlier (partial) deployment, and risk mitigation.
Instead, they add new components, adapt to new regulatory needs, and write bits in Java and C and whatever. They cobble components together, integrate with other systems, and somehow get their complex and expensive code base to talk to another system written in Python to provide online banking. They keep dragging the whole thing on while adding more glue code and more core functions.
Somebody says it's not broken; everybody sort of shuffles around and tries not to mention that it might break if you sneeze too hard, and that it might not be easy to put it back together. If it's expensive to maintain and carrying the risk of minimal professional knowledge available in the field, it's broken: it's a huge risk waiting to bring immense monetary, regulatory, and reputational damage to your organization, and you're paying excessively to keep it around instead of trying to replace it.
and the net has probably a limited concept of the context.
That's actually what should fix this: if something anomalous happens, it should review context, identify if the context appears to be correct, and then cite that the thing is anomalous and extract it from its processing of context. That way you don't try to identify context as a whole; rather, you identify things that imply context and things which are inappropriate to those contexts, determine what seems to be most out-of-context, and question why there is an elephant in the room.
C# isn't proprietary. It's created by Microsoft as a published standard, along with CIL. C# types are base CIL types and so can interoperate with all CIL-targeting languages; and the current CLR (.NET Core 2.1) is MIT licensed. You would, of course, need a completely-new CLR for this, as this isn't exactly your standard middleware platform.
There's not a lot of bloat by adding a Kernel-CLR: it's a separate service, and basically a compiler. It's also a non-syntax compiler: a source compiler like GCC goes from C to a static single assignment tree, optimizes, and outputs x86-64 machine code; while a C# compiler goes from C# to SSA, optimize, output CIL. The CLR reads CIL into a SSA tree--no lexical analysis--and outputs x86-64 (or other) native machine code. Note that libopcodes on armhf is 128KB, and the linker is 496K, and the assembler is 517K: a non-optimizing CLR is likely under 1MB (the linker does a lot more stuff than a loader, and the assembler has to parse text). objdump is 306K, so maybe about 750K.
In a microkernel, the Kernel-CLR is a separate service. You can also separate out the garbage collector, the optimizer, and the profiler. That means you can precompile to optimized CIL and use the CLR to emit native code once; or you can load up an optimizer which further optimizes the code for the local platform, and even a profiler which re-optimizes the code as it runs.
The overhead of these things is also effectively zero: at Kernel-CLR level, you can do things like transactional garbage collection, wherein the garbage collector works with the virtual memory manager to map a shadow page table and replace the pages it's rewriting. VMM marks those pages being collected as read-only in the client service: if there's a write, that core immediately faults into VMM, which sends a message to GC that the page is dirty and then immediately faults back into the client. The whole thing would be a single-digit-thousands-of-cycle delay without cache flushing. If any pages are marked by GC as ready to go, then they're replaced in the shadow page table, and VMM changes the page table root to that new one upon such a fault (which is about a hundred cycles longer than a normal page fault entry and quick exit back to the program).
You can do the same with performance tuning and reoptimization: you shadow the page table for the client service, then switch the page table root when the service yields processor, thus replacing your executable code. All of these processes yield to anything that tries to run, staying out of the way.
At a point, when making enough changes and trying to integrate enough new technology, you're basically rewriting a kernel in place, trying to not step on too many things and create bugs along the way. Once you've crossed that threshold, you're creating more bugs working inside an existing, complex machine than you are by starting from scratch. If you're there, you may as well go all the way and consider a new language.
Well the Democratic party backed someone this year for County Executive who endorsed the Republican governor (also, he lost). They don't like progressive candidates and want centrists; we've been beating their candidates.
Our Democratic Comptroller is endorsing our Republican governor over the Bernie-Sanders-Endorsed Democratic nominee.
Look, I want the Senate, you want a Delegate seat, both are pretty close. We can trade a little. Besides, some of us have a lot of money and some of you don't.
I'm working on starting up a business with an Article in the Articles of Organization specifying that any funding raised through something like crowdfunding must necessarily be used for R&D of freely-distributed products--such as open source software. This creates a legal obligation.
The first software I want to produce is, of course, electronic voting machine software. I'm working on a non-repudiation model of elections integrity and an implementation thereof. Essentially, you prove that the voting system is not tampered at open, and the exact state of the system at open can be inspected at all points in the future: any tampering and any malicious behaviors are impossible to hide, ever.
When you close polls, the machines perform counting and produce an observable statistic which only computes from exactly one set of ballots, thus you can trace the released ballot sets back to the polling center and verify nothing has been added, removed, or modified in transit. In other words: there are no recounts--ever. "We keep ballots in a secure location, trust us!" "Well we've found Candidate B won, and had 100 more votes than we originally counted!" Right. Sure.
So that's cool.
My second interest is an L4+Minix microkernel written in C# by using a Kernel-CLR. Basically the loader pulls out a specialized CLR that has a section in CIL and another section in native: it's ahead-of-time compiled. It executes the native version, which is aware of the CIL segment and becomes self-hosting. System is stripped down basically to System.Collections and a few other things; there's a Kernel namespace; and an abstract factory of low-level operations is backed by concrete factories which implement those operations for the particular platform. The CLR turns a CIL kernel and CIL microkernel services into native code and manages them, allowing 100% of the code to be managed and platform-agnostic (the loader goes away after the kernel is up).
Of course, you need a Kernel-CLR targeting that specific platform. Every strip of executing code is native-compiled (instead of C++ becoming a static single assignment tree and then machine instruction language--as with LLVM or GCC compiling L4::Pistachio, okL4, or seL4--C# becomes SSA and then CIL, which becomes an SSA tree and then machine instruction language).
Garbage collectors at that level are interesting, too: you can do all kinds of fun things like shadow the pages involved in GC, detect when their contents are rewritten, fix up any necessary changes, and make your final pass by replacing the process's root page table entry with a new PTE. That means GC can use idle CPU only, and doesn't insert latency: it's possible to make a hard RTOS where OS components are subjected to garbage collection(!).
So what am I going to do with it?
Implement all the newest technology. Paravirtualization and separate OS domains; capabilities-based security; iptables backed by something similar to nf-HiPAC; advanced schedulers like BFQ and BFS; advanced threading like in Dragonfly BSD; self-recovery like Minix; the lot. The userland ABI will fully-implement Linux, so you can just dump a Linux distribution on top and it'll run.
That's what the crowdfunding clause in my AoO does: if people keep shoving money in my hands, I can't use it to develop closed products; I need to draw legitimate profit for that. I can funnel it to developing open source software, which means I can use it to chase a fancy like the above. It won't line my pockets, but it will let me change the world.
My legitimate profits, on the other hand, will let me kickstart my video game development studio.
Slashdot Mirror
A server is a computer sitting in a rack instead of on a desk.
That's because pharmaceutical drugs have an inverse relationship between usefulness and cost.
It costs a penny to manufacture a pill, but $300 million to get it tested for safety and efficacy--and 90% of drugs that make it to clinical trials turn out to have intolerable side-effects, so patients won't use them, so they fail. $3Bn to find a good drug.
This happens because you can't tell what drugs do by looking at them. There's a chemical compound--n-methyl-alpha-methyl-beta-hydroxide-phenethylamine--which in its (1R,2S) configuration acts as a systemic adrenal stimulant. If you remove a single oxygen atom, it becomes n-methyl-alpha-methyl-phenethylamine. If the alpha-methyl group is leaned away from you (phenethylamine on the left, alpha-methyl on the bottom), it's a harmless nasal decongestant; if it's leaned toward you, it's d-Methamphetamine. If you bind a CO2 to the 3 and 4 positions on the phenethylamine ring, it's MDMA and will destroy your serotonin system.
Notice one of these was "harmless, does nothing in relatively-high doses" because a bond was tilted a little in one direction, versus "will totally fuck you up and cause brain damage and severe addiction if you regularly take 2-3x as much as necessary to stay awake for 30 goddamn hours" for leaning the bond in the other direction.
One compound we found will kill you immediately at micro-doses in a certain chirality.
We don't know what kind of long-term damage these drugs are doing, so we test on rats for 2-3 years, then on isolated human tissue, then at high doses in preclinical trials to check safety when we're pretty sure we won't seriously injure people. There's a 3-year follow-up after filing hundreds of thousands of pages of data with the FDA for approval: you have to get more data from the drug in use on actual patients.
So what if you made a new ADHD drug?
It's expensive...kind of. $20/pill is pricey. I actually think they should bank on re-standardization, e.g. $5/pill but try to get a bigger market--although people also hate pharmaceutical companies for pushing doctors and patients to move onto their new drugs. If it's safe and it works, you can try it as a front-line treatment to help disperse those R&D costs, right? Why not?
A lot of people have ADHD. ADHD drugs disperse cost extremely well.
What about a Hepatitis-C drug?
Yeah, few people have Hepatitis-C, and the drug cures it in 3 months. You're not going to sell very many pills in total, even selling to everyone. If you get a lot of market share up front, you're going to eradicate the disease and kill your market. That's going to be one hell of an expensive drug.
In this case, a government bail-out seems fine by me: you made a drug that can totally eradicate a disease, and it only cost $3 billion! You can sell it for $90k/pill or we can buy it from you outright.
Several pharmaceuticals--Mylan's Epipens, Shkreli's toxoplasmosis pills, one generic drug that got marked up to $40k after being bought, and even athsma inhalers--get big numbers due to rent seeking. Pass a law requiring Epipens in schools and the price jumps up for no reason. "We're going to $1 billion, baby!" total profit seeking. Mismanage R&D into new applications for an old drug and jack up the price to recover. Inhalers and insulin injectors use old, cheap drugs in constantly-tweaked new delivery devices, artificially maintaining patents (devices are expensive to manufacture in small batches).
These people are unscrupulous con artists who prey on the lives of the weak and vulnerable. They need their toys taken away.
That would put load on your electric vehicle batteries, cycle them more frequently, and require earlier replacement. What's the cost of replacing a battery in an EV versus replacing it in a giant wall of batteries?
I don't mean transmission efficiency; I mean the efficiency of physically moving around, going to get things, storing them, transporting them, finding them, diagnosing them.
We handle transmission efficiency by using HVDC, stepping down locally to HVAC, and then transforming to 240VAC at point-of-use. Three-phase power helps, too.
Adiabatic CAES uses a different process than the last generation, whereby the energy lost in compression is retained and re-injected into the medium when driving a turbine.
Lithium batteries require lifting, moving, monitoring, building, disassembling, and chemical scrubbing to recycle or dispose. A lot more goes into the battery around its life cycle.
Grid-scale power is a utility service and not something you'd install at your house. Centralization of energy storage is economically more-efficient (i.e. in the end, people living with a giant building 10 miles away servicing a 10-mile radius are going to be able to buy more things per individual in total than people who have batteries strung out along the wire at intervals or install power storage at point-of-use). The arbitration of high-cost power against low-cost power doesn't apply because the energy supplier is operating the energy storage plant or contracting out to a third-party to do it for them.
Likewise, if everyone is pulling power into the battery at off-peak, and drawing it on-peak, they're putting load on the grid during off-peak. That will strain the grid, and the grid operators will raise the price of power during those times to discourage use. I have a single-rate plan because it would cost me 85% more in monthly electricity bills to use the dual-rate plan and only charge my electric vehicle off-peak than it does to use the single-rate plan.
At 50$ /kWh the whole world will run solar and wind. We can store two or three days electricity usage of the whole world at affordable prices.
Adiabatic CAES. Batteries are for portable things; compressed air is for grid.
Oh go jump in the river, Diogenes; you need a bath.
Byzantine Generals can never actually be certain; they simply tolerate fault. You can't identify when M of N components are correct, but only when they are in agreement.
You can further improve on this by using provable, secure software (so the result of each phase is predictable and unlikely to be altered) and encryption where nobody possesses both encryption and decryption keys (since it's effectively impossible to stuff the ballot box).
You can never know that software is secure; you can only be reasonably-certain, and place controls around the attack surface. That's why I used an approach of publishing the software, publishing the image, demonstrating the imaging of the machines, making the media available (and observed continuously) throughout the voting day, not connecting the machines to any network, and generating a one-to-one proof of the output ballot set before moving the ballots: it's impossible to inject tampering code, ever retract any injected tampering code from public scrutiny and potential discovery, or alter the votes after poll close.
The rest is physical barrier. During election day, there have to be indicators to show what's happening--how many voters have voted, alarms if you enter the system, etc.--and logs taken to monitor the system (one-way serial with heavy error correction). You release logs immediately at poll close, and any physical tampering puts the polling center into an unusable state requiring total reinitialization of all voting machines. That means it takes too long to physically tamper with the machines and you need to modify logs to look legitimate and remove anomalies, which takes a long time.
Someone will walk in on you with your pants down.
A system where both the encryption and decryption keys are secret involves trusted third parties who can collude. Even my system is vulnerable to such collusion: election staff can create additional ballot cards and pass them out to people, just like with paper ballots. Every time a card is created, it's logged centrally (yeah, that machine's not casting or recording votes, so we can do this). The problem is reduced to vote-buying; the election staff can't know what votes are actually cast by the individual; and the individual can't vote repeatedly because any public observers will see the same person going to vote again and again and again, or being given a dozen ballot cards, or entering the ballot box booth and coming out after the count of voters who have cast ballots increases a dozen times.
Yes, I thought of that, too.
Nobody can tamper before or after election day. Nobody can tamper before polls open or after polls close. It's 100% detectable.
The effort to put out the hospital, if given constricted resources, will save more lives per unit of energy expended extinguishing building fires; thus you put out the hospital fire first due to the higher per-capita access to lifesaving emergency services in this triage strategy.
You do actually have to feed people. If you have 1,000,000 people to feed and the next town over has 1,000, the large town can reduce its per-capita CO2 output to meet that of the small town by letting 999,000 people starve to death. By contrast, if the town of 1,000 has 1/200 of the CO2 output of the large town, it can take up the technological processes of the larger town and reduce its CO2 output by 80%, whereas the large town is already at the forefront and will have more difficulty making a proportional decrease--and will only need to reduce its output by 0.4% to achieve the same total reduction.
You do understand twice as many people mean twice as much food and water necessary, right? Do you buy the same amount of dog food every month after getting a second dog?
It's not a matter of natural resources, but rather a matter of the scaling of production. If you continue to expand, you can make more food... until you've exhausted fertile land and good climate, and then you're pouring in more irrigation, more tillage, more fertilization, getting less yield, and investing more labor (cost) to produce less food.
This scaling happens with all sorts of resources. At a point, a method of production can't scale with more human labor performing the same tasks. Productivity decreases once you hit that carry capacity. There are also bottlenecks such as shipping (moving stuff requires a lot of coordination and physical trafficking space), as well as the inertia of capital investment (you don't build another billion-dollar fabrication campus for a two-year, hundred-million-dollar market spike).
In educational terms:
A layman would perhaps expect that with doubling of all productive factors, the output will also double and with trebling of factors of production, production would also be trebled, and so on. But actually this is not so. In other words, when all inputs are increased in the same proportion, the total product may increase at an increasing rate, are a constant rate or diminishing rate. Accordingly the returns to scale could be ‘increasing, ‘constant’, or ‘decreasing’.
Early on, you have increasing returns to scale ("Economy of Scale"). In the middle, you have constant RTS. At the upper end, you have decreasing RTS. This is represented in introduction of new products, which we can see in cell phone technology, and is fairly generic.
Power is a simple example. If you run a motor at high output, it becomes less-efficient and consumes more fuel; you could build more motors, but single, large engines are more-efficient than several small engines. Eventually, you hit a feedstock problem: you need refined fuel to obtain maximum efficiency, yet fuel refinement also requires more resources, pumping raw fuel out of mines faster is difficult, and you wind up running burners hotter and losing more energy along the way.
This is all fine until you realize spreading out by building more power plants and more refineries raises complexity of some logistics geometrically, others exponentially, so you suddenly find yourself sitting on a superlinear factor: you can scale efficiently for a while, and then you need to find a way to more-efficiently generate power. Solar, wind, and geothermal energy don't require feedstock distribution, and so their much-lower logistics (to handle less-intensive maintenance) kicks you back down to the linear portion of the curve, restoring economies of scale.
You just need to figure out how to build those power sources efficiently.
This, of course, ignores basic economic policy issues like scaling minimum wage: if you scale it to inflation or otherwise less than productivity, you start creating poverty-stricken societies which can't purchase as much, and a demand bottleneck. If you scale it with productivity, you constrict job growth, although your economy stays healthy.
The United States gains around 1,000,000 legal immigrants per year since 2000, and currently has over 37,000,000 legal foreign-born immigrants.
You're confusing population and birth rate.
Population of Uganda grew 88.8% from 1980 to 2010; United States, 36.5%. GDP-per-Capita of Uganda grew by 600%, GDP 1,620%; United States, 384% and 523%. Uganda is gaining access to resources at a higher rate and has a higher rate of population gain; both have relatively-low unemployment.
Albania's population grew by 23% from 1980 to 1990. From 1990 to 2010, it fell 2.6% (low point 2000, at 6.6% drop from 1990). Unemployment rate rose from 12% in 1997 to over 18% in 2000; unemployment was 22% in 1993.
People emigrate from these countries or die. They don't have social services to feed their excess children or jobs for people to work and feed themselves; they can have all the babies they want, and if they can't feed them they'll starve. Whether or not there's food is immaterial: if there's food over there but those people are relatively-wealthy and have well-fed guards, you're not eating.
So the US produces 3x as much CO2 output per person than China?
It's actually the opposite: population in total is constricted by resource availability, and the microeconomics of individual family growth do not resemble the macroeconomics of population growth.
Each time technology has ticked forward or wages have risen less than productivity, jobs have become more-plentiful. The workforce and the population have expanded in these events, until the abundance of jobs ceases. People point to impoverished nations with large families or to welfare families with poor family planning (too many children) while ignoring the overall population trend.
You can enable population control by constricting the labor force size: increase minimum wages to hold a percentage of per-person productivity; shorten working hours to reduce the amount produced per person and push the hourly wage up (so the yearly wage remains the same percentage of productivity). Do this slowly so you don't create unemployment, but rather slow the growth of the labor force by not creating as much new employment.
Absolutely true. You implement systems like this in an incremental manner, with parallel deployment so you can thoroughly test. Basically, you form the foundations first, then begin building components, and create adapters to connect your existing system to these new components where they replace parts of the old one; and you run this stuff side by side, duplicating all actions so you can compare results from both systems. Each time you've sufficiently demonstrated a subset of components, you replace production with the new stack.
It's not cheap, and it's not easy; it's something you do when the risk of maintaining legacy is getting too big.
Programs are connected sets of operations and projects to fulfill a common business need; each project is a finite, well-defined, planned, and temporary endeavor. No project should vary its scope unless some risk event makes the prior scope unusable; changes within scope are common and natural, and your project needs a change control board to determine if and how to make those changes.
Unscrupulous project management shops with little technical expertise will suck your business dry by proclaiming that "the customer is always right!" and doing whatever you ask. As a project manager, it is your job to discover what your client wants--not what they're asking for, but what they expect to achieve. If they want you to build something and it won't achieve their purposes, you push back. They can cut the contract or force things through their executive suites if they want, and it's your job to drive them that far if they're trying to make unnecessary and damaging scope changes that will harm their business and ultimately cause the project to fail by delivering something not appropriate or functional.
They call that "Agile"; that's not agile. Iterative and incremental delivery is agile: show each workable unit so the customer can test, analyze, and give feedback before you go basing the next piece on that. This increases customer interaction frequency and reduces risk by continuously validating that the project is developing as expected and actually fits the needs of the business and the product. Running around with no plan and no governance isn't agile; it's bullshit.
Of course I like to get shit done; a lot of people seem to just like money.
Oh, you can architect software that way; it just takes one hell of a lot of investment. It's not so much expensive as it is time-intensive and procedural. This is where you use project management to the fullest, you have a real QA team, you have disaster recovery and hot sites, and all that. Those things are all products of risk decisions, and the requirements here dictate a large investment in risk mitigation.
This is the kind of system for which you produce architectural documents first; you build test suites; and you ensure your organizational history is archived, indexed, and maintained by a dedicated department. It's not just about writing good code; it's about not flying by the seat of your pants on a system nobody understands with a bunch of very smart people who can tinker with it until it works and hope it doesn't break again.
COBOL hasn't lasted 50 years; it's an old legacy language that's running because people are still using it and paying huge money for it. MS-DOS still runs some POS systems.
You make a disjoint argument, as well: if something is so popular and powerful that it lasts 50 years, why would something else critically-important to large, super-rich clients simply fall out of maintenance?
Finally, C# is current, it's well-known, it's easily-maintained, it has modern OOP which allows extensibility and flexibility in your architecture to reduce long-term risks. In the future, C# will probably not be a language--or maybe it will. We then cycle this around again when it becomes clear we may end up stuck with an event nobody can resolve, with the global banking system in tatters, with nobody able to spend money, and our best countermeasure is trying to get people invested in a dead-end career doing nothing exciting.
Better question: why aren't they rewriting this stuff?
This is technical debt, a particular type of risk that piles up over time unless mitigated by taking other risks. Technical debt occurs when you solve a problem with a less-than-optimal solution to avoid a cost--whether that be time, money, or risk. Time isn't a factor here; rather, it's expense (small) and risk (large).
Banks pay quite a lot for maintenance of these systems, and can afford redevelopment. It's not that they're loaded with money, but rather that redevelopment isn't much more expensive (and is possibly short-term cheaper) than maintenance. Because time isn't a factor, a slow approach expending little cost per time--stretch the schedule to accommodate the available budget per quarter--would allow for redevelopment at about any cost constraint; and an agile delivery method integrating the old system onto a new baseline and delivering new components over time would allow better testing, earlier (partial) deployment, and risk mitigation.
Instead, they add new components, adapt to new regulatory needs, and write bits in Java and C and whatever. They cobble components together, integrate with other systems, and somehow get their complex and expensive code base to talk to another system written in Python to provide online banking. They keep dragging the whole thing on while adding more glue code and more core functions.
Somebody says it's not broken; everybody sort of shuffles around and tries not to mention that it might break if you sneeze too hard, and that it might not be easy to put it back together. If it's expensive to maintain and carrying the risk of minimal professional knowledge available in the field, it's broken: it's a huge risk waiting to bring immense monetary, regulatory, and reputational damage to your organization, and you're paying excessively to keep it around instead of trying to replace it.
Well, yes. Also: Summer2018, Fall2018.
It's bad form to breach someone's network unannounced and then publish their internal passwords on your blog without informing them.
and the net has probably a limited concept of the context.
That's actually what should fix this: if something anomalous happens, it should review context, identify if the context appears to be correct, and then cite that the thing is anomalous and extract it from its processing of context. That way you don't try to identify context as a whole; rather, you identify things that imply context and things which are inappropriate to those contexts, determine what seems to be most out-of-context, and question why there is an elephant in the room.
That's artificial reasoning.
US Customs uses their own tape to mark things they've opened.
Byzantine methods? Explain.
C# isn't proprietary. It's created by Microsoft as a published standard, along with CIL. C# types are base CIL types and so can interoperate with all CIL-targeting languages; and the current CLR (.NET Core 2.1) is MIT licensed. You would, of course, need a completely-new CLR for this, as this isn't exactly your standard middleware platform.
There's not a lot of bloat by adding a Kernel-CLR: it's a separate service, and basically a compiler. It's also a non-syntax compiler: a source compiler like GCC goes from C to a static single assignment tree, optimizes, and outputs x86-64 machine code; while a C# compiler goes from C# to SSA, optimize, output CIL. The CLR reads CIL into a SSA tree--no lexical analysis--and outputs x86-64 (or other) native machine code. Note that libopcodes on armhf is 128KB, and the linker is 496K, and the assembler is 517K: a non-optimizing CLR is likely under 1MB (the linker does a lot more stuff than a loader, and the assembler has to parse text). objdump is 306K, so maybe about 750K.
In a microkernel, the Kernel-CLR is a separate service. You can also separate out the garbage collector, the optimizer, and the profiler. That means you can precompile to optimized CIL and use the CLR to emit native code once; or you can load up an optimizer which further optimizes the code for the local platform, and even a profiler which re-optimizes the code as it runs.
The overhead of these things is also effectively zero: at Kernel-CLR level, you can do things like transactional garbage collection, wherein the garbage collector works with the virtual memory manager to map a shadow page table and replace the pages it's rewriting. VMM marks those pages being collected as read-only in the client service: if there's a write, that core immediately faults into VMM, which sends a message to GC that the page is dirty and then immediately faults back into the client. The whole thing would be a single-digit-thousands-of-cycle delay without cache flushing. If any pages are marked by GC as ready to go, then they're replaced in the shadow page table, and VMM changes the page table root to that new one upon such a fault (which is about a hundred cycles longer than a normal page fault entry and quick exit back to the program).
You can do the same with performance tuning and reoptimization: you shadow the page table for the client service, then switch the page table root when the service yields processor, thus replacing your executable code. All of these processes yield to anything that tries to run, staying out of the way.
At a point, when making enough changes and trying to integrate enough new technology, you're basically rewriting a kernel in place, trying to not step on too many things and create bugs along the way. Once you've crossed that threshold, you're creating more bugs working inside an existing, complex machine than you are by starting from scratch. If you're there, you may as well go all the way and consider a new language.
Well the Democratic party backed someone this year for County Executive who endorsed the Republican governor (also, he lost). They don't like progressive candidates and want centrists; we've been beating their candidates.
Our Democratic Comptroller is endorsing our Republican governor over the Bernie-Sanders-Endorsed Democratic nominee.
Look, I want the Senate, you want a Delegate seat, both are pretty close. We can trade a little. Besides, some of us have a lot of money and some of you don't.
What is computer science?
I'm working on starting up a business with an Article in the Articles of Organization specifying that any funding raised through something like crowdfunding must necessarily be used for R&D of freely-distributed products--such as open source software. This creates a legal obligation.
The first software I want to produce is, of course, electronic voting machine software. I'm working on a non-repudiation model of elections integrity and an implementation thereof. Essentially, you prove that the voting system is not tampered at open, and the exact state of the system at open can be inspected at all points in the future: any tampering and any malicious behaviors are impossible to hide, ever.
When you close polls, the machines perform counting and produce an observable statistic which only computes from exactly one set of ballots, thus you can trace the released ballot sets back to the polling center and verify nothing has been added, removed, or modified in transit. In other words: there are no recounts--ever. "We keep ballots in a secure location, trust us!" "Well we've found Candidate B won, and had 100 more votes than we originally counted!" Right. Sure.
So that's cool.
My second interest is an L4+Minix microkernel written in C# by using a Kernel-CLR. Basically the loader pulls out a specialized CLR that has a section in CIL and another section in native: it's ahead-of-time compiled. It executes the native version, which is aware of the CIL segment and becomes self-hosting. System is stripped down basically to System.Collections and a few other things; there's a Kernel namespace; and an abstract factory of low-level operations is backed by concrete factories which implement those operations for the particular platform. The CLR turns a CIL kernel and CIL microkernel services into native code and manages them, allowing 100% of the code to be managed and platform-agnostic (the loader goes away after the kernel is up).
Of course, you need a Kernel-CLR targeting that specific platform. Every strip of executing code is native-compiled (instead of C++ becoming a static single assignment tree and then machine instruction language--as with LLVM or GCC compiling L4::Pistachio, okL4, or seL4--C# becomes SSA and then CIL, which becomes an SSA tree and then machine instruction language).
Garbage collectors at that level are interesting, too: you can do all kinds of fun things like shadow the pages involved in GC, detect when their contents are rewritten, fix up any necessary changes, and make your final pass by replacing the process's root page table entry with a new PTE. That means GC can use idle CPU only, and doesn't insert latency: it's possible to make a hard RTOS where OS components are subjected to garbage collection(!).
So what am I going to do with it?
Implement all the newest technology. Paravirtualization and separate OS domains; capabilities-based security; iptables backed by something similar to nf-HiPAC; advanced schedulers like BFQ and BFS; advanced threading like in Dragonfly BSD; self-recovery like Minix; the lot. The userland ABI will fully-implement Linux, so you can just dump a Linux distribution on top and it'll run.
That's what the crowdfunding clause in my AoO does: if people keep shoving money in my hands, I can't use it to develop closed products; I need to draw legitimate profit for that. I can funnel it to developing open source software, which means I can use it to chase a fancy like the above. It won't line my pockets, but it will let me change the world.
My legitimate profits, on the other hand, will let me kickstart my video game development studio.