You can do `zfs set copies=2` for a ZFS dataset if you think there's value in the extra copies. That's better than a copy of the file because with a single bad block, the checksum will fail and ZFS will retrieve the data from the good block and repair both files. In practice, using disk mirrors is better than setting the copies property.
My workplace has been using ZFS for years. I've yet to see an alternative come close to being compelling. We use OpenZFS on all our RHEL servers and even workstations with XFS for root partitions and smaller clients. Our primary file server is Solaris 11 but is coming to the end of its long life. The plan is to use FreeBSD on the replacement. ZFS has become so valuable to us that it alone can be a major factor in directing our other choices.
Is nice to see it advancing in useful ways. Hopefully this leads to offline dedup without the runtime memory costs.
Maybe salaries are crazy in Silicon Valley, but in Europe I really don't see this. I got a decent starting salary 25 years ago but having remained in a technical role I've never got more than minimal pay rises. I now earn way less than my contemporaries from University who went into other fields. And if I look around for job vacancies, they're never offering big money, certainly never close to 6 figures. Yet the perception in the wider public seems to be that CS professionals have loads of money even here.
Letters she sent were decoded at the time. The evidence leading to her being executed was largely based on that. It is a simple substitution cipher so vulnerable to letter frequency analysis. So the article title is either misunderstanding or click-bait. They do appear to have found previously lost letters which is very interesting. But deciphering them is easy.
Companies are always finding ways to justify lacks of pay rise. The company I was working for got acquired by a much bigger company with all these complex procedures in place and they intentionally allocated all the acquired employees much lower "career levels" so that they can justify no pay rises by pointing out that we're over-paid for our level. I've got 25-years of experience but am on the same level as new graduate hires. They also know that because I'm a foreigner and do have a family to worry about that I'm not going anywhere in a hurry. The industry is also quite badly ageist. Trying to even get a new job once in your mid-40s can be a challenge.
I assume the author is realigning to get only one bit for each letter. This relies on having an alphabet of 26 characters where 26 is less than the 32 available in a u32. In most real-world problems, you need to allow for the full ASCII or Unicode range and this wouldn't be possible.
Using codepoints directly, there is overlap. 'f' ^ 'd' will give you the same bit pattern as 'b'. You could keep an xor value for each window size smaller than the full window but that effectively brings back the inner loop that using xor is avoiding and you could just use equality. With codepoints, there may be a solution similar to a bloom filter so efficiently determine whether a duplicate is possible but I've not thought through that fully.
What this shows is that a lot of people don't use bookmarks but simply search for things every time. Google probably tries to nudge people in this direction because it is better for the ad business.
I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big.
Only rarely is the vertical alignment useful because mostly code isn't read vertically. Used in moderation, the reverse Christmas tree style used in the Linux kernel can be as good for readability (sorted longest to shortest). For some constant structures a reordering of fields to put the variable length element at the end of the line removes the need for padding space (like in the output of `ls -l` where filenames come last).
A common indentation style for continuation lines is to align with the start of arguments to the function. I've never seen the sense of this variable amount where indentation after a while is much more than after an if. Double the normal indentation for continuation works well in languages where line continuation isn't otherwise distinct from normal blocks.
> ... trying to line stuff up in columns like this in code is a mistake.
I've encountered this sentiment more than a few times and I find it hard to accept. It totally makes sense to align repetitive stuff in columns. That's why people use tables in other contexts, and code should be no different. This alignment makes clear any deviations from the norm and lets you "see" the structure of the data easily.
It doesn't matter for minor stuff and, usually, the code linter/formatter is "good enough"-- but sometimes, you REALLY want to have columnar layout!
The value of alignment (at least for me) is not in making the text of the code more readable. Instead, the value is communicating the structure of the code.
Seeing the same shape repeatedly tells me a lot about what is happening. It also helps highlight changes between two lines that are very similar.
> the value is communicating the structure of the code.
I agree and I think that is the same thing as code-readability. Code-readability means you can easily understand the code.
I personally try to abide by what I call "hedge" formatting convention, the punctuation forms a vertical hedge which then shows the structure of your code clearly:
[ a
, b
, c
]
Moving my eyes down to look for the closing bracket is easier (to me) than moving my eyes from left to right to spot it somewhere on the right side of the page.
Note how above ALL the punctuation is in the same (first) column, Having read that it then becomes easier to read what is on the rest of the columns.
In general it helps when things that are the same, or have the same purpose, on each line are in the same horizontal position. It is is then easier to see what is different about each line, since it is easy to see what is the same.
because, I think this is as 'uniform" as it gets. All syntactic separators are in the first column. Thus they are all uniformly in the same column. Line 1 has the syntactic separator '[' which means start-of-array. Lines 2 and 3 have ',' as the syntactic separator which means element-separator. And line 4 has the final syntactic marker which means "end of Array".
All elements of the array start at the same column, uniformly. And all syntactic separators are in the same column also uniformly.
What a stupid design. If the consortium had just one member having the competence of knowing some competing design and using his brain for five minutes, this disaster could have been avoided.
In circumstances, and depending on configuration, the code formatter tool may still aim for alignment, such as assignment operators on subsequent lines. Whether you like that or not, for me the question still stands: how does that jive with "almost monospaced".
Viewing the examples generally, the second one better communicates hierarchy at the cost of an extra line. The arguments are all grouped together visually and without distraction, while in the first example the first argument gets muddled with the function name. Why? To save a line break?
> the first example splits it across multiple lines in a way which maximally preserves the other aspects of the notation.
Once you’re splitting it across lines I don’t think that is a desirable attribute. Better to use a format that suits multiple lines than attempt to match as closely as possible to a format intended for one line. Like those “flying cars” that try to look like the “canonical” car.
From my perspective this is a UI problem (though not a serious one).
Why? The purpose of code is to be readable to humans.
At the same time I get your point and also the argument about Git diffs (which also should be readable). So maybe the ideal situation would be a separation of code and its formatting, so that we have more options than tabs and also no need for crutches like tabs. Like a better, more flexible code formatter that lets you display and edit code in the editor using one style but then saves the file in a standard format that's consistent across the whole project.
It should ignore "almost monospace". Most projects have multiple developers, you should assume different developers have different IDE/font preferences, so your formatting shouldn't try to cater for it.
I just put stuff on one line and let the editor wrap them. Doesn't waste vertical space, compatible with any font, any size, any window width, any form factor, the best from all worlds.
> I long ago concluded that trying to line stuff up in columns like this in code is a mistake. It often results in realignment of blocks for small changes so what should be a small diff in the git history ends up being big.
Seems wrongheaded to me; that's the same reason Elm wanted you to write arrays like this:
[item1
,item2
,item3
,item4
]
instead of a sane way. It means adding or removing an element only changes one line in the diff!
Who cares? It's not hard to understand what's happening in a diff that makes this kind of change. You want the code to be easy to read, not easy to diff.
You could also easily base your diff algorithm on a lexer for the language rather than a lexer for ascii, in which case changing the amount of whitespace would register as "not a change".
Example doesn't have a trailing comma. If it did, it would act the same as the leading comma.
But also the leading comma just moves the problem to the beginning of the list instead of the end. Trailing comma with the opening [ on its own line wouldn't have that problem anywhere.
This just seems like a limitation of the technology. When you change the width of one column, the whole table should realign, without any changes to those parts of the file (it's just about how it's displayed).
I recall reading something about "tab stops" that solved this problem, but I don't think there are any mainstream implementations of it.
> Never attempt to line up text by using spaces. The only exception is if you are using a monospaced font. But in word processing applications, there are appropriate tools available for lining up text, like tables[1] and tab stops[2].
tab stops is still available in terminals. Tab in terminal move the cursor to next x*8(depends on setting) position independent of what character you input before.
But a major flaw is that it only works when your cell has less than 8 characters. Or it will go to the wrong stop. Which isn't that common today.
Because why insist in short names and 80 width character limit? Almost everyone have a screen that can fit hundreds of characters per line today.
Even without the line length problem, 8 character is unlikely to fit in a meaningful word. And because you need a space between each column, you actually only have 7. And nobody using random abbreviations now.
Arguably another problem with lining up code like in the example is that it emphasizes the relationship between the keys and between the values rather than between each key-value pair. This may be useful when writing out matrices but in the example of an object/dict with key-value pairs it seems a distraction more than an affordance.
Many things are similar. What differences bother a particular user will vary. In many cases, zsh's approach is better so the value of crippling it is questionable. A common example is not splitting variables at spaces which is much better if you might have filenames with spaces in but it helps if you bother to learn to use arrays. Another example is the behaviour when wildcards don't match any files. Bash leaves the word unchanged with the wildcards in place which is less robust and fairly nasty but if you're inclined to be lazy can save on quoting.
So don't try to make zsh mimic bash, use it as-is and whenever something bothers you, try to understand both how the behaviour can be changed and consider the actual merit of the options.
Yeah need to look more into how to configure zsh, I'm accustomed to the way bash does things by default. Quickly of the top of my head are getting a pager with multiple columns of output when listing the files of dirs with many files and the readline behavior of deleting directories instead of whole paths when pressing M-backspace.
