Here is a video produced by MillMILK, which is IMO one of the best Hong Kong YouTube channels. They documented how giant bamboo scaffoldings are built on the cliff. I have verified the auto translated Eng subtitles are pretty good.
https://youtu.be/ndf1QcBmQiM
The definition of value may includes many things beside money.
A nicely written review on Google Maps brings fulfillment to the writer, the subject (e.g. business) may find the review useful for improvement, other users may also make use of the review for their better plannings.
If you're against Google, or any other mega corps, consider contributing to Openstreetmap, WikiMedia Commons etc. I have a habit of uploading photos (restaurants, foods, shops, tourist attractions) to WikiMedia Commons, organise them in categories and then add them to Openstreetmap nodes as tags.
I found that my fdroid has not been updated to the latest release mentioned in this post (1.16). I opened it and pulled down to refresh, but it didn't show any available updates to fdroid. I opened the fdroid info page in the app, and at the bottom I saw 1.16.1 was available but 1.15.6 (the installed version at time) was labeled “suggested”, not sure what that meant. I selected 1.16.1 and it installed and ran smoothly anyway.
It's a common argument of computers getting powerful so we don't need to care that much for performance and/or efficiency regarding to cpu/memory/storage etc. In some limited cases the argument is valid but most of the time it's not.
First of all while maybe desktops and mobile phones are more powerful now, but we're getting more and more lower spec devices, like smart watches. Even when smart watches will be powerful enough one day, there will be eventually smaller computers, like smart contact lens, nano robots that run in blood vessels etc.
Secondly efficiency is still favourable for powerful computers. A small percentage of cost reduction can be big money save for large corps. A small percentage of energy save of all (or just a portion of) computers in the world can be a big win for the environment.
Lastly, we also run VMs and containers everywhere. Notice how we've already come up with all kind of ways to minimise VMs and containers size and footprint, in order to run more of them, to start them faster, and to transfer images quicker.
Yep. For hot call sites, these optimizations & inlining opportunities make a massive difference to performance. Static linking also allows for faster application startup time. (Though I don't have an intuition for exactly how slow dynamic linking is).
The only argument for dynamic linking being more efficient is that each dynamic library can be shared between all programs that use it. But not a net win in all cases. When you dynamically link a library, the entire library is loaded into RAM. When you static link, dead code elimination means that only the code you actually run in the library needs to be loaded.
But honestly, none of these arguments are strong. Dyld is fast enough on modern computers that we don't notice it. And RAM is cheap enough these days that sharing libraries between applications for efficiency feels a bit pointless.
The real arguments are these:
- Dynamic linking puts more power in the hands of the distribution (eg Debian) to change the library that a program depends on. This is used for security updates (eg OpenSSL) or for UI changes on Apple platforms. Dynamic linking is also faster than static linking, so compile times are faster for large programs.
- Static libraries put power in the hands of the application developer to control exactly how our software runs. VMs and Docker are essentially wildly complicated ways to force static linking, and the fact that they're so popular is evidence of how much this sort of control is important to software engineers. (And of course, statically linked binaries are usually simpler to deploy because static binaries make fewer assumptions about their runtime environment.)
> When you dynamically link a library, the entire library is loaded into RAM.
It doesn't. When you dynamic link a library, no part of it is loaded into RAM. It is page-faulted in, as it is used. In the end, only parts that were really used were loaded into RAM.
A page will be loaded in if any part of it is useful. Given that functions will be laid out more or less randomly throughout a shared library, and programs use a randomly scattered subset of the functions, I think its safe to say that you'll get a lot of bytes read in to ram that are never used.
Especially when we take the filesystem's read-ahead cache into account - which will optimistically load a lot of bytes near any executed function.
If your program makes use of some arbitrary 10% of the functions in a shared library, how much of the library will be read from disk? How much will end up in RAM? Its going to be much more than 10%. I'd guess that you'll end up with closer to 50% of the library loaded in memory, in one way or another. (Though I could be way off. I suspect most of the time the filesystem cache will end up loading the whole thing.)
If its 50% loaded, a shared library thats used once will waste 90% of its download size & disk space and 50% of its ram usage compared to the equivalent static library. And make the application slower to start because it needs to link at runtime. And make the program slower to run because of missed inlining opportunities.
> A page will be loaded in if any part of it is useful. Given that functions will be laid out more or less randomly throughout a shared library, and programs use a randomly scattered subset of the functions, I think its safe to say that you'll get a lot of bytes read in to ram that are never used.
Dynamic linking also allows for extensible applications that have to otherwise be implemented with slower OS IPC calls, and higher resource costs in process and CPU cores management.
Which also prevents good privilege separation/sandboxing. See PAM vs BSD Auth, where the former cannot be secured with anything like pledge/unveil or Capsicum, but the latter can.
So are you saying use Rust, more efficient at the expense of maybe using more memory? Or swift which may save some memory by being dynamically linked but perhaps is a little slower.
Honestly a ton of code is utility code, not run that often and nobody wants to take the time or expense to rewrite that Perl/python/bash script.
Some code efficiency is much more important than others.
> First of all while maybe desktops and mobile phones are more powerful now, but we're getting more and more lower spec devices, like smart watches. Even when smart watches will be powerful enough one day, there will be eventually smaller computers, like smart contact lens, nano robots that run in blood vessels etc.
My desktop/laptop distro dynamically link everything by default just so it can be slightly less work to port to a smartwatch? That sounds like a reasonable argument for having dynamically linking be possible, but it doesn't seem compelling for it being the default for the entire world.
What I'm more interested in is the comparison between the cases of Go and Dart, which both are languages developed by Google.
Why Go is so much more successful (in the system programming domain) than Dart (in the web/mobile/desktop domains)? Many of the listed good choices (e.g. being developer-focused) can be (had been?) applied to Dart as well.
I'm planning to write a blog post with my experience with those two (I'm using Go full-time for 8+ years and Dart for Flutter for more than 3 years). Those two languages are on the opposite extremes for me (minimalistic vs packed-with-almost-every-feature-known). I use Dart because Flutter is amazing, and Flutter and Dart teams are closely cooperate to my knowledge. I still struggle from time to time to navigate over 100500+ ways to initialize things, or rewriting seemingly innocent map/filter/foreach loops into "normal" readable `for (var i := ...` loops, and generally trying to apply lessons of readability from Go to Dart code as well.
Also, I did a thought experiment a couple of years ago on how Flutter would look like if it was built on top of Go [1] (it doesn't capture all the surface of Flutter, but that was my level of involvement with Flutter by that time).
Anyway, thanks for reminding about idea of writing blog post on those two.
First Chrome was placing it as JavaScript replacement, which made its adoption a failure from other browser vendors, similar to what happened with PNaCL.
After the project's dimissal, it got rescued by AdWords team that had just migrated away from GWT into Dart, and surely wasn't willing to drop it on the floor.
Then Flutter kind of gave it a new purpose, and by then most of the original designers had left as they were against the new direction of strong typing, and I guess how everything was managed to start with.
They have found a place in Fuschia, yet the Android team is also quite keen in making ART run on top of Fuchsia, and it is no surprise the Jetpack Compose is Flutter in Kotlin.
Because Google announced that they will add Dart VM to Chrome, and web community's reaction was "Hell no, we've just got rid of VBScript from the Web Platform, and we don't want vendor-specific languages".
Google changed course to using Dart-to-JS cross-compilation instead, but their initial implementation added 700KB+ of boilerplate at a time when people debated whether 100KB jQuery is too big.
I think the issue was, what was dart useful for that JavaScript or typescript didn't already solve? You had a new language that needed a separate VM to execute that offered basically nothing that typescript/JavaScript didn't already offer. There was no compelling reason for it to exist apart from "just because" - I think that had typescript taken off a few years earlier then they'd probably not have bothered with dart.
Go brought something new that answered an issue developers were facing: easy concurrency in a high performance garbage-collected language that compiled to a single binary with no dependencies. C/c++ did not offer that, nor did java, nor did python. Go filled the gap in the market.
Not to turn this into a language debate, but I think it's worth pointing out that Dart is a completely new language that has a more succinct syntax and more sensible semantics than JavaScript. TypeScript is different in that it intentionally is just JavaScript with type annotations. That makes TypeScript easy to adopt but it also means it inherits a lot of JavaScript's flaws.
For example, in TypeScript you still have nonsense like "this.method = this.method.bind(this)" while in Dart, method tear-offs just work. In Dart it's trivial to implement classes with value semantics that can be used as keys in a Map or Set, which is basically impossible in JavaScript. And so on.
I think most people would agree that Dart is just a much better language than JavaScript or even TypeScript. So the succcess of TypeScript is best understood as building on JavaScript's existing popularity.
> I think that had typescript taken off a few years earlier then they'd probably not have bothered with dart.
I always suspected that Google's investment in Dart was related to the Oracle lawsuit over the use of the Java API in Android. Remember that Dart is also the language behind Google's cross-platform app framework Flutter, which was developed while the Oracle case was still in court.
I suspect that Google wanted to ensure that for Flutter they used a language and API that Google unambiguously owned the rights to, to avoid another debacle.
(Then a better question might be: why didn't they just use Go for Flutter? The technical answer could be that Go is more of a systems language like C/C++ and less suitable for UI code. In truth it might just be a common case of Google starting multiple indepent projects that accomplish vaguely the same goals.)
Go focused on trying to solve for particular pain points within a certain class of applications. Those who had those pains were quick to jump on it to solve their problems.
Dart tried to build a better mousetrap. While you might say it succeeded, it wasn't enough to get people away from their older and less fancy, but working, mousetraps.
It's interesting how a map design can have an influence on social behaviour and city development.
> Beck’s design may have helped persuade city dwellers to make the leap to suburbs serviced by the Underground “by making them look closer to the center, and showing how easy it was to commute.”
Somewhat related, it reminded me some new residential buildings were intentionally incorrectly named with a hint of the nearby district. e.g. A building is located in district A, but was named as "B garden". It is because district B is an over-all better living area, so the flats can be priced higher.
