A very abrupt ending to what could have been a very educative text aimed at people who want to know 'what to choose', how to reason, and where we are currently at. I'd love to read more.
What a magnificent writeup. Much thanks, very useful, I always got a bit stuck on knowing about string types, their pitfalls and which to end up choosing, so I'm very happy with this useful document!
Good article, but visually representing data differently from how it's stored in the database can be a huge PITA. A pet peeve of mine is real names as an example, Dutch family names may have an infix (van, van der, den, van den) which is always in lowercase, and usually is not even an option on non-Dutch websites. You can't leave how to display these things up to the designer: the user has to know (imho) how these are stored. For example, sorting on last name should not happen on the infix, but only by lastname. E.g., "Dijk, van" comes before "Meulen, van der".
For completeness sake, the full names here may be "Bert van Dijk" and "Anne Jan van der Meulen". Also, "Anne Jan" is a single first name, despite the space.
That reminds me of my own pet peeve regarding anglocentric UI assumptions. Spanish naming customs are 'Given_name First_surname Second_surname' [0], such as for example Spanish director Pedro Almodóvar Caballero, whose name would be shortened for convenience by dropping the second surname — Pedro Almodóvar. The problem is too many US/Aus/UK developed UIs assume the whole world follows English naming customs, and thus would insist on showing his initials as 'PC' or shortening his full name as 'Pedro A. Caballero'. For reference, that feels as wrong as it would be to an American for a website (assuming Spanish customs) to initialise the director of E.T. and Jurassic Park as 'SA' or display his full name as 'Steven Allan'.
[0] Spanish given names may often be two-words-long (e.g. 'José Manuel') and a surname may less frequently be more than one word (e.g. 'de la Fuente'), but this isn't a necessary detail for my base rant above.
And the inverse is also somewhat common- forms which require both a maternal and paternal surname, and won’t let you continue with just a single surname.
In José Manuel, Manuel would be the middle name, just like in English. It's not a "two-words-long first name". Sometimes first and middle names are coupled like a whole, like it's usual for José Manuel. Also for José-something or Juan-something in general. Other times, the middle name is never used, like in Nicolás Antonio, being the Antonio part extra annoying, because the SS personnel, for some reason, insists in calling me that when it's my turn.
Wait, what? We don't have middle names, we have "nombres compuestos". Sometimes you may drop part of the name, sometimes not, but you will never see a form with a field for the middle name like you see in English speaking countries.
So different ways of calling the same thing and different UIs. But it's just given names vs. family names and a set of rules. I like Bulgarian ones most.
Exactly. Especially in something like customer service where they're often helping fix and issue. If they don't know the name is incorrect then they will have a lot harder time figuring out why a downstream system is sending the wrong mail to the customer.
In their example, the change is also much harder to read for me. It takes up just as much space but logical categorical groupings are no longer visible at a glance. Previously you could see all the people from the same zip code, city or state. Now you can't because they're all mixed together at different horizontal offsets. You could also pull out the different information at a glance by using the horizontal offset which you now can't.
I’ve been in this boat and then had to justify the choice when integrating with third party vendors whose backends absolutely want names split into first/last components.
We would set up integrations sending the full name in the “first name field” and then a hard coded “notmylastname” string in the “last name field”. And then have about 3 days of back and forth usually including a link to https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... and explaining that no, you can’t reliably use a regular expression to split the full name data into first/last components.
It argues the topic pretty well: xz is unsuitable for long-term archival. The arguments are in-depth and well worded. Do you have any argument to the contrary beyond "sour grapes"?
I can understand wanting your project to succeed, it's pretty natural and human, but it's flagrant Antonio had a lot of feels about the uptake of xz compared to lzip, as both are container formats around raw lzma data streams and lzip predates xz by 6 months. His complaint article about xz is literally one of the "Introductory links" of lzip.
Neither is lzip since it doesn't contain error correction codes. You can add those with an additional file (to any archive) e.g. via par2 but then most of the points in the linked rant become irrelevant.
Neat! Very handy for looking up issues remotely. It has a dependency on firefox, but on systems that have Nix, that shouldn't be too much of a problem.
Just as a word of warning (because I can't tell if this is satire): NixOS does not provide the same experience as a typical Red Hat or Debian-derived distro. It's a vastly different paradigm where your system (including its configuration, packages, etc.) consists (almost) entirely of the output of a program you write in a functional language.
I think it's phenomenal and worth a try (or multiple; I didn't get it the first or second time but now I wouldn't want to go back to something else). But if you go in expecting a traditional Linux distro, you will be disappointed/confused.
Terry Davis was clearly the mad scientist we didn't know we needed. He brought many useful insights to OS development. Maybe one day the seeds he planted will grow out to become a wonderful tree. On days when he wasn't hampered by his medical issues some people remember him to be an extremely skilled teacher, patient with people who asked genuine questions. There was that side to him too.
