I get that people can be flexible about understanding that `.` and `,` do not have a stable definition especially in an international world, but I would have thought that 50.000 EUR in context would clearly be 50 thousand. Who specifies cents with 3 digits?
I have seen it in many different places. At some I had to figure out what they really meant.
My bank is inconsistent, by the way. It uses "1234.00" where the last "00" is the cents. It was "1.234" in the same SMS. In another message (same bank) it uses "12,34". Weird. Although in the last case it might be because it is EUR, not HUF, but they are still very inconsistent.
I suppose you could argue many things? I would not naively expect Perl's versioning behavior, and a system package manager will have many users who are not Perl devs but who may nevertheless have Perl packages installed on their machines. "There is more than one way to do it" is fine for some things, but I also think it's desirable behavior for a system package manager to only require users to learn a single versioning scheme. In gentoo's case (and in most cases of system package managers I've seen), this happens to be dot-separated sequence of numbers, not floating point.
A system package manager also needs to be able to compare versions, and within gentoo's dot-separated versioning scheme 1.2 < 1.12. However, a perl package could have a dev sequence of 1.1, 1.12, 1.2. If these versions are entered naively into the gentoo packaging scheme, the intended order will not be preserved. So there must be some conversion in order to handle it correctly.
Well, for sure it's a mistake to naively expect _anything_ from Perl, of all languages!
I mean, even v-strings themselves ... despite being called version strings, they're different from `version` objects/declarations, and can be used in ways I expect most non-Perl devs might consider unexpected, for example if you run this:
It turns out[1] that v-strings are strings. So v102.111.111 is a three-character string containing codepoints decimal 102 (f), 111 (o), 111 (o), and v128513 is a one-character string containing codepoint decimal 128513 (U+1F601 GRINNING FACE WITH SMILING EYES).
... Yeah, I don’t know who thought this was a good idea either. I mean, I know versions sort lexicographically and strings do too, but no.
Bonus points:
> If there are two or more dots in the literal, the leading v may be omitted.
So 1 and 1.1 denote numbers, but 1.1.1 and 1.1.1.1 denote strings. I guess there’s a sort of syntactic pun to be had with IPv4 addresses. Still, no.
Bonus bonus points:
> Note that since Perl 5.8.1 the single-number v-strings (like v65) are not v-strings before the => operator (which is usually used to separate a hash key from a hash value); instead they are interpreted as literal strings ('v65').
So v1 always denotes a string, but which string it denotes is context-dependent.
That regular layout also makes it likely to feel better to the hand to play diminished or augmented chords, while comparatively punishing major/minor chords. It would be an odd choice considering the traditions of western music.
There's also something to be said about each key having a specific motor pattern/spatial layout. Sure, it makes it harder to move knowledge of one key into another, but during playing it also makes it easier to not accidentally completely change the key unless you mean to. It's all tradeoffs.
But really, I wouldn't worry about the result of this study _at all_ in daily life. It's quite surprising to me that this would be the top HN article at the time of this comment.
Second off, I didn't realize how deep the dep tree would be for this type of program -- 141 total! So much of it is the url crate, itself a dep of the git crate, but there's a bunch of others too. I'm just getting into learning Rust -- is this typical of Rust projects or perhaps typical of TUI projects in general?
(EDIT to strikeout) ~~The binary is also 53M as a result whereas /usr/sbin/tree is 80K on my machine -- not really a problem on today's storage, but very roughly 500-1000x different in size isn't nothing.~~
Maybe it's linking-related? I don't know how to check really.
(EDIT: many have pointed out that you can run `cargo build --release` with other options to get a much smaller binary. Thanks for teaching me!)
Stripping the binary further improves it to 2.9M, and some further optimizations get it to 2.2M without any compromise to performance. (You can get it smaller by optimizing for size, but I wouldn't recommend that unless you really do value size more than performance.)
Most shells dynamically link to a runtime your OS provides "for free". The 4.3 MiB binary in question is bundling the Rust runtime and its dependencies.
For reference, a statically-compiled C++ "Hello, World" is 2.2 MiB after stripping.
By switching to e.g. musl, you can go down to a single megabyte ;)
But in all seriousness, my example is quite cherrypicked, since nobody will actually statically link glibc. And even if they did, one can make use of link-time optimization to remove lots of patches of unused code. Note that this is the same strategy one would employ to debloat their Rust binaries. (Use LTO, don't aggressively inline code, etc.)
Just for fun, I wondered how small a canonical hello world program could be in macOS running an ARM processor. Below is based on what I found here[0] with minor command-line switch alterations to account for a newer OS version.
ARM64 assembly program (hw.s):
//
// Assembler program to print "Hello World!"
// to stdout.
//
// X0-X2 - parameters to linux function services
// X16 - linux function number
//
.global _start // Provide program starting address to linker
.align 2
// Setup the parameters to print hello world
// and then call Linux to do it.
_start: mov X0, #1 // 1 = StdOut
adr X1, helloworld // string to print
mov X2, #13 // length of our string
mov X16, #4 // MacOS write system call
svc 0 // Call linux to output the string
// Setup the parameters to exit the program
// and then call Linux to do it.
mov X0, #0 // Use 0 return code
mov X16, #1 // Service command code 1 terminates this program
svc 0 // Call MacOS to terminate the program
helloworld: .ascii "Hello World!\n"
Yes. The main areas where Rust code uses dynamic linking by default are Glibc and OpenSSL (through the popular `native-tls` crate). Most things outside of that will be statically linked by default. There is room to improve the situation by making more C wrapper libraries support either method.
For Rust code talking to Rust libraries (such as `std`), it's a totally different challenge, similar to what you face in C++. You can compile your pure Rust app in a way to divide it up into DLLs. The problem is that the polymorphism in Rust means these DLLs must all be built together. Calling a polymorphic function means code has to be generated for it. The only way around this is for your Rust library to speak the C ABI, which bloats code as building your C-style API surface will resolve all the polymorphized functions/structs, but at least gets you swappable dynamic linking.
The only way to avoid it is to be on linux with no_std, use musl statically or be on embedded. You cannot (or at least are supposed to not be able to) link to glibc statically and on every other OS you can only call syscalls via the system libraries. (Well, technically you can on most systems, it's just not stable across updates. OpenBSD will actively block it though)
Unless the majority of Rust builds on Linux statically link musl libc or use no_std, then it's pervasively true. And it's true on most non-Linux targets, including the BSDs and macOS. It's the same situation with Go.
The nix file is besides the point - it gives you a totally hermetic build environment. Not OP, but it’s the only way I know how to get gcc to use a static glibc. All you should pay attention to is that it’s using a static glibc.
$out is a magic variable in nix that means the output of the derivation - the directory that nix moves to its final destination
>> Not OP, but it’s the only way I know how to get gcc to use a static glibc.
> /tmp$ gcc -static -O3 test.c -o test
/tmp$ ldd test
not a dynamic executable
yes, that last line above means it's a statically linked executable.
yes, i had a doubt about what the GP said, about their nix way being the only way to create a statically linked executable.
but I didn't remember all the details, because it's been a while since I worked with C in depth (moved to Java, Ruby, Python, etc.)(though I did a lot of that earlier, even in pre-Linux years), so I didn't say anything else. thanks, Josh Triplett for clarifying.
but one thing I do remember, is that static linking was the only option in the beginning, at least on Unix, and dynamic linking came only some time later.
when I started working on UNIX and C, there was no dynamic linking at all, IIRC.
I thought glibc had some hacks in it to prevent it from working fully when statically linked? Is this just a myth or outdated or only affects C/C++ or what?
The issue is that some features of glibc want to dlopen additional libraries, most notably NSS. If you call `gethostbyname`, even a static glibc will try to dlopen NSS libraries based on /etc/nsswitch.conf, and if the dynamic NSS libraries are incompatible with your statically linked glibc, you'll have problems.
musl, by contrast, doesn't support NSS at all, only /etc/hosts and DNS servers listed in /etc/resolv.conf, so whether you statically or dynamically link musl, you just won't have any support for (for instance) mDNS, or dynamic users, or local containers, or various other bits of name resolution users may expect to Just Work.
and by the way, ignorant mindlessly downvoting dudes who don't even bother to check if a comment is right or not, can shove it up, and take a flying leap into Lake Titicaca. they'll meet a lot of their brothers there, like giant frogs.
from a Google search:
>Overview
Lake Titicaca, straddling the border between Peru and Bolivia in the Andes Mountains, is one of South America's largest lakes and the world’s highest navigable body of water. Said to be the birthplace of the Incas, it’s home to numerous ruins. Its waters are famously still and brightly reflective. Around it is Titicaca National Reserve, sheltering rare aquatic wildlife such as giant frogs.
For reference, some statically-linked shells on my system:
2288K /bin/bash-static (per manual, "too big and too slow")
1936K /bin/busybox-static (including tools not just the shell)
192K /usr/lib/klibc/bin/mksh
2456K zsh-static
For comparison, some dynamically-linked binaries (some old)
(The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)
Among the features it has: an interactive terminal GUI, threaded parallel directory walking, and git repository support. In around a thousand lines of code, total, including tests, half of which is the GUI.
I did some benchmarks on one of our CLI and found that `opt-level = "z"` reduced the size from 2.68M to 2.28M, and shaved 10% on the build time, worth a try.
I'll try with `panic = "abort"` for our next release, thanks for the reminder.
You are probably looking at a debug build. On Linux, a release build (cargo build -r) is ~4.3M, and down to ~3.5M once stripped. This could be reduced further with some tricks applied to the release build profile.
Is It though? You won't get it on an embedded device (maybe) but you could install a thousand of these tools and barely even notice the space being taken up on most machines
I think that’s a lame argument. First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space.
Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated.
I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data)
Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256
I’m usually the first to complain about bloat but your counterpoints to the GPs “lame arguments” are themselves, fallacies.
> First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space.
That’s exactly how most people think about file sizes.
When your disk is full, you don’t delete the smallest files first. You delete the biggest.
> Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated.
RAM sizes have actually stagnated over the last decade.
> I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256
That’s because media sizes increase, not executable sizes.
And people do want higher resolution cameras, higher definition videos, improved audio quality, etc. These are genuinely desirable features.
Couple that with improved internet bandwidth allowing for content providers to push higher bitrate media, however the need to still locally cache media.
200MB apps wouldn’t even make a dent on a 64GB device.
The 2GB apps are usually so large because they include high quality media assets. For example, Spotify will frequently consumer multiple GBs of storage but the vast majority of that is audio cache.
I’m intrigued, how many of them are actual 3rd party apps though? And how many are different layers around an existing app or part of Apple / Googles base OS? The latter, in fairness, consumes several GBs of storage too.
I’m not trying to dismiss your point here. Genuinely curious how you’ve accumulated so many app installs.
It's an interesting question. Some of them are definitely from the OS (either Google or Samsung).
Looking through at categories of app where I have multiple, I'm seeing:
- Transport provider apps (Airlines, Trains, Buses, Taxis etc)
- Parking payment apps
- Food delivery apps
- Hotel apps
- Payment apps
- Messaging / Video calling apps
- Banking apps
- Mapping apps
It's especially easy to accumulate a lot of apps if you travel through multiple countries, as for a lot of these apps you need different ones in different countries.
> No one thinks of software size primarily in the context of their disk space.
This is wrong. The reason why many old tools are so small was because you had far less space. If you have a 20tb harddrive you wouldn't care about whether ls took up 1kb or 2mb, on a 1gb harddrive it matters/ed much more.
Optimization takes time, I'm sure if OP wanted he could shrink the binary size by quite a lot but doing so has its costs and nowadays its rarely worth paying that since nobody even notices wether a program is 2kb or 2mb. It doesn't matter anymore in the age of 1TB bootdrives.
Try `cargo build --release --no-default-features` to get a much smaller binary (~5-10MB) - Rust statically links dependencies but supports conditional compilation for optional features.
Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior
> In an incident that is difficult to interpret as anything but rape, Pepys recounts entering the home of a ship’s carpenter—a man very much under his control, since Pepys was a naval official—and noting that, after a struggle, “finally I had my will of her.” His only recorded regret is “a mighty pain” in his finger, which he injured during the apparent assault.
> The victim, identified only as Mrs. Bagwell, had been instructed to offer herself to Pepys by her husband, who thought it would help his advancement. “The story,” notes Tomalin, “is a shameful one of a woman used by two bullies: her husband, hoping for promotion, and Pepys, who was to arrange it. Pepys did not present it in quite those terms, but it is clearly how it was.”
> Another obvious victim of Pepys’s sexual involvements beyond his household was his wife. In 1665, he had married fifteen-year-old Elizabeth St. Michel, the daughter of a French immigrant. Loveman describes the marriage as a “love match, albeit a tempestuous one.” The diary records the couple’s arguments over Pepys’s infidelities, and there were other tensions in the marriage. In an especially heated quarrel over Elizabeth’s management of the household, Pepys gave her a black eye.
> The full record of Pepys’s mistreatment of women is too extensive to detail here. That grim record could fill a book—and, in fact, it has. In The Dark Side of Samuel Pepys, author Geoffrey Pimm explores Pepys’s predations at length, drawing on the diarist’s own accounts of his misdeeds to build the case against him. Pepys, writes Pimm, “faithfully recorded acts of moral turpitude that in later centuries might have caused his name to be blazoned across the newspapers and in some instances, most probably lead him to be arraigned in the courts.”
That's a very strong statement. A less aggressive approach to discussion might involve asking for a concrete example of a problem rather than assuming bad faith argument.
Off the top of my head, and just spitballing, I would be more surprised if mature game devs or animation studios didn't want to version control pretty massive asset libraries.
> Off the top of my head, and just spitballing, I would be more surprised if mature game devs or animation studios didn't want to version control pretty massive asset libraries.
In general this author is comparing robust vim solutions with golf-style solution in Kakoune (i.e. assuming the example is the only thing in the buffer).
I'm not saying multi-select and Kakoune's predicate-then-verb (instead of vim's verb-then-predicate) aren't cool, it's just that he has very strawman comparisons because the vim solutions could often be phenomenally simplified if the same assumptions were made in the comparison.
OTOH, I learned some cool Vim features from those incantations that may be handy in a pinch someday.
The specific cherry-picked examples from GP make sense to me.
data + plural = datasets
data - plural = datum
If +/- plural can be taken to mean "make explicitly plural or singular", then this roughly works.
king - crown = ruler
Rearrange (because embeddings are just vector math), and you get "king = ruler + crown". Yes, a king is a ruler who has a crown.
king - princess = man
This isn't great, I'll grant, but there are many YA novels where someone becomes king (eventually) through marriage to a princess, or there is intrigue for the princess's hand for reasons of kingly succession, so "king = man + princess" roughly works.
king - queen = prince
queen - king = woman
I agree it's hard to make sense of "king - queen = prince". "A queen is a woman king" is often how queens are described to young children. In Chinese, it's actually the literal breakdown of 女王. I also agree there's a gender bias, but also literally everything about LLMs and various AI trained on large human-generated data encodes the bias of how we actually use language and thought patterns. It's one of the big concerns of those in the civil liberties space. Search "llm discrimination" or similar for more on this.
Playing around with age/time related gives a lot of interesting results:
adult + age = adulthood
child + age = female child
year + age = chronological age
time + year = day
child + old = today
adult - old = adult body
adult - age = powerhouse
adult - year = man
I think a lot of words are hard to distill into a single embedding. A word may embed a number of conceptually distinct definitions, but my (incomplete) understanding of embeddings is that they are not context-sensitive, right? So averaging those distinct definitions through 1 label is probably fraught with problems when trying to do meaningful vector math with them that context/attention are able to help with.
I get that people can be flexible about understanding that `.` and `,` do not have a stable definition especially in an international world, but I would have thought that 50.000 EUR in context would clearly be 50 thousand. Who specifies cents with 3 digits?