Heh, establishing an "opsec failure guy" on the boat with software on his Garmin that can be activated on days with special secrecy demands to translate his runs to a plausible fake location? I like that idea. It would actually fit a one-off like the Charles de Gaulle quite nicely!
When it started I thought it was one third Zuckerberg just being the romantic geek wishing to making his childhood gaming dreams a reality (and their adolescence continuation: becoming the best virtual swordfighter by merit of having commissioned the algorithm), one third Zuckerberg having been so spoiled with luck that he involuntarily seeks ever more unlikely odds to finally experience failure and finally the last third shareholder representatives being rightfully sceptic pushing Zuckerberg into a control frenzy where he'd eventually do it just to show "them" that they have no power to stop him.
As in when your secondary memory is fast enough, after the first 10% of the model are processed you can swap their memory with the part for 50% to 60% and when that is done you swap back to have the 0-10% ready in time for the next iteration?
Sounds ambitious, for the small improvement in effective capacity. In particular when I start wondering if real life speed differences would be small enough for that 10% increase, or if it would be even smaller. And that's before factoring in power/cooling cost for saturating another interface.
The beauty is that often used parameters don't live (and die) in .bash_history. They live on the file system. Sure, the same can be achieved by wrapping in a script, but that needs both a name and content and they better stay in sync on changes or else....
> And good luck trying to run the same programs with different arguments
I don't read the idea as trying to replace arguments as in remove, "don't ever use arguments anymore", but as a DSL for _allowing_ to pull supported arguments into the filename. Basically an args list preprocessor. That would only take away your freedom of including triple-dashes in your file name without there being consequences.
You could just fix whatever is wrong with your bash history and/or learn to use the history properly. Bash also supports programmable completion so you could also use that than come up with some weird hack.
In Germany we have a term for entities headed by people who publicly say things Thiel and his gang say. It's verfassungsfeindliche Organisation. I really don't understand how they can still be considered government suppliers to purchase from. Just because they are on the stock exchange and not some secret conspiracy? (they are not on the stock exchange)
Right but if you read that page you quickly come to the quote "Parliament can make or unmake any law". Technically there is judicial review now, so there is some restrictions, but not like in a USA style constitution.
> Your DB isn't going any faster by switching to something else, if that's what you think.
Only true if none of the DB accesses are about stuff that could live as state across requests in a server that wasn't php. Sure, for some of that the DB's caching will be just as good, but for others, not at all.
In most cases you could add a shared cache to fix the problem - e.g. put your shared state in Redis, or in a file that is synced across servers (if its kept as state in a long running process it cannot need to be updated frequently).
These days my vote would go to a quad. Impeller fore, impeller aft and one in each wing. Behind doors, obviously, like the bays for retractable landing gear - this is a solved problem.
They don't have to be efficient, because how much hovering time would you really need? Battery could even exist only in mission specific pods (internal perhaps, when it's a cargo carrier), trade-off as needed.
Thats the point, the more efficient the less supply line you need, which means more autonomy.
I cant find the source but in Afghanistan a large proportion of the Allied casualties were from protecting supply lines.
The thing about quad copters is that they work at small scale because the rotor have almost no inertia. When you scale that up to 2m, then inertia is a bitch. That means you need tilting blades to make up for that lack of control.
BUT
You also need something to be powerful enough to alter the speed of the rotors to get yaw.
Plus you then also need to get them all to rotate so that you can get the efficiency of normal flight.
The reason why the osprey exists is because it has longer range than a helicopter (~1200 miles vs 400) its also faster.
> Plus you then also need to get them all to rotate so that you can get the efficiency of normal flight.
Not when you simply don't use them for horizontal flight. You just shut the VTOL hatches and forget that you aren't a conventional airplane until you want to land but there isn't an airstrip.
Winged operation has to be efficient, no doubt about that. But hovering does not need much endurance when it's only for getting away from the ground and setting down.
Electric has the power density, even more so when you don't need the power for a long time (heat buildup, no need for an equilibrium). Electric suffers from energy density, but that's where the winged mode comes in (old fashioned jet turbine, with the generator slightly larger than usual so that you'll have full batteries for the short landing hover)
If it slows down Rust development it's not pragmatic. And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble. Remember Scala?
>If it slows down Rust development it's not pragmatic.
I truly don't understand. If you don't want rust to become complex, you don't want it to "develop" fast anyways. Unless you mean you think it will be slower to write code?
> And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble.
Zero clue what this is supposed to mean. WTF is "full commitment" here?
> Remember Scala?
Scala, haskell, and others are high level languages in "academic terms." They have high levels of abstraction. The proposals are the opposite of high level abstractions, they instead formalize very important low level properties of code. If anything they decrease abstraction.
Rust is nowhere near the complexity of Scala wrt. seemingly arbitrary high-level features. There's a low-level, systems programming featureset that involves quite a bit of complexity but that's also less arbitrary when comparing across similarly low-level languages.
Counterpoint: if any language could thrive in that valley of despair between pragmatic and theoretical excellence you're referring to, it would be Rust. Because so much of the cost is already paid for once you have satisfied the borrow checker. At least that's what I'd imagine, I could certainly be wrong.
