I would say `narrator voice` in this context is distinctly different from internal dialogue. Obviously the internal voice can narrate to yourself, but that voice tends to be slightly different in my experience.
Narrator voice is a specific voice, cadence, pattern etc. that your internal voice takes on when reading a narrative, rather than the narration of your experience. For me, I have a different voice when reading/writing technical documentation compared to reading/writing fictional works, which both are different from my day to day internal dialogue.
I have a narrator voice when reading code. It's the same narrator voice as when reading technical reports and white papers. I do sometimes struggle to process code that doesn't read well, likely because the cadence of the narrator voice gets disturbed and doesn't flow well.
I've found that my descriptions and explanations of how things work generally follow the same cadence as this narrator voice, which tends to help me explain things succinctly and transfer knowledge quickly.
I do agree it's distinctly different from the narrator voice for fiction books. I would assume that's due to the presence/lack of emotive language between the two types of writing.
Perhaps this is a similar phenomenon to the inner monologue that some people have but others don't? Or the ability to imagine various levels of detail of objects without physically seeing them? The mind is a strange beast.
...you can mark all the books you've checked with a hole so you know you've checked them.
Work harder, not smarter. /s
Jokes aside, I still agree with GP, in that there are more practical skills that are left out of education that would be far more useful in day to day life. The Dewey Decimal System has been replaced with search engines.
I don't need to know how a search engine works in order to type in "how to use a drill press" and read the results. But that's because the knowledge and understanding of how computers work at a high level circumvents the need to do that - a search engine is a form, give it something to search and hit the submit button. Easy.
Being taught by someone to use machining tools helps build an understanding of how every day items are made using those tools, so you have a more fundamental understanding of the items could be combined together into other more interesting things, repair them, take them apart and service them.
It's almost the opposite problem of maths in schools. We're taught maths in various incresasingly complex ways, all the way up to calculus. Those methods teach us how to use maths to do clever things. But every day maths doesn't need that. We're taught compound interest, but we have to use that to figure out how to do our taxes by ourselves without any help. Wouldn't it be nice to have an overlap there, hit two birds with one stone and we all walk away with a stronger understanding of the world?
If we're not taught how to make things, we struggle to learn how things are made, which means less things get made. Learning how to make things early, and embedding the knowledge of how things are made, enables more things to be made in future.
Yeah, sure, today we can teach people to use a search engine and whether you should believe the first result. Is the chatbot always truthful? Not sure when or why it was decided that media literacy isn't a useful everyday skill.
But the only differing cost in that scenarios is the 2 extra conductors to the local transformer, and more likely just to the edge of the property. The 3-phase power is still present in the area, as ideally alternating houses are on alternating phases to balance the load over the phases. The difference in cost would be a one-time hit during installation, and the ongoing maintenance would be the same as 3 separate houses (1 house per phase). That maintenance could be rolled into the cost per watt, so the more you have available the more you can use and the more you could pay.
The installation cost should vary based on what the house wants access to, and the ongoing cost should be the same as every household. A standing charge for the cost of the infrastructure existing is ridiculous when that same infrastructure is what the power company relies on to deliver their chargeable commodity. It's effectively double dipping - how is it any different from ISPs charging for access and then charging for data on top?
I think an important consideration is that the overall grid is not designed for all houses to have the higher capacity connections. So enough connections and they're forced to make massive changes to the infrastructure.
Not to say utility companies don't make obscene profits instead of reinvesting much of that into the infrastructure.
Regarding the ISP, its really the same argument. If I want 2GB/s on a neighbourhood line that supports a max avg service size of 1GB/s then they would be forced to upgrade their lines to service me. Granted, unlike power grids they're liable to just not do that and let service quality degrade and quote the "Up to X Gbps" clause
IANAL, but I believe the terms of the purchased license would be to use the product with only the license key provided. Therefore using an alternative key would be a breach of the license terms, meaning you're using unlicensed software and subject to all relevant laws.
I can see an argument that the vendor is in breach of contract by failing to provide a valid key with the license, and therefore the contract is void and the vendor should refund.
And yet again, I can see an argument that the license has been paid for, and a different key is used in the interim to access the paid for software, therefore no loss has occurred to either party rendering the whole argument moot.
Would be interested to know if this has been tested in the court system.
Depending on jurisdiction there may be rules or case law related to re-engineering and patching of purchased software to keep it working. This is again a reminder how important the right to repair is.
Commonplace books, reading reflection, daily log, zettelkasten are all alternative techniques that achieve much the same as a log book, with various pros and cons to each. Building a Second Brain is also an interesting technique, but is more focused on knowledge documentation rather than logging and benefits massively from being digitised.
I'm a believer that logbooks, journals, diaries, notes, or whatever else you want to call it, are a personal thing and so it's about finding your own way of achieving what you want to achieve with those things. I've not found a single technique that works for me as it's described. That may be an issue with the author, the article, the concept or (more likely) me. But I try to adopt the ideas that I found work well and drop those that didn't.
I keep a bullet journal, although it's kind of somewhere between a bullet journal, commonplace book and daily log. Similar to the article, I tend to take lists of tasks each day; not as a todo list, but as a list of things I want to achieve. As I achieve them, they get ticked off. As I progress them, I write notes about what I'm doing or have done towards them, perhaps splitting them down into smaller tasks, etc.
There's also some personal tracker things from bujo I use, but they are generally just metadata around each daily log. Things like mental health, meal tracking, etc. But the most important thing is separating daily logs from single and double page spreads, and labeling them in a contents page for easy navigation.
If I come across something of interest, I treat it like a commonplace book to capture that interesting thing; recipes, project ideas, reference materials, arbitrary thoughts, and more. Similar to zettelkasten's fleeting notes concept, anything I want to revisit later I write down.
In my opinion, the power of this technique comes from how to link these things together - just writing them down isn't all that useful to me. So maintaining an accurate contents page to be able to quickly jump to a project or tracker spread makes navigation easier, while also maintaining an index for collating specific ideas mentioned sporadically across the entire logbook means I can trace an idea through the logbook (or multiple logbooks). These both mean I can actually go back and look at something specific, or quickly scan for topics that may relate to a new idea and leverage the work I put in when originally writing it.
But, this is just what works for me and doesn't necessarily mean anybody else would benefit from it. And I think this is the key thing naturally omitted by many note taking tutorials, blogs, etc. They're trying to sell you on the solution to end all your problems, when there's no guarantees that the technique even works let alone will work for you.
If you want a web GUI, then pfSense or OPNSense are the general go tos.
However, if you're comfortable with CLI and modifying configs in /etc/ then just running a bare metal Alpine Linux box is perfectly doable on a tiny box. iptables/nftables for firewall/NAT, dnsmasq/bind9 for dns, dnsmasq/isc-dhcp for DHCP. I've got a handful of these boxes all interlinked via wireguard, sharing routes via BGP using bird.
Sure, you miss the config verification that VyOS provides, but does mean you learn the underlying tools themselves and that knowledge is portable to any other box running those systems.
Personally, I don't quite understand why VyOS is a standalone distro when it could just be a config generator/checker package. Could even support multiple different underlying tools so if you want to use dnsmasq over bind9, or vice versa, it can provide a unified config interface for them.
isc-dhcp is EOL. I'd suggest using kea-dhcp from the same ISC. I believe there could be a script or some kind of migration path from isc-dhcp to Kea. I've been using Kea in production with no problems.
I really wish there was a better option for a Linux DHCP server. At my past job we were using isc-dhcp and it was absolutely horribly showing it's age (md5 api "keys", bespoke socket-based API "protocol", most things impossible to do via the "API", clustering that didn't really work, etc.). Kea is barely an improvement, with oddities such as being written in C++ and requiring recompiling for plugins, or an extremely weird API. It's obvious is still written by the same old folks who have no idea how software is supposed to work in the 2020s.
We need something modern - easy clustering, modern API, event stream, gRPC-based plugins, etc. (And yes, I have thought about developing it myself, it's on my pile of TODO)
One remark.
Kea doesn't have some of functionalities provided by ISC-DHCP.
If you use a lot of dhcp-eval and make decisions based on different dhcp options content kea is still a no-go since there is no workarround. Usually at ISP level dhcp is one puzzle of much more complicated system.
I tried if few times and every time I stuck on something and messagefrom developers was: this isc-dhcp feature is not supported.
This was huge national scale ISP and bypassing those limitations means a lot of $ to adapt surrounding systems providing input to isc-dhcp LDAP DB in its own config style.
If wanting internal and external subnets as "zones", iptables/nftables lets you match against incoming and outgoing interfaces. It would be trivial to make match against an incoming interface and jump to a zone specific chain. This is how I manage private subnets. fw-mark is also useful for setting routing rules. Can change which routing table is used by matching rules in iptables.
If wanting to do more stateful things, I'm not aware of any default package, but setting a rule to send packets to an NFQUEUE and implementing some custom logic on that nfqueue would be rather trivial too. I'm sure eBPFs are useable in there somewhere too, but I've very little experience with them.
Obviously iptables/nftables has its own issues, as seen in recent (and not so recent) posts about it being bypassable with raw sockets, but that tends to be host only and not when used as a gateway.
You create a _zone_. You name it and assign some interfaces to it. For my needs, I only assign 1 interface per zone. Then, you specify with which other zone that zone can receive traffic from. That also comes with the identification of a firewall rulesets to apply to that pair.
So, `'Zone WAN (iface eth0) <- Zone LAN (iface eth1)' => apply fw LAN-TO-WAN`
When you do that, the firewall rules become much simpler to write and maintain.
But, a best practice is to assign every zone to every other zone. This soon becomes a combinatorial nightmare. When you want to add a zone, you have to create 2xN new zone configurations and 2xN new firewall rulesets.
iptables -N eth0toeth1;
iptables -P eth0toeth1 DROP;
iptables -A FORWARD -i eth0 -o eth1 -j eth0toeth1;
iptables -A eth0toeth1 -m tcp -p 80 -j ACCEPT;
# add any more rules
Or, as you say to avoid exponential combinations, just make a chain for each zone (interface) and explicitly allow specific protocols/ports to target interfaces. Zones with multiple interfaces are just multiple rules to jump to the same zone chain.
Modern Effective C++ by Scott Meyers is my go to for people in this situation. I'm not sure if there's an even more recent edition that covers C++17 and C++20, but C++11/14 is definitely a great head start over C++03 and earlier.
The most amazing thing about it is how it manages to be so entertaining to read (the last thing I expected from a C++ textbook and a thing that made getting through it way easier)!
>I'm not sure if there's an even more recent edition that covers C++17 and C++20
Somewhat agree, however I think it's because building redstone actually requires some materials science type knowledge. i.e. how different materials and physical structures affect the redstone signal.
Redstone blocks vs redstone torches, and their relative strengths/purposes. Torches on sides of normal blocks with signals entering the side of the block. Using normal blocks to prevent redstone signals from connecting (particularly when going up or down stepped inclines). Space requirements to allow a signal to drive a block and not just terminate the signal next to a block.
These are all game analogues of laying out P and N state semiconductors, or conducting signals from one area of a chip to another and maintaining their signal quality, when designing ICs. Granted, these processes are hugely automated by tooling, but someone has to know, learn and understand how the materials science works in order to develop those tools.
This is why I'm surprised I've not yet seen a VHDL/Verilog compiler for minecraft redstone. Converting a gate array and netlist into a minecraft world feels like a relatively simple challenge for anyone with the knowledge, but I guess it's too niche of a project? Or I'm just not looking hard enough for it.
Narrator voice is a specific voice, cadence, pattern etc. that your internal voice takes on when reading a narrative, rather than the narration of your experience. For me, I have a different voice when reading/writing technical documentation compared to reading/writing fictional works, which both are different from my day to day internal dialogue.