> do you just scramble keys when picking an address?
No. Your ISP or tunnel broker gives you a network prefix. Then you configure SLAAC to use that prefix and hand out addresses within it. Job done.
For example, the prefix might look like 2001:470:e904::/48. Your computers can use any addresses you want as long as they start with that prefix. Since you don’t want to manually hand out addresses to every computer, you configure a router to hand out addresses via SLAAC. Your computers will use SLAAC to discover the prefix from the router, then fill in the bottom 64 bits of the address with a random number. They then ask the local network if anyone is using that full address. If not then they are done and have a working address. If somehow someone is using that address then they try again with a different random number. Servers that want a fixed address will just use their network card’s MAC address (or anything similar, if you want) instead of a random number. The protocol is the same either way.
Notice that this actually gives you some bits of your own to play with, if you want. The full address is 128 bits long. The first 48 were used by the prefix and the bottom 64 by the individual devices, leaving 16 bits in the middle. You could tell your router that the prefix for SLAAC is 2001:470:e904:42::/64, for example, and then use the other subnets for other purposes. Maybe 2001:470:e904:beef::/64 is a special subnet just for your meat freezer and associated monitoring equipment. I don't know, you get to make these things up for yourself. Maybe you manage a corporate network that has a separate VLAN for phones than for normal PCs, and a third VLAN for the guest WiFi. You can give them each a different prefix by embedding the VLAN id into the prefix you advertise via SLAAC.
There’s also DHCPv6 if you want even more control over which addresses are handed out, or you want to subdivide your network even more finely. Or if ISPs ever start handing out smaller prefixes.
> If your ISP gives you a static IPv6. Unfortunately in Germany none of the ISP for private users does (last I checked).
Sure, that’s true. But they probably don’t hand out static addresses for IPv4 either. Not without paying extra, that’s for sure. Either way if you want some static identifier for your computer(s) then the solution is the same: DNS.
Of course if you _are_ running a corporate network with a bunch of VLANS like that then you should actually get your own prefix from your RIR rather than from your ISP. Then you purchase IP transit services from your ISP rather than consumer internet access. You can then advertise your prefix(es) via BGP. Again, this is exactly what you would do for IPv4. Same software, same configuration, just longer addresses. The main advantage of this extra work is that you can keep your addresses static even if you move to an entirely different ISP. You can also use the same addresses over multiple connections to multiple ISPs for better redundancy.
This is a good overview. I think the difficulty with IPv6 is that people rely on all of the crutches invented for IPv4 as features: private addressing NATing gives you security (it doesn't) and portability (it does), IPv6 usually uses subnets per physical location making failover difficult, where as IPv4 will use bgp announcements to failover public IPs, etc. I'm not saying one way is better than the other, just that IPv6 is pretty different and people very much have a IPv4 world view.
> But come on! It is a legitimate question, do you just scramble keys when picking an address?
I did give the answer: SLAAC.
> If your ISP gives you a static IPv6. Unfortunately in Germany none of the ISP for private users does (last I checked).
Weird, here in the UK all the ones I've had have given me a static /56. Still, the same answer for that (DDNS) exist as for dynamic IPv4 addresses, you still get the advantage of not having to deal with NAT.
`attr()` is being updated to basically do that, the modern spec lets you specify a datatype and access any attribute (with some exceptions, you can't get URL types for security reasons), then use it generally.
It's an obvious quote, unless you think people are going to misunderstand and think that the BBC as a publication is talking about it's mother somehow. Quotes are generally well understood to be the view of the person giving it, not the publication.
I think people are going to expect the BBC to validate the correctness of quotes that they elevate into headlines. The interviewee didn't decide that that quote should be a headline, that's a creative choice by the BBC. By putting it there, they are implying that it is an accurate description of the story that follows. Is that incorrect?
2. Is by definition of an accurate representation of the words of the person they are quoting
3. Is a reasonable overview of a complex story, given we understand that "free-spirited" is subjective and that, again, this is a human interest story and conveying the feelings of the people involved is part of the point.
I don't know what you're getting at with 1 and 2. If the person they were quoting claimed to have been abducted by sasquatch, you could still make these two points. Would you still be arguing that it doesn't reflect poorly on the BBC to put that false claim into a headline?
If you would, that is probably the heart of our disagreement. If not, I guess it comes down to an agree to disagree on whether the subjective window of the personality trait 'free-spirited' can include 'active participant in violent resistance against a dictatorship'.
> If the person they were quoting claimed to have been abducted by sasquatch, you could still make these two points. Would you still be arguing that it doesn't reflect poorly on the BBC to put that false claim into a headline?
No? That’s a very good headline for an article about someone who believes that they were abducted by a Sasquatch. It would be a missed opportunity for a newspaper to NOT do.
Yes, it's incorrect. You seem to be under the impression that headlines need to be dry facts, which is just... not what they are or have ever been. Using a quote that draws you in to read is a normal, common thing to do.
You can use React with just JS, JSX isn't core to React. htm is a library that uses string templates and is just Javascript but works like JSX and can (but doesn't need to be) compiled down like it, and you can use with with React or other tooling.
Is the DPRK a democracy? They claim they are, so should a wiki blindly report that they are?
Likewise, it's absurd to claim Gamergate was about "ethics in game journalism", even a cursory look at what the movement actually did makes it very clear that was never the focus.
It's not biased to look at what happened and report that people didn't do what they claimed to be doing.
I'm a little amazed people still have the perspective of "a few more years" when it is very clear that the Republicans have no intent of offering a free and fair election. The rubicon has been crossed ten times over, they got into power after attempting a coup last time, all the safeguards and people who would refuse are long gone, if they don't succeed this time it'll be through sheer incompetence rather than anything else.
I believe satisfies will narrow the type const infers. It won't lose any information, so you can check it satisfies a broader type without stopping it being used as a narrower one, but it will narrow down the inference if given (but you can of course widen it back out with an explicit typing).
I tried zoxide for a while but I really disliked how it made things fuzzy, and most of the use cases for it I found were 90% solved by using ZSH's history search which I use routinely anyway.
It gives you this potentially constantly shifting set of shortcuts, essentially, and the problem is that means I have to constantly check I did get the result I wanted, and that I haven't accidentally gone to the wrong place. I found that more annoying to me than just using tab completions or history, which are much more predictable.
I can see how someone who has different workflows or environments might find it great though.
How are you using Zsh history to navigate to specific folders? E.g., does that mean you always start your `cd` from the home directory (e.g., `~`)? I'm asking because it's usually less key strokes to `cd` to a relative directory (assuming you're working in several related directories). But then the `cd` entry in your history would assume a specific starting path (and therefore wouldn't be universally helpful to recall from history)?
Also, re:
> the problem is that means I have to constantly check I did get the result I wanted, and that I haven't accidentally gone to the wrong place.
Is there a reason you don't add your current path to your prompt? I don't know how I'd work without that, never knowing which directory I'm in.
I like using fzf combined with zsh's shell history filtering.
You can type `cd ~` and press CTRL+r to immediately fuzzy match commands you've run with `cd ~`. fzf naturally ranks paths to cd into on top. If you find that too noisy you can just hit CTRL+r with an empty prompt and then search for `^cd ~` to only find cd commands.
If you want to go into ultra lazy mode you can also type `cd ` and spam the up / down arrows to only show commands from your history where you cd'd into a directory. That use case is also covered in the above post. I normally don't use this for changing directories but it can be done.
The premise is the same: Dump history into fzf and add a grep/awk.
My point was that requiring a new shell (or even history) is a limiting factor here, and either backwards search over commands (as suggested ITT), or just plan fzf directory changes are more functional and already integrated into bash.
`cd foo` is useless in history if you're not already in foo's parent directory. This is the problem Zoxide solves, `z foo` will still do something useful in that case. (Side note about fzf, recursively fuzzy finding subdirectories fine for some use cases, but it doesn't scale as well as Zoxide.)
Yes, the marginal improvements from changing your entire shell are not to be disregarded. I'll change to asserting that it's entirely possible to do a nice 80/20 without changing shells.
What do you mean? Zoxide isn't a shell, it's just a CLI program. It doesn't involve changing shells, you can see the list of supported shells in the README (it's more comparable to fzf than a shell, it ships with optional shell integrations the same way fzf does).
How did you get all the way down here and lose the fact that top level comment is about zsh and finding past commands, and also changing directories? Was it not you that brought up zsh?
And I that brought up bash examples to show how it might be done? We've gone around in circles lads back on the bus.
To me, the interesting conversation here is between these three workflows:
1. Recursive directory fuzzy-search
2. Searching history for `cd` commands
3. Zoxide-style matching visited directories
Which are all ways to make it easier to traverse directories.
For my part, the thrust of your argument seemed to be advocating for #1, so that's what I was responding to (since this is a thread on #3, I'm mainly focusing on why you'd use that instead of #1 or #2, but all three are workable).
All of these can be implemented in any of the common shells. I didn't see anyone making a case for a specific shell here, I think the mentions of a specific shell are incidental (e.g., what people happen to use).
My logic (take it or leave it) is that since zsh is not the default distro nearly anywhere (Kali?), a randomly selected person who might read that advice (and subsequent advice ITT), would likely find "Use ZSH" includes a shell change and therefore more learning curve than "add a few lines to .bashrc".
This is getting off topic, pedantic, and (maybe?) argumentative so I'm calling it quits. Cheers.
I use autojump, which is a lot like zoxide (possible predates it). It stores all the directories you've visited in an SQLite DB (along with the rank for each). I wrote a shell keybinding that presents me with fzf, along with the directories I've visited, in rank order.
With just a few keystrokes, I can visit any directory I've ever visited, really fast. It doesn't need to be the top ranking directory for my query.
Yeah the problem with this approach to me is populating the history with a bunch of cd to absolute paths to begin with, which is not something I'd do natural (I have many ways I'm navigating the file system), and definitely wouldn't do manually. Not having to populate that list is the advantage of zoxide.
- Recursive directory tab completion isn't viable for many key use cases (it'll hang with both monorepos and networked volumes). The only thing that makes zoxide viable is that it only matches against visited directories. (Similarly fzf doesn't have much of a relation here besides encouraging recursive fuzzy matching, which I tend to avoid because it doesn't scale to complex directory structures.)
- Zoxide is probably sponsored by Warp, I doubt they have a relation beyond that, I'm not sure but they don't have much of a synergy beyond both being written in Rust. (The main point of relevance here is Warp is venture funded.)
- Zoxide having a database outside of the shell is actually a huge advantage to me, because it makes it easy to access your database outside of the shell (e.g., Zoxide integration in Vim).
I think that's ok if you have absolute paths mixed in.
If I have some long path like ~/src/open-source/dotfiles or /home/nick/src/open-source/dotfiles it all works with fuzzy matching. You can hit CTRL+r and then search for "cd dotfiles" and it finds it. The ~ isn't necessary, you can also do "^cd dotfiles"` for a tighter list of matches for paths that are more ambigious with other non-cd commands.
It's not that I always use absolute/home-relative paths, but I'm almost always working from the same folders for the context: if I'm working on a project, I'll be in the project directory and work relative to that the vast majority of the time, for example. I also use the substring history search which makes it more useful for the equivalent to zoxide's case.
And I do have my path in my prompt, I'm not talking about something that actually takes time, but more interrupts flow (for me, as I say, I get how for other people it'd work better).
The issue for me with this approach is one: It assumes a clear root for a project (e.g., your base you're cd-ing off of), I think that's only good assumption for small-scale projects? E.g., sufficient complexity, for programming at least, necessitates modularity which dilutes the concept of a "root".
The other issue is that it creates a separate "hop" which adds key strokes and cognitive load (i.e., I can't just jump directly to a subdirectory or related directory I first have to jump to a "junction" directory then to my destination).
In any event, I could see how that would be a reasonable approach in the absence zoxide, but those are the reasons I personally still prefer zoxide. (For the record, zoxide has some nice techniques for making a match more specific, e.g., `z foo bar` will hop to a dir containing `bar` only if it's in a subdirectory containing `foo`.
Mcfly[1] takes your working directory into account when searching shell history.
From the readme:
> The key feature of McFly is smart command prioritization powered by a small neural network that runs in real time. The goal is for the command you want to run to always be one of the top suggestions.
> When suggesting a command, McFly takes into consideration:
- The directory where you ran the command. You're likely to run that command in the same directory in the future.
- What commands you typed before the command (e.g., the command's execution context).
- How often you run the command.
- When you last ran the command.
- If you've selected the command in McFly before.
- The command's historical exit status. You probably don't want to run old failed commands.
I love that mode in Atuin. I can never remember which of the run commands to use between make/cmake/bazel/yarn/npm/uv and hitting ctrl-r twice and scrolling up is better than having to root around in a readme, which I may or may not have bothered to write for my future self.
Oh I forgot about "just"! (and I have Opinions about that name.) Add that to the list. Making order from chaos is not unfamiliar to me. Previously I standardized on make and was fastidious about making makefiles, but with atuin, command directory history the extra effort to create makefiles became superfluous.
I used to have this fantasy that after I die, someone will care enough to go through my ~/projects folder and go through everything I worked on, and all those makefiles and readmes were going to help them, but no one cares that much for me. I'm okay with that, depressing as it is.
That's not default behavior in most shells (e.g., `autocd` in Zsh, and, for the record, that's also not default up arrow behavior in Bash or Zsh [it is in Fish]).
But my question is specifically about relative vs. absolute paths when recalling directory traversal from history. I'm still struggling to follow how you'd use Zsh history as a zoxide replacement without always using absolute paths.
I generally work in only a few folders (we'll call them project a, project b, project c), so once I taught it these are high priority, it just works when I type any part of their names
In Zsh with `setopt autocd cdablevars`, shell variables more or less work like cd-aliases. You could also just add `a=projectA; b=projectB; c=projectC` to your `~/.zprofile` and then at prompts type 1-letter commands `a`, `b`, `c`.
One added bonus of such file tree bookmarks via variables (over a similar `alias a='cd foo'`) is that if you get muscle-memory/active memory for those few abbreviations other use cases like `make -C $a` also work. I usually leave `$hb` & `$lb` set to `$HOME/bin` and `/usr/local/bin`, for example.
# BOOKMARKS (mark b)
declare -x -A bookmarks
bookmarks=(
d "$HOME/Desktop"
dd "$HOME/Downloads"
c "$XDG_CONFIG_HOME"
)
for key value in ${(kv)marks}; do
hash -d $key=$value
done
Then I can just use ~c, ~d or ~dd or anything temporary I want to put there
`hash -d` (aka "named directories") is surely an alternative and if that suits you, by all means.
I see at least two downsides: 1) now you have to remember to say `make -C ~c` { not `make -C $c` which I think most would find more natural } 2) the hash cannot be exported to inheriting subprocesses like a regular scalar $var.
Of course, 1) is kind of weak since you can also use "~var" most places. It's just not as familiar to many as $var.
One notable equivalency is that Zsh prompt escapes for $PS1 and friends like %~ would treat both the same - converting them to a "~c" inside your prompt.
So, in terms of "looking like what you type", that maybe makes ~c better. Maybe there is some setopt to make Zsh expand %~ as $c or $dd? Not sure. There are a lot of setopts.
Anyway, I actually use the exporting feature to non-Zsh subprocesses myself. So, I'm pretty locked-in to vars not just hash entries.
The comment above is something I love about HN. I never knew this existed and would not have even thought to search for it but, but that’s something that I see me using everyday.
Glad to be appreciated. You might also enjoy this snippet from my zshrc:
my-expand() BUFFER=${(e)BUFFER} CURSOR=$#BUFFER
zle -N my-expand # Make Alt-E expand environ vars w/o val escape
bindkey '^[e' my-expand # Allows eVar "short cuts" for history !!:gs etc
It's vaguely related in that it lets you put a variable in the main Zsh Line Editor (ZLE) buffer (with the leading `$`) and then press Alt-E to expand it. ('e' for E)nvironment-E)xpand).
As per the comment I did this so that I could have "history substitution expressions" stored in variables, then Alt-E - look (& maybe edit) & ENTER.
The history syntax itself is very cryptic, derived from early 1980s BSD csh. As with most such crypticnesses, figuring it out once, storing it somewhere you can remember, and expanding it on demand is a not awful way to learn it.
But besides cryptic history directives you could also use it for the `$a<Alt-E>` above to "see before you do". You need an extra `$`, though, as written. It would be pretty easy to auto-add a `$` prefix in `my-expand`, though (with Alt-E just becoming a sort of different kind of TAB for expansion rather than completion).
Yeah, I've been trying it recently and I'm not entirely convinced I want to keep using it.
My biggest annoyance at the moment (and this may be me missing something), is that I have two directories: "thing" and "thing-api". I'm doing work in "thing" much more often than in the "thing-api", but whenever I run "z thing", it takes me to "thing-api" first, and I have to "z thing" again to get to where I wanted to go. It ends up being more effort than if I'd just tab-completed or history searched a plain cd command.
Perhaps helpful: There's also a `zi` command, which prompts you with a list of all matches before changing directories. Personally there's only few directories where I need it, and I just memorize using zi instead of z for those.
However I agree z should ideally have some syntax like `thing$` to denote a full directory name instead.
> Yeah, I've been trying it recently and I'm not entirely convinced I want to keep using it.
> My biggest annoyance at the moment (and this may be me missing something), is that I have two directories: "thing" and "thing-api". I'm doing work in "thing" much more often than in the "thing-api", but whenever I run "z thing", it takes me to "thing-api" first, and I have to "z thing" again to get to where I wanted to go. It ends up being more effort than if I'd just tab-completed or history searched a plain cd command.
AFAIK the z command does take frequency into account (or was it most recent visit). However to avoid going into thing-api instead of thing I believe you just type thing/ i.e. At the slash and z will take you to thing (that obviously doesn't work with tab completion though).
I found that after some time I have gotten so used to z (which I aliases to cd) that I wouldn't want to live without it.
The aha moment for me was to type a space after the characters I'm searching for - then hit tab. You then get the list of options ranked (and a nice view showing the contents of each folder).
I wrote a shell keybinding that presents me with the candidates using fzf (in rank order). This way I can see which one it will go to and pick the "correct" one if need be. It's blazing fast.
You're right, "z d" to always to always go to your downloads folder if way more powerful than whatever fuzzy match can achieve, and unfortunately the project didn't want to add a predictable input mechanism, though maybe that'll change in the future...
Ah, good point, this isn’t `oh-my-zsh` but it does require a couple of options to work as described:
1. `setopt autopushd pushdsilent`: This is the key component, `autopushd` automatically adds directories to the directory stack (and `pushdsilent` option does it without echoing added directories). Without this option, there’s no directory stack to traverse (unless directories are first manually added to it with `pushd` [for completion, `popd` pops directories off the stack navigating back to those directories]). `autopushd` just calls `pushd` on the current directory after each `cd`.
2. To get a menu, Zsh completion also has to be loaded, e.g., `autoload -Uz compinit && compinit -C`
3. Finally `zstyle ':completion:*' menu select` is optional, but that highlights the selected match, which is a nicer UI in my opinion.
Those are the options I used to get this working with `zsh -f` (which starts Zsh with a default config).
Your best argument is "we've done it for a long time, so it can't be wrong"?
Quite the contrary: there is a long history of "objective" tests being shown to be deeply flawed and biased towards certain factors (often cultural and class based), we explicitly know it isn't the case that test scores are purely about some innate intelligence characteristic: there is a reason the rich spend a lot of money to raise their children's scores.
My secondary school claimed to have the best results for Business Studies A-levels in the country. They achieved this by taking the pre-released case study, writing every possible question they could think of about the study, writing model answers, and telling the students to memorise them. The idea that these scores represent some innate intelligence of the student is obviously nonsense if you interact with the system at all.
It is strange to pretend that there is no cultural bias and then given an example that is usually explained because Asians seem to culturally value more education than white British.
How will you explain that Asians outperform white British otherwise, knowing that the idea that Asians and white British are genetically different enough to explain this has been scientifically debunked, or that adopted Asians don't show the same pattern as not adopted Asians?
(and, yes, of course SAT is highly predictive of college performance, isn't that the point: people who get better training get better college performance while not being "smarter", just "better trained")
I’m talking about the supposed cultural bias of the test itself, not cultural differences among test takers. A culturally biased test is one that requires familiarity with a particular culture, generally that of the people who wrote the test. If Asians do better on a test developed by British people, that suggests that the test itself is not culturally biased.
Your argument would have been more convincing if the Asians were getting the same as British people.
But as soon as the Asians do better, it means that the whole comparison is meaningless. It means that Asians and British scores differently. Maybe Asians normally should score 14 and British score 10, but they score 12 because the test is culturally biased.
(sure, we expect that a small difference in "normal situation" should be relatively small, but the samples are defined as biased, so you cannot really rely on them unless making unproven assumptions)
There is no reason to expect that the test results would be the same across all demographic groups, and in fact, everything we know about psychometry (i.e. the science of mental testing) suggests that we should expect exactly opposite. See e.g. "Intelligence: Knowns and unknowns", which described the consensus position of the American Psychological Association as of 1995:
> The cause of [test achievement] differential is not known; it is apparently not due to any simple form of bias in the content or administration of the tests
themselves.
Not sure what is your point, the "test achievement" mentioned in the document refers to totally different "test" that the ones we were talking about.
Also, on just pure logic, I don't think the document shows what you think it shows. The document you provide (which is 30 years old, so with just this one, we should not assume it reflects today's consensus) explains that the difference is not understood, and that there is no _obvious_ answer, neither from biology, from group culture or from bias in the tests. In other words: the difference is due to something _not obvious_, for example (but not limited to, of course, it's just an example), _not obvious_ form of bias.
- Open holes through firewalls, point DNS at the address, and it should just work, the joys of actually having public addresses.
- Same way as with IPv4 mostly. The only real difference is because SLAAC assumes a /64 you probably want your networks to be at least that big.