363 karma · joined September 15, 2013
1. https://learn.microsoft.com/en-us/troubleshoot/windows-serve...
[1] https://www.additudemag.com/attention-deficit-disorder-vast/
I imagine that the laptop you were given in 2018 was not an NMCI laptop, but instead a laptop from either the Navy or Marine Corps' new ownership/operations model which is incredibly flawed. Also, HBSS was poorly implemented in the 2010 time frame and Tanium was introduced (at least in the Marine Corps networks) around 2017. Both are major contributing factors to the issue you're describing.
In short: the current state is that computers are barely usable and that is not NMCI from yester-year.
When people complained about not getting the things they wanted, what they were really railing against was the fact that they didn't get what they wanted all the time anymore; the military grew accustomed to telling someone "I want X" and it happened, regardless of cost, lifecycle sustainment, security, etc. NMCI forced the DoN to develop and articulate requirements properly, write good contracts, budget for software and hardware sustainment, and generally operate professionally.
In short, I would take an NMCI computer and enterprise services from 2010 versus a Marine Corps Enterprise Network computer and enterprise services from 2022 any day of the week.
Disclosure: I have been a Marine Corps Communications Officer for almost 20 years; starting before NMCI. I worked at the regional and enterprise levels to transition ownership back from the NMCI program/contractor to government owned.
Where the M1 architecture really shines is the collaboration between CPU, GPU, memory, SSD, and other components on the SoC. The components all work together within the same 5nm silicon fabric, without ever having to go out to electrical interconnects on a motherboard. Thereby saving power, heat, etc.
What you lose in repairability/upgradability, you gain in performance on every front. That tradeoff is no different than what we chose in our mobile devices. If repairability and upgradability are more important to you, then definitely don't buy a device with an Apple M1; absolutely buy a Framework laptop (https://frame.work).
Once the client-side JS has taken over, the `next/link` component [1] is used to render and listen to events when a user clicks on a link. That component tells `next/router` to render the page that was clicked on. All of this happens on the client by default. If JS is disabled on the client, then the HTML rendered by the `next/link` component on the server is a simple `<a/>` tag and a normal browser page load occurs.
1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client.
2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions.
3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state.
4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.
This problem set reminds me that The Philippines has a similar problem with their "Overseas Foreign Worker" population (estimated at 2.2M people) that works overseas, primarily in the Middle East, in order to send money back home.
1 - https://www.goodreads.com/book/show/38840.Boyd
2 - https://en.wikipedia.org/wiki/Energy–maneuverability_theory
Can you provide an example of what you're referring to?
After 20 years of network/system/software engineering across a wide variety of network sizes and levels of complexity, I teach people the following method to troubleshoot complex network issues:
1. Write down the symptoms that you're seeing. How do you know something is wrong? What do you see happening?
2. Draw a diagram that includes all of the components and nodes involved. (this is hard)
3. Develop some hypotheses that could be worth testing. (this is hard and highly variable based on knowledge/experience)
4. Establish a "test plan" that allows you to prove/disprove the hypotheses while making minimal changes to the system. Start from one source device and work your way out to the farthest component you identified in your diagram. Start at the lowest OSI layer and work your way up.
5. Methodically test components, step by step, along the diagram.
6. As you test, record your results. Add new hypothesis to the list as you gather more information but don't start testing them right away! You can develop a new test plan after you finish the first one that proves/disproves your new hypotheses.
7. Repeat all steps, adding new information, until you find a solution.
I know this seems like a lot of steps when you're just troubleshooting a WiFi issue at home--it may be overkill. However, this framework applies to that scenario or when you're diagnosing any complex network issue. You'll learn more about the systems, protocols, and devices that truly make up the Internet than you could ever imagine. Through repetition and experience, these steps will get easier and some of them can happen quickly and in your head.
To help you get started, here's some info for steps 1, 2, and 3:
1. From your post: "3:40pm every day my wifi loses internet access. My devices remain connected to the network, but all traffic dies. Almost exactly 1 minute later everything is resumed"
2. Start your diagram off as an "equipment string diagram". This will include all physical devices between you and the Internet. Along the way, you may need to modify the equipment string diagram to include "virtual" devices, network segments, various protocols/servers, etc. Your diagram should include at least the following items:
- Your laptop/desktop. If it's happening to all devices, then pick one. Identify your IP and MAC addresses
- The WiFi access point that device is connected to. Identify the IP and MAC addresses
- Any switches, firewalls, modems, etc that connect from your WiFi access point to your Internet Service Provider (ISP) and their IP and MAC addresses.
- The "next hop" from your modem into the ISP's network. You can use a cloud to represent the ISP's network that you don't know/understand, but always identify the IP address of the device that your modem first reaches. If you can find the MAC address (or other OSI Layer 2 address) as well, even better.
That's the equipment string between you and "The Internet". For now, you can ignore the complexity inside the ISP's network and beyond. You might have to add more of that later, but start small.We know there are other components involved in making the Internet work that introduce complexity and can cause issues along the way. Let's list them on your diagram and identify what servers are used and where they might be located.
- DHCP (local to your network and also between your modem and ISP)
- DNS (could be local to your network and often is a third party service either run by your ISP or not)
- Encryption (VPNs, SSL certificates, network device clock settings, etc)
- IP routing (what devices do IP routing? Hint: all devices that operate at Layer 3, using IP, do IP routing--including your workstations)
3. Some hypotheses (some were identified in the comments): - Is there a device in the equipment string that is rebooting every day?
- Is DNS intermittently failing?
- Is DHCP releasing/renewing your IP address assignment? This could be from your device -> local DHCP server OR your modem -> ISP DHCP server
- Is there an upstream connectivity issue with your ISP?
- Is your WiFi access point losing connectivity?Qube Money and Envel.ai seem to be the most similar competitors after searching for a bit.
Here's an article on Qube Money's website: https://blog.qubemoney.com/leaving-simple-bank-heres-why-qub...
In that article, there's a link to a Google Sheet that someone on Reddit created comparing alternatives: https://docs.google.com/spreadsheets/u/2/d/1Etr8dGtviSRpdAjR...