In Japan they have the abbreviation “NG” (“not good”) that’s often used as the opposite of “OK”. I always liked how, when I worked for a Japanese machine learning company, classifiers would be between “OK” and “NG”. Maybe semantically “okay” and “not good” are not great opposites, but I always liked how having textual alignment makes the contrast immediately obvious
It's not unusual in France to use OK and KO. I never liked it much because it's too easy to confuse and no semantically a good opposite either, but visually it does look very balanced.
I've seen it a lot in Spain as well. I guess it's a combination of just being the reverse of OK, and also "KO" meaning "knocked out" just feels like the opposite of OK.
I've always just understood it as in knockout, chaos wouldn't fit in the way OK and KO are used (as predicate adjectives, if I understand English grammar classes correctly) but it is part of why some people like to use "KO", I'm not sure.
The origin of OK is disputed; however, most modern reference works hold that
it originated around Boston as part of a fad in the late 1830s of
abbreviating misspellings – that it is an initialism of "oll korrect" as a
misspelling of "all correct". This origin was first described by linguist
Allen Walker Read in the 1960s.
In nix packages (derivations) are so lightweight that your store has tens of thousands of them, many with the same name, or with no meaningful name at all. On the rare occasions that you need to look in the store for a package you’re much more likely to be looking for a particular hash than a particular name. That, and having the hash as a prefix looks nicer in tabular output.
> 2. listing the contents of the store directory would not be allowed
Wow, that's awful, that's what Windows AppStore does, so it's even hard to see how much of the preinstalled garbage there is or even whether you might have a huge game you forgot to uninstall but might want to to free up some space.
What's the cool benefit that could justify this limitation?
Nothing should rely on how store paths are named, ever. Like, there is actually no reason to know that hash 1234abc is a certain output of derivation xyz-12.1.0. The contents of the store can be garbage-collected at any point. So you actively do not want things outside the Nix store (or managed by NixOS tools, or Nix-aware tools) referencing paths in /nix/store.
If you do something like write a config file that references /nix/store/1234abc-xyz-12.1.0/bin/xyz, that config file will break the next time you update the derivation that produces that path. Again, this makes knowing what things are in the store completely pointless unless you are writing Nix-aware tooling or debugging, in which case there are tools to show you what path your derivation produced. But you should never need to do the opposite, which is to resolve which derivation produced a path in /nix/store/.
The Windows Store problem is completely orthogonal; paths in /nix/store are not "installed" on your system, they are derivations or outputs of Nix derivations. NixOS "installs" things by adding some of these to your PATH in a shell script that is also a derivation output in /nix/store.
I'm afraid this doesn't work in a generic Unix world -- what stops an application from saving some env variable it was first initialized with into its local config and later accessing them (and potentially failing if they were GCd in the meanwhile)? E.g. many developer tools store references to compilers and the like.
Nix is over 20 years old. We've fought all those tools and won by now. (I.e. we've figured out how to configure them to not do that when we don't want them too.)
I am using Nix everywhere and have some packages contributed, so I do know how it goes - and there absolutely are cases like I have mentioned. Sure, apps can be patched, problems can be circumvented, but a fundamentally malicious/ignorant program can end up a pain in the ass for nix to manage (without bringing out the big guns like build FHS env)
Best way to deal with the sense of doom imo is to actually use it. You'll find how dumb it really is by itself, and how much of your own judgment/help/editing is still necessary to get anything usable. It might look like magic from these manicured press releases, but once you get your hands on it, it quickly becomes just another tool in your toolbox that, at best, helps you do the work you were doing anyway, more quickly.
I work with these models professionally (well, I’m a web dev working along side people manipulating these models). When you give it a prompt and it spits out a pretty image, remember that the range of acceptable outputs is very large in that context. It demos very well but it’s not useful outside of stock image/stock video use cases. What artists and engineers actually do is work under a rigorous set of constraints. Getting these models to do a very specific thing, correctly adhere to those constraints, and still maintain photorealism (or whatever style you need) is a very much unsolved problem. In that case the range of valid outputs is relatively tiny.
> As an American, sitting down next to a European on vacation for more than a few minutes is never fun. Once they inevitably ask "Where are you from?", they follow it up with a lecture on American politics before I can even finish my sentence. It's tedious and it's nothing new.
Counter-anecdotally; I've never experienced this and in my workplace at least, the people who never stop talking politics are all American.
Haskell's type system works because of purity, and purity doesn't generally mesh well with performance-oriented applications like game engines. There are some type-driven approaches to gamedev, like https://github.com/jonascarpay/apecs, but it's fairly experimental. There has been some talk about linear types, which would allow Haskell to have controlled impurity similar to Rust, but they're still a ways off.
However, to allow the compiler to optimise pure operations to impure ones, I don't think linear types are sufficient. You need something like uniqueness types.
I think C++ compiles down to a pure functional language that is then optimized into an efficient beast. So I'm not sure that pure code is hard to optimize.
SSA is quite different from a pure FP; for example it doesn’t do anything about effects, it only gets rid of local imperative assignments that don’t really interfere with purity anyways.
Most imperative languages have an intermediate language in which local variables are immutable. However, purity is about more than immutability. For example, in C++
x = doSomething(x) + 1
Can be written to not overwrite x
int x2 = doSomething(x) + 1
This is equivalent in some ways to Haskell
let x' = doSomething x + 1
However, I know that in Haskell, evaluating 'doSomething x' will not turn off the computer, display anything to the user, or launch missiles. I have no idea what evaluating 'doSomething(x)' does in C++. It may add things to caches, exit the program, etc.
The author, some of the comments here and especially the author of the Gizmodo article seem to lament the fact that passwords aren't stronger. I have no idea about whether or not that is justified, but a list of the most common passwords is in no way reflective of average password strengths. A good password is probably unique in the world so by definition the only passwords on this list are those that are trivially easy to come up with. A more interesting statistic, I think, is what percentage of the world's passwords is '123456'.
This is a good point. If these are each used by 2 people, it's not very interesting. It's sort of implied by the attention these stories get that the problem is much bigger than that, but I agree the story is incomplete without the magnitudes. And for the rest of us, we should care about the _trend_ of the % population using common passwords. In order to be safe, you probably need to stay above some constant level that is "good enough" for any hacker trying patterns or brute forcing. As the bottom gets more secure after reading articles like this or adopting password managers, we all need to step up our game. The first to go will be people who do things like:
- put a capital letter first and only first when a capital letter is required
- put a special character last and only last when a special character is required
- put a number next to last and only next to last when a number and a special character are both required
These will be the next patterns tried after the most common passwords, dictionary attacks, etc. -- and if you stay ahead of _these_ people then you'll be good for a while.
